Re: [Cryptography] trojans in the firmware
On Wed, Feb 18, 2015 at 8:57 PM, Henry Baker <hbaker1@pipeline.com> wrote:
At 03:12 PM 2/18/2015, grarpamp wrote:
Afaik, all vm's today simply pass through all drive commands.
It seems a move all the BSD's and Linux could make today, without waiting on untrustable hardware vendors to roll out signature verification in hardware, is to simply kernel block all commands unnecessary to actual production use of the disk. Permit only from a list of READ, WRITE, ERASE, INQ, TUR, RST, and so on. Thus every other command component, including firmware update, vendor specific, and binary fuzzing, gets dropped and logged.
???? If the disk drive or flash drive firmware has already been compromised, none of this will work, because the firmware simply waits for the appropriate "legitimate" read & write commands, and does its thing.
Obviously. This is only meant to help protect clean systems, or prevent subsequent malicious commands if they happen to go through a user to kernel path that has for some reason not yet been compromised (say through the usual /dev to driver to hardware path).
BTW, what happens with "emulated" disks -- e.g., .vdi files -- in vm's ? Presumably these emulated disks have no firmware to update, so any attempt would either be ignored or crash the system.
Depends on how the vm is coded. My guess is vm's that emulate say disk devices, munge those opcodes too. Yes, looking at how virtualbox and even lightweight instances like jails code/handle it could be useful. Try it and see :) In all cases, having the logging capability for non production opcodes without having to postfilter them out of some debugging stream would be nice. Obviously again caveat parts of the system that have not been compromised, and defense in depth.
On 02/18/2015 09:13 PM, grarpamp wrote:
On Wed, Feb 18, 2015 at 8:57 PM, Henry Baker <hbaker1@pipeline.com> wrote:
At 03:12 PM 2/18/2015, grarpamp wrote:
Afaik, all vm's today simply pass through all drive commands.
It seems a move all the BSD's and Linux could make today, without waiting on untrustable hardware vendors to roll out signature verification in hardware, is to simply kernel block all commands unnecessary to actual production use of the disk. Permit only from a list of READ, WRITE, ERASE, INQ, TUR, RST, and so on. Thus every other command component, including firmware update, vendor specific, and binary fuzzing, gets dropped and logged.
???? If the disk drive or flash drive firmware has already been compromised, none of this will work, because the firmware simply waits for the appropriate "legitimate" read & write commands, and does its thing.
Obviously. This is only meant to help protect clean systems, or prevent subsequent malicious commands if they happen to go through a user to kernel path that has for some reason not yet been compromised (say through the usual /dev to driver to hardware path).
BTW, what happens with "emulated" disks -- e.g., .vdi files -- in vm's ? Presumably these emulated disks have no firmware to update, so any attempt would either be ignored or crash the system.
Depends on how the vm is coded. My guess is vm's that emulate say disk devices, munge those opcodes too. Yes, looking at how virtualbox and even lightweight instances like jails code/handle it could be useful. Try it and see :)
In the VirtualBox manual, I see: | Starting with version 1.4, as an alternative to using virtual | disk images (as described in detail in Chapter 5, Virtual | storage), VirtualBox can also present either entire physical | hard disks or selected partitions thereof as virtual disks | to virtual machines. | | With VirtualBox, this type of access is called "raw hard | disk access"; it allows a guest operating system to access | its virtual hard disk without going through the host OS | file system. ... <https://www.virtualbox.org/manual/ch09.html#rawdisk> Given that, I'm assuming that when using VDIs, the host OS doesn't allow VMs to directly access physical disks. And I don't see how a VM could reconfigure itself for raw hard disk access to the host disk, because doing so would such access to its own config. But if anyone can manage it, the NSA arguably can.
In all cases, having the logging capability for non production opcodes without having to postfilter them out of some debugging stream would be nice. Obviously again caveat parts of the system that have not been compromised, and defense in depth.
On Thu, Feb 19, 2015 at 2:17 AM, Mirimir <mirimir@riseup.net> wrote:
https://www.virtualbox.org/manual/ch09.html#rawdisk
Given that, I'm assuming that when using VDIs, the host OS doesn't allow VMs to directly access physical disks. And I don't see how a VM could reconfigure itself for raw hard disk access to the host disk, because doing so would such access to its own config.
The link is saying different than that. VM VDI is just a backing file on the host OS FS, opcodes likely fail here, note in link how VM supplies fake disk VPD to guest OS. Host OS often runs VM as root and even may assist by loading VM kernel module. VM's can thus passthrough host OS devices to guest OS if so configured, and if so, VM probably does not filter any opcodes, particularly if passing an entire physical disk. Also consider what VT-d is doing regarding sharing physical devices. So you'd still want opcode filtering in kernel in those cases.
On 02/19/2015 03:58 PM, grarpamp wrote:
On Thu, Feb 19, 2015 at 2:17 AM, Mirimir <mirimir@riseup.net> wrote:
https://www.virtualbox.org/manual/ch09.html#rawdisk
Given that, I'm assuming that when using VDIs, the host OS doesn't allow VMs to directly access physical disks. And I don't see how a VM could reconfigure itself for raw hard disk access to the host disk, because doing so would such access to its own config.
The link is saying different than that. VM VDI is just a backing file on the host OS FS, opcodes likely fail here, note in link how VM supplies fake disk VPD to guest OS. Host OS often runs VM as root and even may assist by loading VM kernel module.
VirtualBox in Linux doesn't require root rights. I just checked htop on the host, and all VM processes are running as user. And visudo shows nothing about VirtualBox.
VM's can thus passthrough host OS devices to guest OS if so configured, and if so, VM probably does not filter any opcodes, particularly if passing an entire physical disk.
How would I test that? I suppose that I could setup a VM to boot from an HDD, and then see if I can flash the HDD's firmware. But I'm not the NSA, and so only success would be probative. But hey, I'll take a shot.
Also consider what VT-d is doing regarding sharing physical devices. So you'd still want opcode filtering in kernel in those cases.
I see that VirtualBox can use VT-d passthrough for PCI devices, such as NICs, and maybe displays. But don't see any mention of VT-d for disks and CD/DVD. I do see that QEMU can do more of that, however.
How would I test that? I suppose that I could setup a VM to boot from an HDD, and then see if I can flash the HDD's firmware.
If this firmware trojan is EFI-based: For PCI-based devices, use an Intel Tunnel Mountain box, an EFI dev box. You can install a debug version of the firmware with symbols or full-source level debug info, and debug it with a second machine using GDB or Windbg. http://tunnelmountain.net/ For USB-based devices, use an Intel Minnowboard MAX, a low-end dev board for 'hobbiests'/'hackers' for Yocto and UEFI. Much cheaper than the Tunnel Mtn box. http://www.minnowboard.org/ Consider trying to use QEMU to test a virtual drivers for native passthru. QEMU has the best diagnostic options for UEFI, it is the UEFI Forum's main virtualization option for EFI dev. You can build the same kind of debug firmware image for QEMU (called OVMF) as with live box. VirtualBox has some EFI support, especially when you build it with custom flags and set some environment variables. But AFAIK, VirtualBox's EFI support is less powerful than QEMUs. http://www.tianocore.org/ovmf/ If malware vendor provided ARM OpROMs in addition to Intel ones, use one of Linaro's target ARM dev boards. They have a fork of TianoCore EFI for each of these boards, and you can use that OVMF with QEMU as well. https://wiki.linaro.org/LEG/Engineering/Kernel/UEFI
On Thu, Feb 19, 2015 at 7:35 PM, Mirimir <mirimir@riseup.net> wrote:
VirtualBox in Linux doesn't require root rights. I just checked htop on the host, and all VM processes are running as user. And visudo shows nothing about VirtualBox.
It may be setuid and switching users, or kernel module or helper program or something, otherwise vbox docs about pointing at /dev/sdx are bogus because the raw devices aren't available to non root users. I didn't read vbox docs closely.
How would I test that? I suppose that I could setup a VM to boot from an HDD, and then see if I can flash the HDD's firmware. But I'm not the NSA, and so only success would be probative. But hey, I'll take a shot.
http://www.t13.org/documents/UploadedDocuments/docs2008/d1699r6a-ata8-acs.pd... With whatever windows tools you find. Probably sdparm hdparm on linux. camcontrol's cmd capabilities and cam(4) debug options on freebsd. I wouldn't try to flash or fuzz a drive you can't afford to brick.
On 02/20/2015 03:50 AM, grarpamp wrote:
On Thu, Feb 19, 2015 at 7:35 PM, Mirimir <mirimir@riseup.net> wrote:
VirtualBox in Linux doesn't require root rights. I just checked htop on the host, and all VM processes are running as user. And visudo shows nothing about VirtualBox.
It may be setuid and switching users, or kernel module or helper program or something, otherwise vbox docs about pointing at /dev/sdx are bogus because the raw devices aren't available to non root users. I didn't read vbox docs closely.
OK, I'll dig. It might be that mounting physical disks on the host requires root rights. But that's obviously insecure. What concerns me is guest access to the host's disk firmware when using VDIs.
How would I test that? I suppose that I could setup a VM to boot from an HDD, and then see if I can flash the HDD's firmware. But I'm not the NSA, and so only success would be probative. But hey, I'll take a shot.
http://www.t13.org/documents/UploadedDocuments/docs2008/d1699r6a-ata8-acs.pd... With whatever windows tools you find. Probably sdparm hdparm on linux. camcontrol's cmd capabilities and cam(4) debug options on freebsd. I wouldn't try to flash or fuzz a drive you can't afford to brick.
Not a problem. I have a bunch of retired disks.
On Fri, Feb 20, 2015 at 7:39 AM, Mirimir <mirimir@riseup.net> wrote:
On 02/20/2015 03:50 AM, grarpamp wrote:
On Thu, Feb 19, 2015 at 7:35 PM, Mirimir <mirimir@riseup.net> wrote:
VirtualBox in Linux doesn't require root rights. I just checked htop on the host, and all VM processes are running as user. And visudo shows nothing about VirtualBox.
It may be setuid and switching users, or kernel module or helper program or something, otherwise vbox docs about pointing at /dev/sdx are bogus because the raw devices aren't available to non root users. I didn't read vbox docs closely.
OK, I'll dig. It might be that mounting physical disks on the host requires root rights. But that's obviously insecure. What concerns me is guest access to the host's disk firmware when using VDIs.
How would I test that? I suppose that I could setup a VM to boot from an HDD, and then see if I can flash the HDD's firmware. But I'm not the NSA, and so only success would be probative. But hey, I'll take a shot.
http://www.t13.org/documents/UploadedDocuments/docs2008/d1699r6a-ata8-acs.pd... With whatever windows tools you find. Probably sdparm hdparm on linux. camcontrol's cmd capabilities and cam(4) debug options on freebsd. I wouldn't try to flash or fuzz a drive you can't afford to brick.
Not a problem. I have a bunch of retired disks.
On Fri, Feb 20, 2015 at 7:39 AM, Mirimir <mirimir@riseup.net> wrote:
I wouldn't try to flash or fuzz a drive you can't afford to brick.
Not a problem. I have a bunch of retired disks.
Annex A or B have historical references which may be useful for expectation with older disks. SCSI has parallel doc sets you can find. .../docs2014/di529r06-ATAATAPI_Command_Set_-_4.pdf
participants (3)
-
Blibbet -
grarpamp -
Mirimir