Schneier on Security
A blog covering security and security technology.
« Anti-Missile Defenses for Passenger Aircraft |
| Hackers Clone RFID Passports »
August 3, 2006
A Month of Browser Bugs
To kick off his new Browser Fun blog, H.D. Moore began with "A Month of Browser Bugs":
This blog will serve as a dumping ground for browser-based security research and vulnerability disclosure. To kick off this blog, we are announcing the Month of Browser Bugs (MoBB), where we will publish a new browser hack, every day, for the entire month of July. The hacks we publish are carefully chosen to demonstrate a concept without disclosing a direct path to remote code execution. Enjoy!
Thirty-one days, and thirty-one hacks later, the blog lists exploits against all the major browsers:
- Internet Explorer: 25
- Mozilla: 2
- Safari: 2
- Opera: 1
- Konqueror: 1
My guess is that he could have gone on for another month without any problem, and possibly could produce a new browser bug a day indefinitely.
The moral here isn't that IE is less secure than the other browsers, although I certainly believe that. The moral is that coding standards are so bad that security flaws are this common.
Eric Rescorla argues that it's a waste of time to find and fix new security holes, because so many of them still remain and the software's security isn't improved. I think he has a point. (Note: this is not to say that it's a waste of time to fix the security holes found and publicly exploited by the bad guys. The question Eric tries to answer is whether or not it is worth it for the security community to find new security holes.)
Another commentary is here.
Posted on August 3, 2006 at 1:53 PM
• 19 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
Sometimes help can be a bad thing.
People who continue to fix bugs in IE, are therefore prolonging the agony of using IE. No bug fixes = abandonment.
Eric Rescorla has a good point indeed, unfortunately people have their own reasons for doing what they do and no theorizing is going to stop them (nor should it), unless the sentiment becomes more widespread. I suppose the purpose is to make it widespread.
We will continue to live with buffer overruns and other constant security problems in IE, Firefox and other browsers until someone decides that a secure browser has to be built from the ground up, with a secure language & framework.
It's not coding stardards. It's low-level languages (yes I mean C and C++) that are empirically proven to not work. Even the best coders don't get memory management and direct memory access right. Don't believe me? Just look at all those browser bugs above.
I don't think it's just coding standards and languages. To the best of my knowledge, secure software engineering is just not given very much emphasis in computer science education. It's still seen as a rather optional and esoteric part of the curriculum. To get at the root of the problem, people need to learn secure and safe programming from the get-go. Without the right education, even the best tools will be mis-used, and security problems will still plague us.
The languages you mention can work just fine; you just need to create (or use) good libraries that handle the trickier points, and require their consistant usage via coding standard(s). C++ in particular can be very effective if you properly use its absract features.
Isn't it also true that the high number of IE bugs may also reflect more energy placed in discovering exploits in IE, as it is still far more widespread then other browsers, and thus makes more sense to dedicate time compromising?
Probably, partially, although they don't hold the market share they did, say, 2 years ago. One intrinsic problem IE has that the others don't, though, is that Microsoft made the decision to integrate IE into their OS. This means that IE is not strictly an application on top of the OS, so a browser exploit may gain you more than it would with other browsers.
This also may make it more difficult to fix IE defects (since a change in IE may also have an unintended side effect elsewhere in their OS).
I don't see any browser bugs listed for lynx... :-X
Benny: "To the best of my knowledge, secure software engineering is just not given very much emphasis in computer science education. It's still seen as a rather optional and esoteric part of the curriculum."
Unfortunately, that's true at most universities, at least at the undergraduate level. There are many graduate level programs investigating information security theory in a logcally and semantically valid way. Most of the top-tier undergraduate programs at least offer advanced coursework in the subject as well.
Saying "nothing's going to change until we write secure software from the ground up" is like saying "human beings will keep suffering until we cure all sickness and disease": It's true, and it's good to keep it in mind, but as a course of action it doesn't even begin to cover the complexity of the problems, let alone the solutions.
I have a lot of hope for this sort of research---I think it's ultimately going to be the best security tool we'll have---but we have a ways to go yet.
"Saying 'nothing's going to change until we write secure software from the ground up' is like saying 'human beings will keep suffering until we cure all sickness and disease': It's true, and it's good to keep it in mind, but as a course of action it doesn't even begin to cover the complexity of the problems, let alone the solutions."
I definitely agree with you. I just wanted to point out that education is every bit as important as improving software engineering methods and tools. To keep with your analogy, we fight sickness and disease by making better medical equipment AND training better doctors and nurses.
The most critical vulnerabilities allow a specially crafted web page to execute arbitrary code and modify the victim's system. This is an OS design problem. Why should the OS allow a browser to modify the system? Why does the OS allow a browser to launch executable code that can modify the system?
There is good engineering.
There is bad engineering.
Humans have shown an ability to create in either way. The current system does not encourage or support good software engineering. This is not a problem that can be fixed without regulatory intervention by government.
Maybe it is the logical expression of an engineering legacy which includes the US design principles of; 'good enough' and 'planned obsolescence'.
"Isn't it also true that the high number of IE bugs may also reflect more energy placed in discovering exploits in IE, as it is still far more widespread then other browsers, and thus makes more sense to dedicate time compromising?"
That's almost certainly true.
I don't think you can use this data as evidence of one brower's security over another.
I have to disagree with at least one part of the paper analyzing whether or not it's worthwhile for the whitehat community to research vulnerabilities.
The author contends that the probability of discovery of a given subset of vulnerabilities in some piece of software, Pdiscovery, is equal to the size of the subset, Vdiscovery, divided by the total number of vulnerabilities in that software, Vall.
Pdiscovery = Vdiscovery/Vall
I would contend that this calculation doesn't take into account the difficulty of identifying the vulnerability. At least intuitively, it seems that the probability of finding a bug triggered by, say, feeding an overly long string to some input point in the software is far higher than the probability of finding a bug that is dependent on some large number of variables being initialized to specific values.
Am I missing something here?
In a way, Opera IS more secure than IE - through "obscurity". There may or may not be as many bugs as in IE, but because fewer hackers attack it, the vulnerability of Opera is obscured.
"The most critical vulnerabilities allow a specially crafted web page to execute arbitrary code and modify the victim's system. This is an OS design problem. Why should the OS allow a browser to modify the system? Why does the OS allow a browser to launch executable code that can modify the system?"
Simply put, we'd have to add another, larger set of access controls to applications. And, hey, if you want to, you could use Linux and have Firefox running in its own user account. But that would still allow it to modify any files that that account has access to.
It's doable, but you'd need to modify your OS severely. We really don't have any operating systems built with security in mind--at least, not security from automated attacks.
"It's doable, but you'd need to modify your OS severely. We really don't have any operating systems built with security in mind--at least, not security from automated attacks."
Damn straight it's doable. It's been done, more than once.The EROS operating system is a good example. (If you're looking for it, it's now called, CapROS and can be found at www.capros.org. It's also all open source.)
derf is right.
"This is an OS design problem. Why should the OS allow a browser to modify the system? Why does the OS allow a browser to launch executable code that can modify the system?"
EROS was built by people who understand that vulnerabilities will always exist. We need systems that properly support the notion of least privilege in order to mitigate the possible damage when a vulnerability is exploited.
I think the real issue is about performance. i386 design intended to have separate layers of execution, dubbed rings; I think it's 4 rings of execution, from 0 (high) to 3 (low). If browsers were to run at a lower ring of power, say 2 or 3, there would be no real danger because the code would have no power within the computer, and certainly no ill effects on ring 0 OS code. But it would be slower...
Instead, somebody figured out it's faster at ring 0 and now you can claim your OS and browser are speedier.
I may be wrong about the number of rings and what not, but you see my point.
Browsers in general do run with less privilege than the OS, even IE probably does (in the sense that it doesn't have direct access to the hardware).
But even if you are running as non-admin and have the browser limited to your restricted user account, this may be enough: an attacker has access to the net (to attack others, e.g. DoS), access to *your* data (credit card etc.) and run software (e.g. for popups). An admin account is "only" needed to make the malware impossible to remove without reinstalling the system.
Schneier.com is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc.