Is Armory vulnerable to USB-Stick viruses like BadBios?

[Inaba]

What about a raw/custom formatted USB stick?

I think a real danger after disabling autoplay is the filesystem itself. There have been exploits within several kernel modules for the different filesystems (e.g. http://www.cvedetails.com/cve/CVE-2013-1773, http://www.cvedetails.com/cve/CVE-2011-4330, http://www.cvedetails.com/cve/CVE-2009-4020). I don't know how severe these bugs are and if they could have been used for malicious code execution, but I think it is reasonable to expect an existing, unfixed bug, which can be used for code execution.

A custom format, which only defines the most necessary fields to transfer the raw transaction data should be much safer. The code to read the custom format should be much simpler and thus less error prone than conventional kernel filesystem modules. Additionally, any exploit of this custom format parser will be executed in the user space and not within the kernel, because only the signing application (e.g. Armory) must read and parse the data.


My thoughts about the USB stick infection of "badBIOS":
I don't think, that it is possible for a simple mass storage device to infect a pc just by plugging in (and not reading and interpreting any data on it). The circuit to read and write data on the drive is hardwired and can't be manipulated by software (correct me if I'm wrong). This should be true for the USB host interface in the mainboard, too. So as long as there is no data transfer it is impossible to infect anything. Things might change if data is transfered. However, even then, the hard wired host interface or the kernel code which handles the usb frames must be compromised by a malformed usb frame. This however should be prevented by the hard wired circuit on the drive itself.
Don't get me wrong, I think it is perfectly believable, that a system can be compromised by its USB subsystem. This has been demonstrated with the PS3. However, a special USB frame had to be crafted for this to happen. A simple mass storage device could not do this.

I think part of the problem is that windows kind of does its down thing when a USB device is inserted.  Admittedly I am not that well versed in Windows USB enumeration, but it's always been my feeling (which may be entirely baseless) that windows does a lot of data reading and other useless stuff (in the name of convenience) when a USB device, particularly a storage device, is inserted into the system.  That can be exploited as an attack vector and would be no guarantee of safety, even with a custom formatted stick, since Windows will still try to read it and ask if you want to format it (at which time a specially crafted payload could be delivered) ... this might be far fetched and unlikely, but I'm just throwing it out there as an avenue I would look into if I were looking to exploit an offline bitcoin computer that might be using Armory   or something similar.

[1715320767]

1715320767

[1715320767]

1715320767

[1715320767]

1715320767

[1715320767]

1715320767

[1715320767]

1715320767

[1715320767]

1715320767

[maaku]

dacoinminster, if badbios does what people are claiming it does, you're fcked no matter what. There's nothing a user-level program like Armory can do to protect you, except perhaps using a TPM chip. There are no robust wallet apps with TPM signers that I'm aware of*, although this would be a good addition to Armory...

(* except maybe this?)

[maaku]

I don't think, that it is possible for a simple mass storage device to infect a pc just by plugging in...

It is, and this is exactly what badbios is about. The target is not the OS's USB software stack, it's the USB microcontroller itself. It then spreads to the keyboard. Or the sound card's DSP. Or the CPU itself (yes, there are multiple microcontrollers inside the CPU). All of these devices have direct access to the machine, circumventing any OS protections.

[adam3us]

dacoinminster, if badbios does what people are claiming it does, you're fcked no matter what. There's nothing a user-level program like Armory can do to protect you, except perhaps using a TPM chip. There are no robust wallet apps with TPM signers that I'm aware of*, although this would be a good addition to Armory...

Well there is also the air-gapped optical interface: scanning QR codes. drazvan made an offline QR code scanning wallet using network disabled cheap android wallet (can buy for $50 - $100) including camera.  Then you can make payments.

You do need no buffer overflows in the QR code scanner, but other than that...

And at least thats code we get to look at, not USB firmware on a motherboard.

Adam

[maaku]

Adam, I don't think that's the issue. The air-gapped communication is just an interesting tidbit about how it operates (presumably to mesh network inside of secure facilities like Iran's nuclear research bunkers). Presumably BadBIOS is state sponsored, and not concerned with bitcoin. But hypothetically if it were a wallet-stealing malware it has perpetual root access to the machine it has infected and be able to scan RAM or disk for bitcoin-like data structures and steal the private key as it is scanned or decrypted in memory. By residing in embedded peripherals it is able to inject itself first into the BIOS/EFI, and then into the OS kernel during the boot process, and cannot be removed by any existing generation of anti-virus tools or user action (solution: buy a new computer and think up a creative way to get needed data off the old without infecting the new).

[etotheipi]

dacoinminster, if badbios does what people are claiming it does, you're fcked no matter what. There's nothing a user-level program like Armory can do to protect you, except perhaps using a TPM chip. There are no robust wallet apps with TPM signers that I'm aware of*, although this would be a good addition to Armory...

Well there is also the air-gapped optical interface: scanning QR codes. drazvan made an offline QR code scanning wallet using network disabled cheap android wallet (can buy for $50 - $100) including camera.  Then you can make payments.

You do need no buffer overflows in the QR code scanner, but other than that...

And at least thats code we get to look at, not USB firmware on a motherboard.

Adam

Personally, I think this is an ideal steady-state solution once the offline system is setup.  But you can't use plain QR codes, you'll have to do QR videos.  If you have to move 2 MB to the offline computer and back... you really want those 100 QR codes to be cycled at 13.82 Hz (or any frequency that isn't a multiple of the other device sampling frequency).  Though even then, your arm might get kind of tired holding it up while it acquires all the images.  Meh. 

But there is still the concern about getting the system setup in the first place.  I guess if you have a custom OS image with the camera software pre-installed, you could use the QR thing to move the Armory offline bundle intself onto the system. 

Yeah, we really need to come up with a set of best practices, so people have some kind of guidance...

[flipperfish]

I don't think, that it is possible for a simple mass storage device to infect a pc just by plugging in...

It is, and this is exactly what badbios is about. The target is not the OS's USB software stack, it's the USB microcontroller itself. It then spreads to the keyboard. Or the sound card's DSP. Or the CPU itself (yes, there are multiple microcontrollers inside the CPU). All of these devices have direct access to the machine, circumventing any OS protections.

I did dig into this a bit more and it seems the controllers of common usb sticks are really not as hardwired as I thought. The spec-sheet of this (http://www.phison.com/english/newProductView.asp?ID=199&SortID=60) rather cheap IC explicitly states "Firmware Upgradable". So my earlier thoughts are probably wrong.

[adam3us]

Personally, I think this is an ideal steady-state solution once the offline system is setup.  But you can't use plain QR codes, you'll have to do QR videos.

drazan's visualBTC android offline wallet uses "animated QR codes" which is consistent with what you said about the practical bandwidth requirements.  https://bitcointalk.org/index.php?topic=210371.0

The other thing is there's a sanity size cap on a transaction: the bitcoin block size is limited to 1MB for now, and I think its probably the bitcoin developers might have to take countermeasures or non-linear size related fees if people got in the habit of creating individual transactions that use a whole block - that would limits bitcoin to one transaction per 10 minutes.

But there is still the concern about getting the system setup in the first place.  I guess if you have a custom OS image with the camera software pre-installed, you could use the QR thing to move the Armory offline bundle intself onto the system.  

Maybe there's a market to include a PGP code signing key. and a pre-installed armory client in an armory labeled cheap android tablet with the speaker, microphone, bluetooth, wifi, and USB cables cut.  (Or one that could be made cheaper by not even including that hardware).

Then you could send it via QR video, armory signed software upgrades;)

I think a risk with USB is someone can infect the online wallet via remote internet compromise, infect a USB that gets plugged into it, and from there into the offline wallet.

Adam

[malevolent]

The badBIOS analysis is wrong + comments

+

some of the comments here:
http://www.reddit.com/r/netsec/comments/1ppwet/the_badbios_analysis_is_wrong/

[JakeGold]

I've actually been thinking about exactly this for the last few months.

I thought I had something when I found UBS drives with a physical write lock, but that doesn't help when you need to write the unsigned transaction from the online machine to the device, and then sign it on the offline machine and write the signed version on again, which has to be moved to an online machine.

If you could communicate the unsigned transaction through QR codes, assuming the offline machine is not infected, you could write the signed version to the USB, then lock it and move it to the broadcast machine, insuring that nothing jumps to the drive.

[justusranvier]

I did dig into this a bit more and it seems the controllers of common usb sticks are really not as hardwired as I thought. The spec-sheet of this (http://www.phison.com/english/newProductView.asp?ID=199&SortID=60) rather cheap IC explicitly states "Firmware Upgradable". So my earlier thoughts are probably wrong.

I wonder if any of the ASIC designers could produce provably-secure USB controllers.

[justmyname]

A good virus program will go a long way in ferreting out any bad code.

[etotheipi]

Personally, I think this is an ideal steady-state solution once the offline system is setup.  But you can't use plain QR codes, you'll have to do QR videos.

drazan's visualBTC android offline wallet uses "animated QR codes" which is consistent with what you said about the practical bandwidth requirements.  https://bitcointalk.org/index.php?topic=210371.0

The other thing is there's a sanity size cap on a transaction: the bitcoin block size is limited to 1MB for now, and I think its probably the bitcoin developers might have to take countermeasures or non-linear size related fees if people got in the habit of creating individual transactions that use a whole block - that would limits bitcoin to one transaction per 10 minutes.

Just to be clear, the issue is not the maximum size of a single transaction.  The issue is that in order for the offline computer to verify the transaction fee, you must supply every, full, supporting transaction along with the one to be signed.  The offline computer must see the tx associated with every input, so it can verify the value of each input.  Therefore, if I send you a few dust outputs contained in 100 kB transactions, then you will potentially be moving 0.5 MB of tx.  Even without me doing anything, I"ve had people report issues because they use their offline wallet to collect lots of small payments over time and then end up with 271 inputs at once.  Those are multi-megabyte transactions.  The single QR codes are just not scalable for this, requiring me to develop something that can handle wider bandwidth for those cases, anyway...

Technically, there's a trivial hard-fork solution:  https://bitcointalk.org/index.php?topic=181734.0 ... but I don't have much hope of it being adopted.  

[etotheipi]

Whoops, totally posted to the wrong thread!  Please ignore this post...

[Post relocated to the correct thread]

[adam3us]

Just to be clear, the issue is not the maximum size of a single transaction.  The issue is that in order for the offline computer to verify the transaction fee, you must supply every, full, supporting transaction along with the one to be signed.  The offline computer must see the tx associated with every input, so it can verify the value of each input.

Technically, there's a trivial hard-fork solution:  https://bitcointalk.org/index.php?topic=181734.0 ... but I don't have much hope of it being adopted.  

I suppose there are two ways to view that:

a) transaction fees should not be implicit (and outputs summing to inputs, including fee should be validated downstream); or

b) the signer should state what he is spending (and the downstream should verify it) as you proposed in the above link.

Either solution could be fine.  Kind of frustrating the pace of progress on bitcoin main though one can fully appreciate the risks and resource constraints, but mostly the risks.  It is why I proposed the bitcoin-staging idea.  Now all we have to do is coax Warren Togami (formerly fedora distro founder) into taking the mantle.  He already ventured from litecoin into spinning a bitcoin-OMG release (litecoin latest fork with bitcoin parameters reinstated, to give bitcoin users the advantages of litecoin validated fixes).

Though something like that is less use to armory as armory is itself on the high value end of the bitcoin scale, and people may not use the fedora like variant on high value.

Streamline and practice a system for hard forks?

Stall and dont progress and get undertaken by faster progressing alt-coins?

Move too fast and make a security mistake.

Rock and hard-place.  Hmmm.

Adam

[Roy Badami]

I don't think, that it is possible for a simple mass storage device to infect a pc just by plugging in (and not reading and interpreting any data on it). The circuit to read and write data on the drive is hardwired and can't be manipulated by software (correct me if I'm wrong). This should be true for the USB host interface in the mainboard, too. So as long as there is no data transfer it is impossible to infect anything. Things might change if data is transfered. However, even then, the hard wired host interface or the kernel code which handles the usb frames must be compromised by a malformed usb frame. This however should be prevented by the hard wired circuit on the drive itself.
Don't get me wrong, I think it is perfectly believable, that a system can be compromised by its USB subsystem. This has been demonstrated with the PS3. However, a special USB frame had to be crafted for this to happen. A simple mass storage device could not do this.

Yes, but a whole bunch of USB frames get exchanged when you plug a device in, to identify the device.  As you say, a specially crafted USB frame could trigger a buffer overflow in the USB stack.  (ETA: That's more a risk with a specially designed malicious device - it's less likely a standard USB stick could be made to do this.)

Still, if you're going to dedicate an offline machine to Armory, then I think it's a reasonable precaution to spend a couple of extra bucks to buy a couple of brand new USB sticks and use them exclusively for moving Armory transactions about.  Doesn't completely remove the risk, but is a good way to minimize it.

[flipperfish]

Yes, but a whole bunch of USB frames get exchanged when you plug a device in, to identify the device.  As you say, a specially crafted USB frame could trigger a buffer overflow in the USB stack.  (ETA: That's more a risk with a specially designed malicious device - it's less likely a standard USB stick could be made to do this.)

Actually this was exactly my line of thinking. Device gets plugged in, hard-wired USB interface IC exchanges USB frames with host in order to recognize the device. So far no danger, because the hardwired part of the stick can't be changed. If the data in a data carrying frame could trigger an exploit? I don't know, but I suppose not, because the host interface should expect any data within the payload.

However as it turned out, most USB devices, even cheap standard USB sticks, have microcontrollers with "upgradable firmware". I don't know, if it is possible to alter the firmware through the USB interface. But for some USB sticks this must be true, as for example those sticks, who identify themselves as CD drives to the host to make autorun work, can be changed to not do this anymore. However, if the software driving the microcontroller in the stick can be altered, it is also possible for the stick to send some malicous frames, where the whole frame can be used to trigger the exploit in the host interface/driver.

Still, if you're going to dedicate an offline machine to Armory, then I think it's a reasonable precaution to spend a couple of extra bucks to buy a couple of brand new USB sticks and use them exclusively for moving Armory transactions about.  Doesn't completely remove the risk, but is a good way to minimize it.

I don't know if it makes sense to use "new" USB sticks. Maybe, if you don't know, where the USB sticks you already posess have been used in the past. But if the online pc is infected, a "new" USB stick doesn't help, because the online pc can infect the stick, when the unsigned transaction is copied to the stick.

[maaku]

flipperfish, most USB controllers do some processing at that layer. That's why there is a microcontroller, after all. If there is a security hole at that layer, then a specially constructed USB device (like, say, those given out at conferences or the G8 summit) could do a buffer-overflow like attack against the microcontroller itself, before the frame is passed up to the operating system's USB stack. It then flashes the USB controller with its own custom firmware, sticks the virus payload in NVRAM for insertion into the kernel at next boot, and then passes up fixed, normal USB frames to the host OS. What you need to realize is that none of this occurs on the CPU or in main memory, so it's pretty much undetectable with the current generation of commercially available security software. When you flash the USB firmware, what do you think it does? It send commands to... the USB microcrontoller. If the virus is already in the controller, then it is perfectly capable of flashing itself without outside involvement.

And yes, using a new stick doesn't really gain you anything for the reason you mention.

[flipperfish]

flipperfish, most USB controllers do some processing at that layer. That's why there is a microcontroller, after all. If there is a security hole at that layer, then a specially constructed USB device (like, say, those given out at conferences or the G8 summit) could do a buffer-overflow like attack against the microcontroller itself, before the frame is passed up to the operating system's USB stack. It then flashes the USB controller with its own custom firmware, sticks the virus payload in NVRAM for insertion into the kernel at next boot, and then passes up fixed, normal USB frames to the host OS.

I think, you are talking about the controller of the host interface? It can be compromised by a malformed usb frame (while doing its custom processing before passing it to the OS). That's basically, what I've written before. Of course, the malware is then able to do all other kinds of shady things with or without help of the OS and it will execute on the USB controllers internal "CPU" or the main CPU. This includes changing the BIOS and so on. This way of infection is possible, no question. The hack of the PS3 showed this very well.

However, what I've been talking about, is the controller of the pen drive itself, which manages the data flow between the host's controller and the flash-chip itself. As long as this controller is hardwired and cannot be changed by software, the host pc can't be infected with this pen drive by just plugging in and transferring data. I just refuse to accept, that the host's controller can be compromised by a malicious data payload in an usb frame (Note: I really mean the data part of the usb frame, not the header and other protocol-overhead). The host-interface should never care about the data part. And the header cannot be changed, because the flash drives's controller, which creates the frames and puts the data in, is (in this current assumption) hardwired. Of course, as soon as the data gets interpreted in some way, buffer overflows and the like can happen and cause malware to be executed.

Anyways, it's superflous, because the pen drive's controller can be reprogrammed, as I learned now. However, it still has to be seen, if the reprogramming can happen through the USB interface, or only via other ways (SPI and the like), that are not connected to the host pc in normal operation. For some USB flash drives, I'm pretty sure it's possible via USB.

What you need to realize is that none of this occurs on the CPU or in main memory, so it's pretty much undetectable with the current generation of commercially available security software.

I think, I realized this a long time ago, when the first proof-of-concept trojans, that could hide in the eeprom of a network card, were made public. Of course, this kind of malware can't be detected by antivirus software. However, there are already a lot of other ways to escape antivirus software with conventional, software-only malware. So I think it's rather stupid to rely on av-software alone for important things.

[greBit]

flipperfish, most USB controllers do some processing at that layer. That's why there is a microcontroller, after all. If there is a security hole at that layer, then a specially constructed USB device (like, say, those given out at conferences or the G8 summit) could do a buffer-overflow like attack against the microcontroller itself, before the frame is passed up to the operating system's USB stack. It then flashes the USB controller with its own custom firmware, sticks the virus payload in NVRAM for insertion into the kernel at next boot, and then passes up fixed, normal USB frames to the host OS. What you need to realize is that none of this occurs on the CPU or in main memory, so it's pretty much undetectable with the current generation of commercially available security software. When you flash the USB firmware, what do you think it does? It send commands to... the USB microcrontoller. If the virus is already in the controller, then it is perfectly capable of flashing itself without outside involvement.

And yes, using a new stick doesn't really gain you anything for the reason you mention.

For the moment we could probably suggest that this kind of attack, while extremely worrying, is limited to well-funded adversaries targeting very specific people. If this is the case then you are pretty much screwed.

In order for malware to exploit this method of infection in a more general fashion, surely there are some pretty hefty technical obstacles to overcome? How would an adversary target a machine with unknown hardware / unknown bios / unknown OS.

Someone able to do this may equally find a nice way of causing the online Armory to circumvent any air-gap-transmission system (display QR codes / output audio) to exploit a vulnerability in the offline armory.

Of course I would however never ever run Armory on Windows and would definitely prefer a bootable CD/DVD environment  such as https://bitcointalk.org/index.php?topic=233453.0