USB device bootloader: which method do you prefer?

On 9/7/2016 4:47 PM, Theo Markettos wrote:
> Don Y <blockedofcourse@foo.invalid> wrote:
>> Too often, APPROACHING a product with the "upgrade path" foremost
>> in mind suggests a lack of confidence in:
>> - knowing what the customer wants
>> - knowing what the product should *be*
>> - your implementation
>> - some combination of the above
>>
>> IME, "upgrades" are stressful experiences to most users.
>
> Unfortunately, if your device has connectivity this doctrine no
> longer applies.  In the brave new IoT world security threats will evolve and
> vulnerabilities will happen.  While there are sensible mitigation
> strategies, you can't plan for the discovery of vulnerabilities in advance.
>
> Therefore you had better get used to an upgrade path and make it bomb-proof
> because you will be using it.  Or if you aren't you're almost certainly
> should be.  Unless you have a really good threat model as to why your gadget
> isn't worth targeting (including using it as a springboard to attack other
> things).

The first thing you can do is implement ONLY what is needed.  And,
UNDERSTAND that implementation!  I.e., if you're just "lifting"
code (e.g., a network stack) out of "something else" (FOSS),
then it's probably safe to say you've got more cruft than you
actually need!  More things that can contain latent bugs; more
levers that exploits can flip.

Ask yourself OBVIOUS questions:
- do you need support for all these protocols?
- will your device NEED to talk to a wider ecosystem?  Or, just
   other devices of YOUR design/manufacture?
- will you NEED to support N concurrent connections?
- is your deployed environment STATIC?
etc.

Chances are, you've got far more cruft in your device than
you actually *need*.

By eliminating cruft that you *don't* need, you eliminate
things that you (should, otherwise) understand!  And, things
that you WOULD, otherwise, have to test.

E.g., my home automation devices KNOW they will never be talking
to anything other than my OTHER home automation devices.  No
need to support name services, filesystems, exports, etc.  No
need for an ARP cache -- its contents should be const!  etc.  As
a result, I can apply really robust tests to network transactions
and KNOW that anything out-of-the-ordinary is either:
- a bug
- an attempted exploit
There are no other "benign" possibilities (that a more generic
network implementation would "tolerate"):
    "Um, why are you sending me these ICMP messages?  That's
    not part of the product specification.  Go away, bad thing!"

>> The process is *rarely* "well documented" (i.e., instead of
>> saying "wait for the light to start blinking", you should
>> be saying "wait 7 seconds (not 6 and not 8) for the light
>> to start blinking".  *All* the details need to be nailed
>> down so the user doesn't wonder "how long should I wait?",
>> "is it doing what it *should* be doing?"  etc.
>
> To be honest UIs on these things are often terrible.  If you really want to
> communicate with the user, put a display on it and tell them, don't try to
> use Morse code.  But that costs money.

Even where the UI already exists, "upgrades" are seldom painless.

I have to upgrade the BIOS on a bunch of little diskless workstations
I have, here.  I can plug in a keyboard, mouse, display, etc.
I can boot a full-fledged OS, etc.  Yet, it's taken me several
hours to figure out why the upgrades won't install!  Even googling
for an explanation of the error message turns up nothing.
(Hence my admonition to document EVERYTHING)

If I was *reliant* on this upgrade (e.g., to patch an exploit as you've
outlined above), I'd be increasingly "anxious" that the upgrade
wasn't "taking".

Theo Markettos wrote:
> Don Y <blockedofcourse@foo.invalid> wrote:
>> Too often, APPROACHING a product with the "upgrade path" foremost
>> in mind suggests a lack of confidence in:
>> - knowing what the customer wants
>> - knowing what the product should *be*
>> - your implementation
>> - some combination of the above
>>
>> IME, "upgrades" are stressful experiences to most users.
>
> Unfortunately, if your device has connectivity this doctrine no
> longer applies.  In the brave new IoT world security threats will evolve and
> vulnerabilities will happen.  While there are sensible mitigation
> strategies, you can't plan for the discovery of vulnerabilities in advance.
>

Oh, I know. I suppose there's some fun in that but I'm doing everything
in my power to avoid the entire edifice. And I mean "avoid" in both the
consumer role and as a developer.

Alphabet's "retirement" of that Nest thermostat tells me everything I
need to know about that niche. It's not designed to create consumer 
surlpus at all, but to appeal to the ego of what passes for "tech 
companies" these days. Gotta keep the l33t hax0rs busy; idle hands
you know...

Second, when people did on the high seas what system crackers do
over the internets, it was called "piracy". At least the British
Empire had "ships of the line" to hunt them down and hang them
from yardarms.

Instead, we treat them as clever children and encourage them.

Heads on pikes outside the city gates, I say. Invoke Mossad-style
hit squads...

> Therefore you had better get used to an upgrade path and make it bomb-proof
> because you will be using it.

Not so much; no. I can check for WiFi or Ethernet and simply *not buy* 
the damned thing. Or cut certain traces is you can't avoid it any more.

> Or if you aren't you're almost certainly
> should be.

I think you've made an excellent case for *not* needing it.

> Unless you have a really good threat model as to why your gadget
> isn't worth targeting (including using it as a springboard to attack other
> things).
>
>> The process is *rarely* "well documented" (i.e., instead of
>> saying "wait for the light to start blinking", you should
>> be saying "wait 7 seconds (not 6 and not 8) for the light
>> to start blinking".  *All* the details need to be nailed
>> down so the user doesn't wonder "how long should I wait?",
>> "is it doing what it *should* be doing?"  etc.
>
> To be honest UIs on these things are often terrible.

Horrid. That's why the best UI is no UI at all.

I dunno if you've looked at TR-069 but Good Lord, what a 
cluster[expletive deleted]. Oh yeah, that's So Much Better than, say 
SNMP....

> If you really want to
> communicate with the user, put a display on it and tell them, don't try to
> use Morse code.  But that costs money.
>

:)

