<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 1, 2014 at 4:34 PM, Jerry Leichter <span dir="ltr"><<a href="mailto:leichter@lrw.com" target="_blank">leichter@lrw.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">On Aug 1, 2014, at 1:11 PM, Joe St Sauver <<a href="mailto:joe@oregon.uoregon.edu">joe@oregon.uoregon.edu</a>> wrote:<br>

> #I dunno how to fix this. The best I can come up with is to make more of<br>
> #these exploits happen - post anonymous bounties to get firmware and<br>
> #schematics leaked?<br>
><br>
> Use of non-rewritable ROMs would obviously "fix" the vulnerability (for<br>
> some definition of "fix," but that assumes you can produce flawless code<br>
> that might never need to be patched or updated (or that you can live with<br>
</div>> pitch-and-replace (rather than patch ) as an update/remediate strategy)....<br>
How many USB devices have ever been patched after sale?  I know of one example, which I mentioned in my original posting:  The Apple aluminum keyboard, introduced in August of 2007, has received exactly one update during its lifetime.<br>

<br>
I, personally, know of no other examples.  If anyone else does, I'd like to hear about them.<br>
<br>
USB devices are generally pretty cheap.  There's little motivation to publish patches - there's no general way to reach users, you have to worry about whether the users even have a system they could use to patch the device, and most will never bother anyway.  So for your expense you gain nothing in the market.  It's hard enough (effectively impossible) to get more complex, expensive devices like WiFi routers patched in the field - typical USB devices are just not worth thinking about.  (Apple could even *consider* doing a patch because it had an easy pathway to push patches out to all Apple systems, thus capturing most Apple keyboards.)<br>

<br>
Doing patching on devices still at the factory, or even in the supply chain, might be more realistic - but most organizations these days run such lean supply chains that the fraction of devices you could actually get to this way is tiny.  Hardly worth the effort except maybe at initial release.<br>

<br>
So, yes, for pretty much all USB devices, the code that was initially installed will be the code that's in the device until it's discarded.  It has to be "right enough".<br>
<br>
I suspect most "patchable" devices are that way because that was the interface used to upload their firmware to begin with, and it's not considered worth the cost to lock out later uploads, even if there's no realistic change there will ever be a need for them.<br>

<span class=""><font color="#888888"><br>
                                                        -- Jerry<br></font></span></blockquote><div><br></div><div class="gmail_default" style="font-size:small">​This phenomena is not unique to USB, but applies to essentially any device in which there is a embedded processor, which, besides the base system firmware image in embedded devices, may include your disk drive, flash drive, wireless module, keyboard modules, and so on. ​ Devices you think of as "single chips" are often SOC's + flash + a bit of custom stuff these days. </div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">We did this mostly right at OLPC for the base firmware , where the boot loader's write enable was/is protected by a D flop; the boot loader first checks if there is a properly signed update for itself on boot, and otherwise immediately locks the boot loader flash down hard (until reset at next power up).  So a bad guy cannot put an implant into the boot loader without access to the keys.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The bootloader is also able to check that the image being booted is signed appropriately, and also has facilities for unlocking the bootloader and system image for hacking and debugging (possibly after a delay to deter theft, which is a serious issue in some parts of the world; a scenario most do not have).  That such firmware be unlockable if you have possession of the device is actually needed as you have no other way to ensure that the system has not been tampered with in transit or via malware, or recovery after disaster, where you may not have a network for updating.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Even flash chips with sector "protection" have typically ways to unlock those sectors from software, so if you compromise the OS appropriately, you can unlock those sectors, typically by poking a bit in a register some place.  I recently chatted with a friend responsible for the later OLPC systems who recently was unable to find flash with suitable one way write protect features.  But a separate serial boot rom and D flop is around $.28 cents, and is probably easier to trust.  In principle though, the additional cost should be zero, if you can trust the flash chips you use.<br>
</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The NSA TAO catalog makes clear that such unprotected firmware is rife for all sorts of mischief, persistent implants being some of the most pernicious.<br>
</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">                                                   Sigh,</div><div class="gmail_default" style="font-size:small">
                                                            - Jim</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">"Friends don't let friends run factory firmware."</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div></div></div></div>