5

How many of you have actually updated their mouse, keyboard or USB stick firmware? How many vendor actually propose updates for such devices?

However these devices firmware often offer a proprietary update feature.

Why is it so? What is the expected use of such feature? Is it some kind of debugging facility left by the manufacturer in the firmware code as "safe because nobody will find it", or in another words can this be seen a backdoor left by the manufacturer in consumers products?

To be precise I use the term "backdoor" as its root definition: I do not necessarily imply any malicious intent from the manufacturers, a backdoor being not necessarily malicious in its intent... even-though they are often heavily damageable when they are just caused by manufacturer's carelessness.

  • How is this a "backdoor"? Unless the device is phoning home regularly, or starting up a listening service, the manufacturer (or anyone else for that matter) doesn't have access to it except by user-initiated actions (like downloading and running a firmware updater program, or another program designed to act like one). – Iszi Aug 19 '15 at 13:17
  • @Iszi That's why I felt necessarily to highlight that I was not focusing on malicious backdoors, but that I was talking about backdoor in general (as service accesses), ie. an undocumented feature unknown to the end-user and allowing someone to proceed with actions which would normally not be possible. Such feature can exists for reasons as simplifying technical support, provide debug facilities during the development process, etc. Wikipedia highlights this difference, linking to an interesting article to illustrate this (footnote 3). – WhiteWinterWolf Aug 19 '15 at 13:34
  • @Iszi: My concern here is that sometimes, by laziness, carelessness and/or attempt to reduce costs, manufacturers include backdoors in their software which may have very wrong consequences. A similar example is the D-Link routers backdoors: it was not malicious, designed to make the configuration software development more easy, but in final allows anybody to get control of the router simply by forging the user-agent to a specific value... – WhiteWinterWolf Aug 19 '15 at 13:41
  • My point still remains that it's really not a backdoor - at the very least, it's not at all an effective one. Without phoning home or running a listener, someone would need physical access to your device (or to trick you into running a Trojan) in order to modify its firmware. Having a non-automatic update capability built into a device is a very far cry from including a remote access tool. It's not even remotely close to being similar to the D-Link backdoor. If anything, it's actually a front door - something intended for end-user use to begin with. – Iszi Aug 19 '15 at 14:25
  • @Iszi: I think we agree while not understanding ourselves ;). I did not meant a backdoor to access the computer, I meant a backdoor left by firmware developers in order to easily access the device internals :). Regarding the front door, the fact that there is no security except by obscurity and that end-users need to get their hands on leaked firmwares and flash tools leads me to mitigate this assertion (specially for dumb devices which are of the most concern here). – WhiteWinterWolf Aug 20 '15 at 9:54
5

Everything is buggy. Hardware, software, firmware, wetware. Everything.

Most of the time those bugs fall within acceptable limits. Whatever computer you're using, for example, probably has 5-20 BIOS updates, depending upon how old it is. And for most people, they can be many updates behind without problems - because the bugs fixed by later versions either don't impact them or aren't catastrophic.

Sometimes bugs are more serious, and need to be fixed before something can be shipped / sold. It would suck to manufacture a million USB thumbdrives, for example, then be forced to throw them out at a loss because of a bug that surfaced. The manufacturer would be much better off if they were able to compensate for the bug (and firmware can often compensate for hardware problems, not just firmware problems).

So the general rule is to design systems that have a little update-ability, even if the normal lifecycle of the product isn't expected to require it.

Because everything is buggy.


WhiteWinterWolf asks this followup question in the comments:

In the Black Hat presentation by Karsten Nohl and Jakob Lell, the solution presented as the most simple and effective one would be to lock the firmware down at the factory, blocking any firmware update. Following your answer, do you think that such possibility would therefore be not very realistic "in the real world"?

Now we're purely into speculation territory. Here's my opinion:

Locking the firmware is a technical solution, but it's one that will only be embraced at the very low end (cheap, throwaway devices) and the very high end (security-focused marketing). The vast middle will continue to ship writable devices because the business case edges out the security case.

Let me tell you how I got there:

Locking the firmware has positive (increased security) and negative (inability to update to correct issues as described above) impacts.

At the very low end - where you can buy an 8 GB thumb drive for $2 - the inability to update is less of a problem. In all likelihood, the manufacturer is relatively generic, and won't mind the PR hit for having a buggy device that can't be updated. And at that price, consumers are more likely to toss it in the trash and buy something else than they are to look for an update.

