Minimizing Risk
Alan: Reading between the lines, do you know of a startup that’s working on such a solution? The Mac would actually be a great platform as the proof-of-concept--there’s a predictable set of hardware that would have to be supported.
Dino: There are a number of products that provide behavior-based anti-malware for Windows, but I also would love it if there would be a solution for Macs as well.
Alan: When we talk about general, rather than signature-based solutions, and think about Gray Hat strategies, we have to talk about things like Deep Packet Inspection technology. The “Golden Shield” project (a.k.a. the Great Firewall of China) was developed by the Chinese government to censor the information their citizens have access to. The NSA used Deep Packet Inspection to identify Voice-Over-IP packets to allow wire-tapping of VoIP conversations in the same way they could do so with the regular plain old telephone system.
With that said, what do you think is the role for desktop deep packet inspection? If I had a box between my computer and the Internet, it could make sure that random data wasn’t going out.
Dino: I don’t think deep packet inspection has a role on the desktop. That is a like watching your living room TV from your backyard. You already have the data and processes running on your machine, your security systems should examine them in that state where they have more information on the behavior.
Alan: But as a separate box, it may be possible to minimize the risk of a sophisticated exploit that disables the security systems that are running on the same machine. The box would have its own OS, would not be exposed to breach via Web browsers or plugins that run on the same device? Or do you think that today's security tools are "good enough" where that extra level of paranoia is overkill?
Dino: A secure hypervisor or even a kernel driver would be secure enough for most home users if they didn't run as an administrator when they were surfing the Web. It is way easier for malware to evade packet inspection than it is for it to exploit a kernel vulnerability. There is absolutely no reason why Web malware couldn't be delivered over SSL, except that it hasn't been necessary up to this point.
Alan: Many of the exploits demonstrated at Pwn2Own have come through non-core operating system elements such as QuickTime (your exploit in '07), Adobe Flash, or Web browsers (IE8, Firefox, and Safari).
In hindsight, was there anything that could have been done on the user end? That is, if you had outgoing firewalls, anti-spyware/anti-malware software, weren't logged in as a root user, would that have done anything to limit the extent of these exploits? Or are we at the mercy of the software developers to protect us?
Dino: No matter what, users are at the mercy of application and operating system software developers. The user can only take secure configuration and third-party security add-ons so far. Outgoing firewalls still have to allow the Web browser to connect to Web-based TCP ports, so an attacker can simply program their exploit payload to do the same. Anti-spyware and anti-malware systems catch high-level actions that malware takes, such as installing back doors, so they may not notice the simpler remote shell payloads used in Pwn2Own exploits. Even if users log in as less-privileged accounts, an attacker may still gain access to their data. A less-privileged account makes it more difficult for spyware to maintain persistent access to the system, but does not prevent gaining initial access.
Disabling unneeded plugins reduces the risk of attack, but there are not enough options in current Web browsers to disable little-used functionality or restrict them to trusted Web sites. Internet Explorer has the most flexible security policy settings, but even it does not let you grant Flash or Java access to selected sites. Selectively granting privileges to enhanced functionality to Web sites is an area where most Web browsers can improve.
