LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityThreat models for embedded devicesUnderstanding the threats that a system could be subjected to is a starting point for deciding on what countermeasures to use to protect it. That idea is the motivation behind the development of "threat models", which is a term used in various contexts including both military and computer security. It is impossible to defend against all possible threats, so understanding which threats are to be defended against helps focus the efforts to elements that will thwart those attacks—without getting lost in a wide variety of other possibilities. In the embedded systems context, a threat model is the summation of the kinds of threats the device is meant to thwart. It is essentially a list of the attack types that will be defended against by all elements of the system: hardware and software. The good folks at the Embedded Linux Conference accepted my talk, "Understanding threat models for embedded devices", which I thought might best be organized around this article, effectively killing two birds with one stone. The threat model can be considered long before specific software choices for a device are made, as it is largely determined by the intended function of the device. There are several things that need to be considered, including things like the connectivity of the device (wired, wireless, remote control, etc.), the data that the device has—or controls—access to, the kinds of environments where it will be installed, and the technical sophistication expected of its users. From a threat model perspective, those characteristics are interdependent, so they can't be analyzed in isolation. What is being protected?One of the first things that needs to be identified is what is being protected. At the most basic level, the proper functioning of the device likely requires protection, so that attackers cannot cause a denial-of-service, but there are often more assets to protect than that. Another way to look at the problem is to consider what the consequences are if the device is successfully attacked. Beyond just being able to disrupt the user's enjoyment of the device, the data stored in the device or protected by it—think router/firewall for example—needs to be considered. The value of that data, both to the user and to a potential attacker, is a key factor in determining what threats are relevant. For something like a television or microwave, which either don't store much in the way of data or only store data that has a fairly low value (various settings, favorite channels, etc.), protecting the data from disclosure or erasure is probably not a high priority. But for other devices, a successful attack might drain a user's bank account, snoop on their phone calls, or permanently delete their family photo album. From a user—customer—perspective those differences are very important. As the value of the data to an attacker increases, the sophistication of the attacks also increases. A basic tenet of security is that making attacks require more resources than an attacker gains if they are successful is an effective means of repelling attacks. InputsOne of the biggest factors that impacts a device's threat model is the kinds of connectivity it has to the external world. Devices like home wireless internet routers or network-attached storage servers have obvious network connections, but other devices, even some that might seem to be connection-free, often still have some means of interacting with users that might be a potential means for attack. Remote controls—or even front panel buttons, depending on the installation location—provide a means for providing input to a device. Any input can, of course, be used for good or ill. There are very few devices that take no input at all, so identifying those inputs is important. There are obvious inputs, wired and wireless networking, bluetooth, GPS signals, cellular voice/data, etc. There are more subtle, and likely less useful, inputs that should also be considered. Cameras are being added to more devices these days, and depending on what kind of processing is done to an image, could become a vector for attack. There have certainly been enough exploits of flaws in image-handling libraries to give one pause. Some inputs have much more potential for abuse than others, but as part of coming up with a threat model, all of the system inputs should at least be considered. It may make sense for business or other reasons to explicitly ignore certain kinds of attacks, especially if the input mechanism is protected in other ways. If the device is intended to be physically secure—locked up in someone's house or server room for instance—it may be reasonable to exclude attacks requiring physical access from the model. That doesn't mean that those attacks are impossible but that they require an attack focused on a particular individual or organization, which are some of the hardest attacks to thwart. Installation locationPhysical security is often assumed for servers, but embedded devices don't necessarily have that luxury. Depending on the function of the device and the technical knowledge of its owner, devices may be deployed in ways that are outside of the expectations of the developers. "Home" wireless routers are often used in small businesses and are sometimes explicitly set up for use by the general public, in coffee shops for example. Televisions and DVRs may be installed in bars and restaurants which expands the kinds of attacks those devices might be subjected to. It is important to at least think about other ways that a device might be used. It is much easier to assume that a device will only be installed in a "friendly" environment, or that its owner will keep it physically safe, but those expectations may not be borne out in practice. It is also important to consider the target market for the device and the expected level of technical knowledge for its users. UsersTechnically savvy computer users would probably never even consider hooking up their NAS—with their music, photo, and movie collection—directly to the Internet, but less sophisticated users might. If they were trying to share photos with a relative, or some kind of photo printing service, it might seem to be far easier to just "put it on the net" without recognizing the privacy and security implications. So some consideration should be given to the target market. Less sophisticated users probably need a higher level of security, at least for some types of devices. If the device is targeting the IT department at a company, some level of security knowledge can probably—hopefully—be assumed. But that same device in the hands of someone with no security training or awareness may be at much more risk. Another consideration is how the device gets its updates in the event of a security flaw. These days, most devices have some means to update the firmware for security, other bugs, or to add—and sometimes subtract—functionality. In order for security updates to get installed, though, the user must know about the problem, and have the capability to perform the upgrade. Systems that do not plan to have an easy path for user upgrades will probably want to put more effort into ensuring that the firmware that ships has been carefully vetted based on the other factors in its threat model. ExamplesA television with HDMI, remote control, and front panel inputs is not susceptible to very many kinds of attacks. There are potentially denial-of-service attacks possible via the latter two input methods, but the data being protected is of fairly low value (if there is any data at all). The users are likely to have little security awareness, but since there is little of value and few ways to impact the device, the security needs are fairly minimal. The biggest problem might be someone surreptitiously changing the channel or volume via a universal remote—something that is completely outside of the scope of problems that a television manufacturer should be expected to thwart. A NAS box targeted at home users to store various multimedia files throughout the home has an entirely different profile. Other than a power switch, there probably isn't any real front panel, but there is a network interface, which is where most of the exposure comes from. The data is of fairly high value to its owner, and while its value to an attacker is variable, it is probably fairly low. An attacker who could deny access to the device or its contents might be in a position to extract a ransom to restore it. If the system could be compromised, though, it is likely to be powerful enough to be of interest as a botnet participant, which may be the most likely attack scenario. Targeting the home market means that users are not likely to have a lot of technical expertise, so they may install and use the device in unexpected ways. But even for those devices that are properly installed behind a router/firewall, there may be attacks via malware running on other computers in the network. Home networks are often considered to be "safe", but browser and other malware attacks against devices behind the firewall, or the firewall itself, are certainly not unknown. Probably one of the more common mistakes that is made with these kinds of devices is using a default administrative password that never gets changed—malware doesn't have to work very hard to exploit that flaw. Other devices will have different characteristics, of course, but analyzing the device to determine the threats to defend against is similar. Using the value of the data, the kinds of inputs the device has, its users, and how it is intended to be installed, one can start prioritizing which functional areas of the device software need the most attention. Explicitly rejecting certain kinds of attack scenarios will also assist in cutting down on the work that needs to be done, as long as customer expectations are set correctly. Doing this analysis during product planning, rather than after there is working prototype or, worse yet, a shipping product, will make it much less disruptive resulting in a better, more secure device. ConclusionDevice manufacturers, like software vendors, often see security problems as a public relations issue, which it is to some extent. But it is really more of a customer relations problem—if customers have been burned by security problems in a particular vendor's device, they are much less likely to purchase from that vendor again. As a large software vendor in the Pacific Northwest found out, once a reputation for poor security is established, it can be very hard to undo. It's much better to "bake security in" rather than just hope that no security issues arise.
Brief items Apache.org services attackedThe Apache Infrastructure Team has reported a direct, targeted attack against the server hosting their issue-tracking software. "If you are a user of the Apache hosted JIRA, Bugzilla, or Confluence, a hashed copy of your password has been compromised. JIRA and Confluence both use a SHA-512 hash, but without a random salt. We believe the risk to simple passwords based on dictionary words is quite high, and most users should rotate their passwords. Bugzilla uses a SHA-256, including a random salt. The risk for most users is low to moderate, since pre-built password dictionaries are not effective, but we recommend users should still remove these passwords from use. In addition, if you logged into the Apache JIRA instance between April 6th and April 9th, you should consider the password as compromised, because the attackers changed the login form to log them."
New vulnerabilities acroread: multiple vulnerabilities
alienarena: denial of service
clamav: denial of service
drupal-views: multiple vulnerabilities
firefox: security bypass
firefox: multiple vulnerabilities
kdm: privilege escalation
MoinMoin: access restriction bypass
spamass-milter: arbitrary code execution
Page editor: Jake Edge |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||