> Theo
>

-- 
Les Cargill

On 9/9/2016 1:11 PM, Les Cargill wrote:
> Theo Markettos wrote:
>> Don Y <blockedofcourse@foo.invalid> wrote:
>>> Too often, APPROACHING a product with the "upgrade path" foremost
>>> in mind suggests a lack of confidence in:
>>> - knowing what the customer wants
>>> - knowing what the product should *be*
>>> - your implementation
>>> - some combination of the above
>>>
>>> IME, "upgrades" are stressful experiences to most users.
>>
>> Unfortunately, if your device has connectivity this doctrine no
>> longer applies.  In the brave new IoT world security threats will evolve and
>> vulnerabilities will happen.  While there are sensible mitigation
>> strategies, you can't plan for the discovery of vulnerabilities in advance.
>
> Oh, I know. I suppose there's some fun in that but I'm doing everything
> in my power to avoid the entire edifice. And I mean "avoid" in both the
> consumer role and as a developer.
>
> Alphabet's "retirement" of that Nest thermostat tells me everything I
> need to know about that niche. It's not designed to create consumer surlpus at
> all, but to appeal to the ego of what passes for "tech companies" these days.
> Gotta keep the l33t hax0rs busy; idle hands
> you know...

Nest's stupidity was in designing the device with the intent of
it talking to a server that *they* controlled.  And, coming up
with a rationalization for why that would be "necessary".

Philips has some lighting products that have headed down the
same path.

Why can't *I* talk to *my* devices without THEIR needing
some intermediary?

> Second, when people did on the high seas what system crackers do
> over the internets, it was called "piracy". At least the British
> Empire had "ships of the line" to hunt them down and hang them
> from yardarms.

Ocean is a lot smaller than the Internet!  And, relatively easy
to identify "ports of call" that they MUST routinely visit to
resupply.  A pirate operating on the east coast can't "suddenly"
move to the west coast cuz the heat's turned up (but a hacker
can appear on the other side of the globe, in an instant!)

> Instead, we treat them as clever children and encourage them.
>
> Heads on pikes outside the city gates, I say. Invoke Mossad-style
> hit squads...

We also do nothing to REALLY motivate designers to design more
robust products.  If my router gets hacked, can I recover damages
from the manufacturer?  If my bank account gets hacked?  If
my medical records?  Voter registration?  etc.?

>> Therefore you had better get used to an upgrade path and make it bomb-proof
>> because you will be using it.
>
> Not so much; no. I can check for WiFi or Ethernet and simply *not buy* the
> damned thing. Or cut certain traces is you can't avoid it any more.

Unfortunately, you may not have that option if, for example,
those traces bring some "needed functionality" to the device.

Don Y wrote:
> On 9/9/2016 1:11 PM, Les Cargill wrote:
>> Theo Markettos wrote:
>>> Don Y <blockedofcourse@foo.invalid> wrote:
>>>> Too often, APPROACHING a product with the "upgrade path" foremost
>>>> in mind suggests a lack of confidence in:
>>>> - knowing what the customer wants
>>>> - knowing what the product should *be*
>>>> - your implementation
>>>> - some combination of the above
>>>>
>>>> IME, "upgrades" are stressful experiences to most users.
>>>
>>> Unfortunately, if your device has connectivity this doctrine no
>>> longer applies.  In the brave new IoT world security threats will
>>> evolve and
>>> vulnerabilities will happen.  While there are sensible mitigation
>>> strategies, you can't plan for the discovery of vulnerabilities in
>>> advance.
>>
>> Oh, I know. I suppose there's some fun in that but I'm doing everything
>> in my power to avoid the entire edifice. And I mean "avoid" in both the
>> consumer role and as a developer.
>>
>> Alphabet's "retirement" of that Nest thermostat tells me everything I
>> need to know about that niche. It's not designed to create consumer
>> surlpus at
>> all, but to appeal to the ego of what passes for "tech companies"
>> these days.
>> Gotta keep the l33t hax0rs busy; idle hands
>> you know...
>
> Nest's stupidity was in designing the device with the intent of
> it talking to a server that *they* controlled.

