illurity-logo
Log in

Site menu:

Categories

Tags

Site search

September 2018
M T W T F S S
« Dec    
 12
3456789
10111213141516
17181920212223
24252627282930

Links:

Archives

Where’d that firmware come from?

The word “hacker” is very frequently misused, insomuch as jargon can be misused. But who would dare argue with an RFC? This venerable 15 year old document incontrovertibly defines a hacker as “a person who delights in having an intimate understanding of the internal workings of a system, computers and computer networks in particular.  The term is often misused in a pejorative context, where ‘cracker’ would be the correct term.” Whether it’s your iPhone, your Tivo, your XBox, or your WRT, there are plenty of hobbyist sites dedicated to these sorts of delightful hacks, and others. And that’s fine – if you buy a consumer electronics product, you should be able to modify it, enhance it, or destroy it in whatever fashion if you so choose. Worst case, you’re out a few bucks. Or maybe you go to prison because some rabid IP attorney heaps DMCA or EUCD copy protection violation ambiguities on you in just the right Goldilocks configuration.

If the only control a product vendor offers to protect the original/authorized state of a hack-worthy product is a “please don’t change stuff” EULA, the effectiveness will hover around zero. If the vendor goes a little further by putting in place a relatively weak technological control, the effectiveness will increase, but it will be somewhat offset by the fact that a difficult but surmountable challenge generally makes a successful hack even more delightful for the hacker. So given that nothing is unbreakable, to what extent should security or mission-critical vendors go to protect the integrity of the code of their products?

According to this, further than they do. Call it phlashing, or malicious hacking, or bricking, this exploit describes loading intentionally non-functional code onto a target as a “permanent denial of service attack”. Although loading naughty firmware can often be done remotely, thus making this a “remote exploit”, the act of loading firmware generally requires administrative access. As long as 1) the default username:password has been changed, 2) admin credentials have not been compromised, and 3) firmware is not loadable through some other insufficient validation backdoor or exploit, then this becomes far less threatening.

Still, responsible vendors could (and do) take further steps to defend against adulteration, such as:

  • Enforcing the use of digitally signing firmware images
  • Performing hash verification of the images to protect against tampering/fuzzing
  • Verifying that the loaded image is intended for the target platform (to ensure that ‘wrong’ versions of firmware aren’t loaded)
  • Providing an unalterable bootstrap method of recovery, i.e. a SafeMode at a ‘brick-proof’ level below the running firmware, in the unlikely event of firmware corruption
  • Using Secure Compact Flash and/or encrypted disk file systems to protect against code being directly written to a boot device

Sure, some of these measures are designed to protect against only physical attacks, and it’s common to hear the argument that “once the attacker has physical access, the battle is lost” but what about before the product is put into production? A big part of the Common Criteria EAL certification process, includes such points as “who has access to your source code?”. “who controls access to the source code?”, “what compilers, toolchains or development environments are used in the creation of your products?”, “by whom and how is firmware loaded onto the appliances?”, “how is the finished product transported from manufacturing, through distribution, to the consumer?”

A truly secure product will defend against all of this.

Share: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Twitter
  • LinkedIn
  • Facebook
  • email
  • Google Bookmarks
  • del.icio.us
  • StumbleUpon
  • Reddit

Comments

Pingback from Worth A Glance » Quackery
Time: 2009-01-06, 21:07

[…] and Common Criteria to help to ensure cryptographic integrity, to protect against attacks targeting development environments and supply-chains, and to weed-out fraudulent vendor claims. But the effectiveness of these […]

You must be logged in to post a comment.