Saw it, thought it was interesting.
3 Likes
Bit light on details.
The âexploitâ presumably needs direct access to the SSD controller, which in any sane platform should not be possible from a non-system/non-root user account.
I mean if you have that foothold already, you can potentially store your shit in network adapter/gpu firmware, hard disk firmware (NSA were doing this 8-10+ years ago), OOB management engine, etc.
3 Likes
While it is very interesting, it is a shame that the news articles seem to be conveniently leaving out that this is a PoC from university research, not a piece of malware in the wild.
I hope you do not mind, I posted this in the newsdump thread (archived), so anyone perusing there might see it as well.
2 Likes
There was talk of rewriting controller chips on hard-drives for persistantsâ, bios is another scarry one as itâs not easy to check on normal hardware, I.e. most moboâs have two chips⌠donât have a hand held checker box!
1 Like
And how is the average bloke supposed to deal with something like that or even similar malware made on such a low-level hardware interface? Even general developers wouldnât be able to do so.
Many of the super malware out there on the news, sounds like you should be a proffessional black/grey/white hat to even DETECT the thing, let alone remove it.
1 Like
Just switch all your compute over to DIY whatever so nobody except you understands why it works in the first place.
3 Likes
Soon i wonât be able to tell if all technologies added to hardware is there to be useful for the end-user or just to have somewhere else to place malware.
2 Likes
Next super malware. Uses DLSS to up and downscale malware code in firmware. Even playbacks an .mkv file to show a visualization of itâs effects on the components.
No one knows why, but it can also use HDR technology to outmanevour RGB components below 29 lumen. To produce a 29.000 nits RGB effect.
2 Likes
Keep up to date and do not let your machine get compromised in the first place.
This isnât an exploit to compromise your machine, its a persistency foothold once compromised.
ANY machine, imho that has been compromised can never truly be trusted for this sort of reason. So many peripherals have firmware in them that is executed by the processor in some way and if you have system/root level access on the box you can flash them.
NSA had a hard drive firmware exploit 10-15+ years ago for example.
[citation provided] 
One of the Equation Groupâs malware platforms, for instance, rewrote the hard-drive firmware of infected computersâa never-before-seen engineering marvel that worked on 12 drive categories from manufacturers including Western Digital, Maxtor, Samsung, IBM, Micron, Toshiba, and Seagate.
Tangentially related to this is the reason the Talos/OpenPOWER crowd stresses the importance of having a strict IOMMU and using disk encryption; while any CPU-side malware could still cooperate with an infected HDD/SSD, GPU or other PCI[e] peripheral to store data, a proper IOMMU configuration prevents the rogue device from using DMA to infect a âcleanâ kernelâs memory or that of a userspace program.
Of course, if there is no form of authenticated/secure boot, a malicious storage device could in theory swap out the kernel files that are loaded (vmlinux and/or initrd) at boot time, without violating any IOMMU DMA protections. I do not know if Option ROMs on PCI[e] devices might also be an avenue to bypass IOMMU protections, but in the past I think Computrace may have persisted via such a method.
My ideal is that we will see Xen ported to Power (hopefully by then I will be able to afford such a machine), so that a Talos/Blackbird system could run Qubes.
On Talos II or Blackbird, as long as one avoids the optional SAS controller, the only closed-source reprogrammable binary in the entire system is in the hard drive or SSD the user installs, and with secure boot from open-source firmware, the HDD/SSD does not need to be trusted at all.
The NIC was originally a concern, but due to community effort (with some encouragement) the NIC firmware was reversed and re-implemented and now ships on newly purchased machines.
Since Power is more of a niche platform, Option ROMs (usually containing x86 code) did not work anyway, so there is no legacy need/want to support them anyway.
Of course, open-source code is no guarantee of better security, especially when the alternative is a proprietary product that receives intensive auditing, but with SSDs and HDDs, I suspect their firmwares stay out of the limelight so much that open source would definitely be an increase in code scrutiny.
I would love to see an open source firmware replacement for SSDs, but the project I have seen, OpenSSD, seems to be more of a research or training prototype.
1 Like
Isnât most super malware exactly about that? The persistency foothold⌠The problem is that itâs somewhat easy for people that work in groups, to get those elevated privileges just once. Which is more than enough. When that is achieved, the device is basically âa malware brickâ. Very possibly, without showing any signs of it being so.
My point is that unless youâre compromised in the first place thereâs nothing to worry about with this SSD exploit.
And if you DO get compromised⌠well there have been firmware level persistency footholds in use for the past⌠15+ years
Not to say it isnât bad. But given the malware already has system level privileges, putting itself in SSD unprovisioned space, the boot loader, your firmware, etc. is all to be expected.
This shouldnât be news; get malware on your machine and anything that can be written to, modified, etc. by a firmware update, system update, low level format, etc. is all fair game.
TLDR: if you get malware on your machine that runs with system privileges and the box is actually important - it can never be trusted again imho. This exploit is nothing new with regards to that at all and should surprise no one. Its not really news that this is possible.
1 Like