So the security benefit outweighs the business cost at the low end. (Whether low end manufacturers can be convinced to take such a simple step is another question; by definition, they care less about the consumer, because they're not building brand loyalty).

At the other end of the spectrum, there are companies who market themselves as security-before-everything-else providers. IronKey, for example, sells devices that wipe themselves if the wrong password is entered too many times, and which are baked in epoxy to prevent physical access. For them to offer the trade-off of locked firmware (no updates, but less insecurity) is fine - that's their value proposition. Their customers would rather throw expensive devices away than have security risks that could be avoided.

As for everyone between those two extremes...

Picture a presentation being given around a board room. The presenter says, "We can improve our client's security, against a very unusual niche attack, by locking our hardware so that updates aren't possible. There is a possibility this could cause high rates of product returns, negative publicity, and general damage to our brand. We are here to decide whether to protect ourselves or a small, unknown subset of our customer base against an unknown potentiality."

They're going to vote to do the right thing for the company, not for the hypothetical individual customer. And they're going to keep shipping things they can update.

Just my 2 cents (which is good enough to buy a 256 MB thumb drive these days).

  • In the Black Hat presentation by Karsten Nohl and Jakob Lell, the solution presented as the most simple and effective one would be to lock the firmware down at the factory, blocking any firmware update. Following your answer, do you think that such possibility would therefore be not very realistic "in the real world"? – WhiteWinterWolf Aug 20 '15 at 10:03
  • @WhiteWinterWolf I've updated the Answer to address your followup (was too long to fit into a comment!) – gowenfawr Aug 20 '15 at 12:14
2

USB sticks are composed of several different electronical and logical modules. Combined, these modules can cater certain technological requirements that are necessary to constitute portable storage. These modules can be bought in bulk and are as generic as possible so that the manufacturer can sell them to as many buyers as possible without needing a ridiculous amount of production diversity.

So, for example, we have a company called ScanDisk that wishes to manufacture portable flash drives. ScanDisk will buy memory chips, PCB's, quartz clocks and, most importantly, a controller. In order to have these components work together in a meaningful way with a computer, ScanDisk will have to load firmware on the controller.

These controllers come in all shapes and sizes, some allowing more complicated firmware than others. In all cases it's necessary for the controller to be writeable in one way or the other, a USB drive that's just been put together won't have any functionality until the controller is provisioned with firmware. It's cheaper for both the manufacturer and the buyer to allow firmware flashes via the USB port, and really, requiring a special port that is encased in the housing won't rule out any attacks whatsoever.

As for securely designed controllers... it's certainly not cheaper than you average wholesale chip, so it's not hard to guess which one's preferred.

  • Does this mean that the update feature is not actually embedded in the manufacturer's firmware code, but is stored somewhere else outside of the firmware provider's hand? I thought that this functionality was precisely handled by the firmware (allowing malicious firmwares to cheat inspection and overwrite attempts)... – WhiteWinterWolf Aug 19 '15 at 15:19
  • 1
    Usually it's a functionality in the design of the chip and is described in the documentation. If you Google for the documentation of a more complex chip (like the USB controller) you will find details on how to load firmware on there. Usually it involves setting the chip in write mode by sending a certain signal and from there on the computer can send hex/bytecode straight into the controller's internal 'ROM' (which isn't really Read Only at this point, but alas), the write operation is then closed with another particular signal. – Chavez Aug 20 '15 at 7:16
  • Indeed, there is on one side the USB chip producer which provides a framework "containing the necessary firmware code for USB operation and providing a placeholder for the user's code", and on the other side the device manufacturer which will rely on this framework to develop his USB device (thumb drive, mouse, printer, etc.). Unless the framework propose a specific option (a bit to switch for instance) to disable firmware overwrite, then the chip should just be rewriteable using the right framework. – WhiteWinterWolf Aug 23 '15 at 17:21
  • Too sad the bounty system doesn't allows me to give you the equivalent of a "good answer" rep, I think it nicely complete gowenfawr's answer by giving a better view "behind the scene" while he explains why the current situation will most likely not change in the near future due to the need of firmware updates as "plan B" for the device manufacturers. – WhiteWinterWolf Aug 23 '15 at 17:35
1

How many of you have actually updated their mouse, keyboard firmware? How many vendor actually propose updates for such devices?

I've updated my mouse and keyboard firmware on several occasions. It's quite common among devices created for and targeted at the gaming community. These devices are can be quite advanced and use technology that wouldn't exist in a common consumer grade mouse. For example, SteelSeries makes a mouse with an embedded 32 bit ARM processor and mini LCD screen on the underside of the mouse. It's the same story with keyboards. Embedded processors and RAM for storing macros, profiles, etc. As with any hardware device, compatibility issues can arise with the myriad of hardware combinations possible which necessitates the need to update the firmware of these devices.

  • Complex hardware have greater chances to need updates, but I guess that complex hardware where updates are expected and which benefit from greater computation possibilities handle this properly by checking (cryptographic signature for instance) the pushed updates before writing it to their memory. Maybe I'm wrong, but I suppose that dumb USB devices are more prone to BadUSB attacks than high-end complex devices. – WhiteWinterWolf Aug 19 '15 at 13:48
  • @WhiteWinterWolf, Private keys can leak or get lost; physical security is better. I know of no HID with such protection against updating firmware, though. – Cees Timmerman Aug 21 '15 at 9:32
  • @CeesTimmerman "get lost": I could hardly imagine such an incompetent device producer loosing its own private keys, "can leak": possible, but I never heard such story yet, however I heard stories of people reverse engineering the firmware and finding flaws in the update procedure allowing to rewrite the firmware despite the signature check. Physical security is better from a pure security point of view, but may not be practical for casual users and would cost even more to produce especially when firmware updates is just a "plan B" and are not expected unless something goes very wrong. – WhiteWinterWolf Aug 21 '15 at 10:00

protected by Rory Alsop Feb 11 '17 at 18:41

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.