Sanity check time- Firmware exploits as new vector for cyberattack?
http://www.darkreading.com/document.asp?doc_id=154270&WT.svl=news1_1 Bull or danger? -- Oren Beck 816.729.3645
Making a broken firmware image would be very easy. Start with the real one, and corrupt it. Scripting access to the firmware update feature, also trivial. So change the password on your netgear muffin whenever a stranger jostles you on the bus. On Tue, May 20, 2008 at 11:34 PM, Oren Beck <orenbeck@gmail.com> wrote:
http://www.darkreading.com/document.asp?doc_id=154270&WT.svl=news1_1
Bull or danger?
Hey, how about a worm that infects your cable modems and uncaps them for you? ;)
Of course it's a danger. If you build hardware that allows the firmware to be updated remotely, you're vulnerable to malware that deliberately bricks it. Good design for firmware would put a very minimal block of code in true ROM, which would be sufficient to load a firmware update into flash memory. It might require physical access to a special switch to do that, but it would prevent bricking the hardware due to a bad flash operation, whether malicious or merely accidental. Another option is to include a large public RSA key for the hardware manufacturer in the ROM, which would be used to authenticate any firmware updates. Since that smacks of "tivoization", I'd say allowing the owner of the hardware to bypass that with the aforementioned physical switch would probably be a good bet; just use the RSA key to validate remotely loaded updates. On Tue, May 20, 2008 at 11:34 PM, Oren Beck <orenbeck@gmail.com> wrote:
http://www.darkreading.com/document.asp?doc_id=154270&WT.svl=news1_1
Bull or danger?
-- Oren Beck
816.729.3645 _______________________________________________ Kclug mailing list Kclug@kclug.org http://kclug.org/mailman/listinfo/kclug
If you're worried about remote firmware updating, look up redboot, and quiver at the thought of all the network attached hardware that uses it or something similar. On Wed, May 21, 2008 at 1:16 PM, Monty J. Harder <mjharder@gmail.com> wrote:
Of course it's a danger. If you build hardware that allows the firmware to be updated remotely, you're vulnerable to malware that deliberately bricks it.
Good design for firmware would put a very minimal block of code in true ROM, which would be sufficient to load a firmware update into flash memory. It might require physical access to a special switch to do that, but it would prevent bricking the hardware due to a bad flash operation, whether malicious or merely accidental.
Another option is to include a large public RSA key for the hardware manufacturer in the ROM, which would be used to authenticate any firmware updates. Since that smacks of "tivoization", I'd say allowing the owner of the hardware to bypass that with the aforementioned physical switch would probably be a good bet; just use the RSA key to validate remotely loaded updates.
On Tue, May 20, 2008 at 11:34 PM, Oren Beck <orenbeck@gmail.com> wrote:
http://www.darkreading.com/document.asp?doc_id=154270&WT.svl=news1_1
Bull or danger?
-- Oren Beck
816.729.3645 _______________________________________________ Kclug mailing list Kclug@kclug.org http://kclug.org/mailman/listinfo/kclug
_______________________________________________ Kclug mailing list Kclug@kclug.org http://kclug.org/mailman/listinfo/kclug
On Wednesday 21 May 2008, Billy Crook wrote:
If you're worried about remote firmware updating, look up redboot, and quiver at the thought of all the network attached hardware that uses it or something similar.
RedBoot is easily configured to not connect to a network. Usually this is the factory config. On the other hand, recent La Foneras appear to come with a 5 sec boot wait ;)
The physical switch is both the best possible choice, and the only one which will never be acceptable to a proprietary company because it gives power to the consumer. --- "Monty J. Harder" <mjharder@gmail.com> wrote:
Of course it's a danger. If you build hardware that allows the firmware to be updated remotely, you're vulnerable to malware that deliberately bricks it.
Good design for firmware would put a very minimal block of code in true ROM, which would be sufficient to load a firmware update into flash memory. It might require physical access to a special switch to do that, but it would prevent bricking the hardware due to a bad flash operation, whether malicious or merely accidental.
Another option is to include a large public RSA key for the hardware manufacturer in the ROM, which would be used to authenticate any firmware updates. Since that smacks of "tivoization", I'd say allowing the owner of the hardware to bypass that with the aforementioned physical switch would probably be a good bet; just use the RSA key to validate remotely loaded updates.
On Tue, May 20, 2008 at 11:34 PM, Oren Beck <orenbeck@gmail.com> wrote:
http://www.darkreading.com/document.asp?doc_id=154270&WT.svl=news1_1
Bull or danger?
-- Oren Beck
816.729.3645 _______________________________________________ Kclug mailing list Kclug@kclug.org http://kclug.org/mailman/listinfo/kclug
_______________________________________________
Kclug mailing list Kclug@kclug.org http://kclug.org/mailman/listinfo/kclug
On Wednesday 21 May 2008, Oren Beck wrote:
http://www.darkreading.com/document.asp?doc_id=154270&WT.svl=news1_1
Bull or danger?
DCC SEND 123456789ab
participants (6)
-
Billy Crook -
David Nicol -
Leo Mauler -
Luke -Jr -
Monty J. Harder -
Oren Beck