>> 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)
Reply by Theo Markettos●September 11, 20162016-09-11
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
Reply by acd●September 10, 20162016-09-10
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
Reply by Les Cargill●September 10, 20162016-09-10
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
Reply by Don Y●September 9, 20162016-09-09
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.
Reply by Les Cargill●September 9, 20162016-09-09
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
Reply by Don Y●September 7, 20162016-09-07
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".
Reply by Theo Markettos●September 7, 20162016-09-07
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 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.
Theo
Reply by Don Y●September 7, 20162016-09-07
On 9/7/2016 12:07 PM, Les Cargill wrote:
> Not to be snide, but I prefer to make things that work and don't
> have to be updated. It's cheaper that way. I know this
> isn't always possible but I bet it's more possible than you think.
+42
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.
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.
[I recently bricked a print server because "wait for the
device to reboot" REALLY meant "wait for the better portion
of a *minute* for the device to reboot". AND, the device
had no provision for resuming an aborted update: start it
and you are committed to finishing it!]
It typically takes a fair bit of time to update *a* single device:
- discover that an update is available
- decide if the update is worth installing
- discover if the update is *applicable* (version currently running?)
- download the update (make sure the download protocol alerts the
user if the download was prematurely aborted! make sure BINARY/ASCII
mode doesn't impact the payload; etc.)
- set up the update environment (special cables? disconnect peripherals?)
- perform the update
- verify the result (you *did* include a means whereby the user can
identify the NEW version of the software installed, right?)
All assuming nothing goes wrong in the above.
If (when!) something goes wrong, is there a way to recover? To restart
the upgrade (have you documented EVERYTHING the user needs to do in
order to restart? E.g., my print server case required me to reset
the deviec so it would repeat the BOOTP discovery sequence)
If (when!) something goes wrong, is there a way to return to the previous
configuration?
If you later decide the upgrade was a "mistake" (you are not happy
with it -- or, it is buggier than your previous version, you've lost
some capability, etc.), is there a way to DOWNgrade?
Are all of your configuration choices seemlessly propagated forward to the
new implementation?
Repeat this for (potentially) *all* of your customers. How many will
pick up a phone and call "support" somewhere in this process? Or, send
an email asking for clarification/assistance? How many will render their
devices useless? How many of those will complain to you about your
"crappy software"? What will all of this cost *you*?
And, more importantly, what will it cost *them*? How eager will you be to
move yet another upgrade out to them? How eager will they be to go through
this effort AGAIN? When will they start thinking, "Why didn't the device
ALREADY have these features/capabilities WHEN I BOUGHT IT?"
> Weasel out of iffy requirements with configuration, mostly. Test the
> crap outta the thing - it's always cheaper than you think.
If you're confident an upgrade will NOT be needed to fix a latent bug
in your code, then put your money where your mouth is: challenge your
colleagues to see if they can find any bugs (in the product's use
*or* from an inspection of the sources). I routinely bake goods for
friends/colleagues willing to spend some time hammering on something I've
decided is "done" -- a reasonably fair trade (a few hours of their time
vs. a few hours of me baking). If someone finds something significant,
it would be a BARGAIN to treat them to a steak dinner -- "out".
If you find yourself "buying lots of dinners" -- or, "rationalizing
their (legitimate) comments away" -- then your process needs some serious
rethinking!
*Cherish* your customers' time -- because *they* do! Treat them with
disdain and a competitor will lure them away in a heartbeat ("Our
product WORKS!")
Reply by Les Cargill●September 7, 20162016-09-07
This decision is more based on what resources the target has.
It's also about the use cases for updates you expect to support.
Not to be snide, but I prefer to make things that work and don't
have to be updated. It's cheaper that way. I know this
isn't always possible but I bet it's more possible than you think.
Weasel out of iffy requirements with configuration, mostly. Test the
crap outta the thing - it's always cheaper than you think.
If an "update" is shooting a new set of config options at the target,
your life is less interrupted.
If you need to make that look like an upgrade, then do that.
pozz wrote:
> I'm designing a small electronic gadget with a USB device port.
>
> Now I'm thinking about a good method to upgrade the firmware through the
> USB. The process should be as simple as possible for the user.
>
> I think there are three main method, each one with pros and cons.
> In all of them, the user should only press a button while the device is
> connected to the host (so powered up). At startup, the switch is sensed
> and, if pressed, the bootloader enters or stop running the application.
>
> CDC
> The device is seen as a COM port from the host. IMHO this is the
> simplest method for the developer, but has many cons.
> First of all, the user should be able to read the COM port number
> assigned by the host to the device. However I don't know if it is
> really true. Is it possible to write a software that automatically
> detects if my USB CDC gadget is connected and automatically communicate
> to it without knowing the COM port number (or automatically detect it)?
> Second, the user should install a driver when the device is attached (at
> lest in Windows, the driver is a .inf file only).
> Third, a software must be installed on the host to communicate with the
> bootloader.
>
> DFU
> It seems USB defined a DFU standard for firmware upgrade through USB
> connection. If I understood well, even in this case the user should
> install a driver and should use a custom tool to manage the firmware
> upload process.
>
SFAIK, this may preclude using the USB port as a serial port. It may
not.
Ardunios use essentially an FDTI driver for both. It's a good
approach, IMO. But Ardunios don't have a file system and use what
appears to be a monolithic download image.
Cubie boards ( and I believe Beaglebone Black ) use this as an OTB port.
You can then reflash ( soft-debrick ) the unit that way. I forget what
happens when that goes wrong, you may need a JTAG/ODB type thing.
> MSD
> I think this is the simplest method for the user.
> The host sees the device as a removable disk with a virtual filesystem
> in it (usually it is FAT12 that is the simplest to implement in the
> device).
> The firmware upgrade process is only to drag the new file to the root
> folder.
> The only issue I see here is how to report the result of firmware
> upgrade (success or error) to the user. He can only see a list of files.
> I can think to create a virtual file, such as SUCCESS.TXT or ERROR.TXT
> or other similar names, when the firmware upgrade ends. However the
> host OS could cache the content of the virtual disk, so hiding the new
> virtual files.
>
If you have the resources, sure. You still need a debrick strategy.
> Maybe there are other methods. Which one do you prefer?
Prefer? Something more like bootp. SLIP[1] the surly bonds
of serial ports.... then when you plug it in, it Just Updates.
[1] or PPP...
This may be a challenge for cases where users or techs have to update
units in the field. But maybe you have an Official(tm) Li'l Upgrade Box
or something.
--
Les Cargill