And if Annhauser-Busch built a bar, what sort of beer you think they'd 
sell?

> And, coming up
> with a rationalization for why that would be "necessary".
>
> Philips has some lighting products that have headed down the
> same path.
>

Yup.

> Why can't *I* talk to *my* devices without THEIR needing
> some intermediary?
>

Derp de derp de derp derp derp!

>> Second, when people did on the high seas what system crackers do
>> over the internets, it was called "piracy". At least the British
>> Empire had "ships of the line" to hunt them down and hang them
>> from yardarms.
>
> Ocean is a lot smaller than the Internet!

Nonsense. It's that same damn thing. Oceans got progressively smaller 
anyway.

DID NOBODY READ HORATIO HORNBLOWER BOOKS AS A KID?

Geez :")

> And, relatively easy
> to identify "ports of call" that they MUST routinely visit to
> resupply.  A pirate operating on the east coast can't "suddenly"
> move to the west coast cuz the heat's turned up (but a hacker
> can appear on the other side of the globe, in an instant!)
>

I don't care where they are. I'd just support their... elimination,
toothsweet.

Consumerism is hanging by a thread; if anything was in the public
interest, the rapid and efficient dispatch of network pirates would
seem to be .. one of those things.

Unless you think that advancing the interest in Security(tm) to
toasters somehow creates you a business model...

This is what's called a "bootleggers and baptists" situation.

>> Instead, we treat them as clever children and encourage them.
>>
>> Heads on pikes outside the city gates, I say. Invoke Mossad-style
>> hit squads...
>
> We also do nothing to REALLY motivate designers to design more
> robust products.

Of course not. And why would we? I just do it out of stubbornness.

> If my router gets hacked, can I recover damages
> from the manufacturer?  If my bank account gets hacked?  If
> my medical records?  Voter registration?  etc.?
>
>>> Therefore you had better get used to an upgrade path and make it
>>> bomb-proof
>>> because you will be using it.
>>
>> Not so much; no. I can check for WiFi or Ethernet and simply *not buy*
>> the
>> damned thing. Or cut certain traces is you can't avoid it any more.
>
> Unfortunately, you may not have that option if, for example,
> those traces bring some "needed functionality" to the device.
>

Then I shall do without it.

-- 
Les Cargill

Am Donnerstag, 8. September 2016 01:47:05 UTC+2 schrieb Theo Markettos:

> Unfortunately, if your device has connectivity this doctrine no
> longer applies.  In the brave new IoT world security threats will evolve and
> vulnerabilities will happen.  While there are sensible mitigation
> strategies, you can't plan for the discovery of vulnerabilities in advance.
> 

Doesn't the capability to update the firmware open a plethora of security risks
that are even more difficult to fix than that of your application?

Andreas

acd <acd4usenet@lycos.de> wrote:
> Am Donnerstag, 8. September 2016 01:47:05 UTC+2 schrieb Theo Markettos:
> 
> > Unfortunately, if your device has connectivity this doctrine no
> > longer applies.  In the brave new IoT world security threats will evolve and
> > vulnerabilities will happen.  While there are sensible mitigation
> > strategies, you can't plan for the discovery of vulnerabilities in advance.
> > 
> 
> Doesn't the capability to update the firmware open a plethora of security risks
> that are even more difficult to fix than that of your application?

That's easy to fix.  Just use signed firmware, and check the signature before
updating.

It does require a bit of care with your signing keys but it's not rocket
science.  Though it doesn't necessarily prevent regression to older firmware
(which might contain vulnerabilities).

(putting aside for a moment the argument that I as purchaser should have the
right to determine the software running on hardware I own)

Theo

On 9/11/2016 10:47 AM, Theo Markettos wrote:
>> Doesn't the capability to update the firmware open a plethora of security risks
>> that are even more difficult to fix than that of your application?
>
> That's easy to fix.  Just use signed firmware, and check the signature before
> updating.
>
> It does require a bit of care with your signing keys but it's not rocket
> science.  Though it doesn't necessarily prevent regression to older firmware
> (which might contain vulnerabilities).

A "version number" tag in the file could be examined to ensure this
isn't allowed.

Or, a key in the new image can effectively render all but the *next*
(sequential) upgrade "incompatible".

But, there's still no guarantee that you won't get pwned.  Note how
many "big players" seem to be unable to prevent their products from
being repurposed, rooted, etc.

> (putting aside for a moment the argument that I as purchaser should have the
> right to determine the software running on hardware I own)