Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.
Security Response

OSS in an Embedded World - Vendors Need To Take Responsibility for Security

Created: 16 May 2006 07:00:00 GMT • Updated: 23 Jan 2014 18:59:35 GMT
Ollie  Whitehouse's picture
0 0 Votes
Login to vote

So, it's started. We are starting to see the arrival of Linux in the cellular device/handset market (to be honest, it's been a year or two since they first emerged, but they are now starting to become more prevalent) and along with them the attendant security issues.

While I wish to avoid a war in regards to different operating systems and security (I don't want to antagonize the Slashdot crowd again), the following is true: the vendors who are gaining direct benefits from the adoption of open source software (OSS) within their devices and products (such as low cost and quicker product development) are not addressing the security with the same aggression. If Symantec were a non-OSS company, people (myself for one) would be quick to point this out and remind them of their obligations to end-user security.

Let me explain what I mean. Currently we expect big OS vendors like Microsoft, Apple, and Sun to typically provide an easy way to implement upgrades that address security issues (even if not always timely) both in their non-mobile and mobile devices alike. However, when we look at these Linux-based cellular devices for example, we see code from a myriad of different OSS projects. Have I seen any upgrades from the vendors of these handsets that address a security issue? The short answer is no. I can't even upgrade the device from one vendor by official means unless I take it to a service center. Have I seen individual security patches for the Kernel, Helix and others from their respective projects? Oh yes, I have. So what about these little computers that sit in our pockets and are very personal to us? They sit there unpatched and potentially vulnerable to the same exploits as their desktop cousins (although, granted, they maybe slightly more esoteric in nature.)

This problem is compounded when vendors don't pull their code directly from the project itself but instead via a third party who provides "industrial Linux development environments" or something similar. The result being that they need this third party provider to upgrade the components (such as libpng, zlib, etc.) in order for the OSS to be supported. And where's the commercial incentive in that?

While I am discussing cellular handsets here, obviously this has a much wider scope that encompasses a vast number of different types of devices. I think cellular handsets are a good example as they hold sensitive information, have numerous communications channels open to them (which can also allow exploitation)—such as SMS, MMS, GPRS/UMTS, 802.11, Bluetooth and Infrared—and are trusted by us users as a key part of our digital world.

In short, vendors who benefit from OSS (not just Linux-based, as we saw with Sony’s vulnerable version of libpng, which they shipped on the first PSPs) need to understand that security issues will be found in OSS just as they will be found in non-OSS. However, unlike those vendors using non-OSS products, vendors using some flavor of OSS will normally have to confess that they are using it (or it may be that people work it out quickly enough on their own) and the visibility of any susceptibilities can increase. As a result, when vendors develop products based on an OSS, they need to have the processes and capabilities in place to upgrade their devices in the field and address security issues.