A call to embedded system developers – think of the consumers and users

Recently I bought a NAS (Network Attached Storage) solution for hometo manage backups for the ever increasing number of storage devices weall seem to be accumulating. I did as most people would and selected aconsumer solution from a well-known brand. The brand name on the box,as is not unusual in this day and age, was not the actual developer ofthe underlying reference design. Instead the system was developed by athird-party, including the controller and remote management software,which was subsequently modified to support some proprietary LEDs andgave the company license to slap their logo on it by the name on thebox.

Anyway, this solution was built using GPL software components(Linux, Lighttpd and Perl among others); the vendor and original OEMabided by this license and released all the code on their site(including configurations). I did some digging around and was somewhatdismayed to discover that this product had a number of significantsecurity issues. These vulnerabilities resulted in the ability for aremote attacker to bypass the authentication on the administrativeinterface through to achieving arbitrary code execution as root on theunderlying Linux operating system.

You can imagine my chagrin when I discovered these over the weekend.The year is 2007 and vulnerabilities such as Web servermisconfigurations, poorly written Perl scripts and everything runningas root squarely belong in the last century. These problems, coupledwith the reality that patching these systems in unlikely ever tohappen, as well as the fact that people are just going to plug these inthinking that the advertised security actually does what it says ontin, pose a big security issue.

The result could be hundreds of thousands - if not millions - ofpotential root shells with vast amounts of storage sitting on the endof DSL, 802.11 access points and cable lines the world over. While Iappreciate not all of these will be exposed to the Internet, that manyof them will is a distinct possibility.

So, really this is a request - no actually, I’m pleading - toembedded systems developers: Just because it doesn’t have a screen,keyboard and mouse doesn’t mean security isn’t any less important. Ifyou’re primarily a hardware designer and/or manufacturer and you arestarting to dabble in network-connected devices, please engage asoftware developer/consultant/contractor with demonstrated knowledgeand experience in secure systems and software development. If you’re abig corporation buying/licensing reference designs to repackage underyour own brand, maybe do some due diligence that the advertisedsecurity exists and is up to scratch before slapping your logo on it.Doing so is going save all concerned embarrassment and more importantlyprotect the consumers and users from the risks they are unknowinglybeing exposed to.

Anyway, regarding the specific example alluded to above; I skippedthe re-badger as I knew they weren’t going to have a security team andwent straight to the OEM/OED. I’ll be interested if they respond atall, considering the fact it would appear that the guy that developedthe Web interface did so under contract and has since left.