Disloyal Software
Disloyal software surrounds us. This is software running on devices or computers you own and that serves interests other than yours. Examples are DVD firmware that insists on making you watch the silly FBI warning or prevents you from skipping “splashes” or previews, or popup and popunder advertisement web browser windows. When people discuss malware or categories of software, there is usually little consideration for disloyal software (I found this interesting discussion of Trusted Computing). Some of it is perfectly legal; some protects legal rights. At the other extreme, rootkits can subvert entire computers against their owners. The question is, when can you trust possibly disloyal software, and when does it become malware, such as the Sony CD copy prevention rootkit?
Who’s in Control
Loyalty is a question of perspective in ownership vs control. The employer providing laptops and computers to employees doesn’t want them to install things that could be liabilities or compromise the computer. The employee is using software that is restrictive but justifiably so. From the perspective of someone privately owning a computer, a lesser likelihood of disloyalty is an advantage of free software (as in the FSF free software definition). The developers won’t benefit from implementing restrictions and developing software that does things that go counter to the interests of the user. If one does, someone somewhere will likely remove that restriction for the benefit of all. Of course, this doesn’t address the possibility of cleverly hidden capabilities (such as backdoors) or compromised source code repositories.
This leads to questions of control of many other devices, such as game consoles and media players such as the iPod. Why does my iPod, using Apple-provided software, not allow me to copy music files to another computer? It doesn’t matter which computer as long as I’m not violating copyrights; possibly it’s the same computer that ripped the CDs, because the hard drive died or was upgraded, or it’s the new computer I just bought. By using the iPod as a storage device instead of a music player, such copies can be done with Apple software, but music files in the “play” section can’t be copied out. This restriction is utterly silly as it accomplishes nothing but annoy owners, and I’m glad that Ubuntu Linux allows direct access to the music files.
DMCA
Some firmware implements copyright protection measures, and modifying it to remove those protections is made illegal by the DMCA. As modifying consoles (“modding”) is often done for that purpose, the act of “modding” has become suspicious in itself. Someone modding a DVD player to simply be able to bypass annoying splash screens, but without affecting copy protection mechanisms, would have a hard time defending herself. This has a chilling effect on the recycling of perfectly good hardware with better software. For example, I think Microsoft would still be selling large quantities of the original XBox if the compiled XBMC media player software wasn’t illegal as well for most people due to licensing issues with the Microsoft compiler. The DMCA helps law enforcement and copyright holders, but has negative effects as well (see wikipedia). Disloyal devices are distasteful, and the current law heavily favors copyright owners. Of course, it’s not clearcut, especially in devices that have responsibilities towards multiple entities, such as cell phones. I recommend watching Ron Buskey’s security seminar about cell phones.
Web Me Up
If you think you’re using only free software, you’re wrong every time you use the web and allow scripting. The potentially ultimate disloyal software is the one web sites push to your browser. Active content (JavaScript, Flash, etc…) on web pages can glue you in place and restrict what you can do and how, or deploy adversarial behaviors (e.g., pop-unders or browser attacks). Every time you visit a web page nowadays, you download and run software that is not free:
* it is often impractical to access the content of the page, or even basic form functionality, without running the software, so you do not have the freedom to run or not run it as a practical choice (in theory you do have a choice, but penalties for choosing the alternative can be significant).
* It is difficult to study given how some code can load other active content from other sites in a chain-like fashion, creating a large spaghetti, which can be changed at any time.
* there is no point to redistributing copies, as the copies running from the web sites you need to use won’t change.
* Releasing your “improvements” to the public would almost certainly violate copyrights. Even if you made useful improvements, the web site owners could change how their site works regularly, thus foiling your efforts.
Most of the above is true even if the scripts you are made to run in a browser were free software from the point of view of the web developers; the delivery method tainted them.
Give me some AIR
The Adobe Integrated Runtime (“AIR”) is interesting because it has the potential to free web technologies such as HTML, Flash and JavaScript, by allowing them to be used in a free open source way. CERIAS webmaster Ed Finkler developed the “Spaz” application with it, and licensed it with the New BSD license. I say potentially only, because AIR can be used to dynamically load software as well, with all the problems of web scripting. It’s a question of control and trust. I can’t trust possibly malicious code that I am forced to run on my machine to access a web page which I happen to visit. However, I may trust static code that is free software, to not be disloyal by design. If it is disloyal, it is possible to fix it and redistribute the improved code. AIR could deliver that, as Ed demonstrated.
The problem with AIR is that I will have to trust a web developer with the security of my desktop. AIR has two sandboxes, the Classic Sandbox that is like a web browser, and the Application Sandbox, which is compared to server-side applications except they run locally (see the AIR security FAQ). The Application Sandbox allows local file operations that are typically forbidden to web browsers, but without some of the more dangerous web browser functionality. Whereas the technological security model makes sense as a foundation, its actual security is entirely up to whoever makes the code that runs in the Application Sandbox. People who have no qualms about pushing code to my browser and forcing me to turn on scripting, thus making me vulnerable to attacks from sites I will visit subsequently, to malicious ads, or to code injected into their site, can’t be trusted to care if my desktop is compromised through their code, or to be competent to prevent it.
Even the security FAQ for AIR downplays significant risks. For example, it says “The damage potential from an injection attack in a given website is directly proportional to the value of the website itself. As such, a simple website such as an unauthenticated chat or crossword site does not have to worry much about injection attacks as much as any damage would be annoying at most.” This completely ignores scripting-based attacks against the browsers themselves, such as those performed by the well-known malwares Mpack and IcePack. In addition, there probably will be both implementation and design vulnerabilities found in AIR itself.
Either way, AIR is a development to watch.
P.S. (10/16): What if AIR attracts the kind of people that are responsible for flooding the National Vulnerability Database with PHP server application vulnerabilities? Server applications are notoriously difficult to write securely. Code that they would write for the application sandbox could be just as buggy, except that instead of a few compromised servers, there could be a large quantity of compromised personal computers…
on Tuesday, October 16, 2007 at 03:52 AM