By Greg Sandoval
Each day this month, a prominent security expert will highlight a new vulnerability found in one of the major Internet browsers.
HD Moore, the creator of Metasploit Framework, a tool that helps test whether a system is safe from intrusion, has dubbed July the Month of Browser Bugs. Already, the security researcher has featured five security flaws, three for Microsoft’s Internet Explorer and one apiece for Mozilla’s Firefox and Apple Computer’s Safari.
Thirty one days later, MoBB is done! By far one of the more interesting vulnerability disclosure projects we’ve seen this year. I have a strong feeling that the real ramifications won’t be realized until months later, but until someone does a more thorough analysis.. my random thoughts.
First, HDM and I chatted almost every single day during the month, mostly to coordinate the pre-assignment of OSVDB IDs for each bug. Due to the schedule I keep, it was usually easy to check the blog around midnight every night, and for 30 of the 31 days, he was right on time releasing the next bug. Only on the 31st day did he finally fall behind by a whole two hours (jeez, what a slacker!) in releasing the final bug. Ok ok, it wasn’t due to slacking, he had been working for hours trying to isolate the exact details to fully understand and document the bug he had been researching in Safari.
31 browser bugs, what’s the final breakdown?
- MSIE: 25
- Apple Safari: 2
- Mozilla: 2
- Opera: 1
- Konqueror: 1
I’ll let you make any conclusions you want. If I hadn’t posted this, we’d no doubt see at least one article saying how much more insecure MSIE is than X and this is just proof of that. Hopefully the fact I posted that last line might actually make a journalist stop and think, “why, is it something else?!” GLAD YOU ASKED! Ok not really, but there is more to it than W bugs in X browser vs Y bugs in Z browser so W must be more insecure than Y!@$#! If you can’t think of any such reasons, quit your job and go to art school.
What if he had…
- followed ‘accepted’ vulnerability disclosure guidelines? (the project would have been dubbed the YoBB?)
- sold his findings to the shops like ZDI or iDefense that pay for such information? (he’d be rich?!)
- sold his findings to a russian spam syndicate? (he’d be able to buy a new iPod?!)
- never posted a single bug in any fashion? (he and a dozen others would all be sitting on this information)
- provided even more easy point-and-drool exploitation? (we’d be reading another CNET article about the latest spyware/adware that exploited..)
Want another month of browser bugs? Yes, he could continue on into August without a problem. The amount of browser bugs is stupid. Apparently, the idea of writing a basic fuzzer is still lost on the authors. The good news, HDM will be releasing the fuzzer he used to find all these to the public. Will an insane rush of browser bugs follow? We can hope!
Want another month of browser bugs? Then do it yourself. While it may sound easy, researching each one to the degree HDM did is not easy and it isn’t fast. If you can devote between 15 minutes and 3 hours a day for 31 days, then go for it! Until then, as my friend major says, “never lick a gift whore in the mouse.”
PoC aka ‘Proof of Concept’. Please, stop and read those words.. actually think about what it means. The term was originally used to label code that demonstrated that a concept or idea was actually valid. ResearcherX would say that SoftwareY contained an exploitable overflow in FunctionZ. Since code can be tricky and input sanitized in a number of places, the researcher would write up exploit code that demonstrated and proved (the ‘proof’ in PoC) his concept was actually valid. This was working code that at least demonstrated a segfault, denial of service, or actually run an arbitrary (even harmless) command.
These days, PoC is a stupid catch phrase used to label any URL that supposedly demonstrates an exploit. Researcher1 finds a cross-site scripting vulnerability in SoftwareY and releases the following PoC:
That does not prove your concept. That does not prove there is a vulnerability. That does not necessarily let anyone else figure out how to exploit it short of full source code analysis. Yes, most XSS vulnerabilities are trivial to reproduce, especially with a cross site scripting cheat sheet out there. However, some XSS vulnerabilities may take some tricky encoding, restrict specific types of characters, or otherwise make exploitation difficult. Assuming that 99% of the XSS vulnerabilities disclosed are trivial to replicate, i’ll concede the above as a proof of concept. That said, the next time you find yourself typing this:
Please, don’t bother. Just because you pasted a ‘ character into the application and saw some pretty SQL error syntax doesn’t mean it is vulnerable to SQL injection. If you are going to use “PoC” anywhere in your “advisory”, prove your claim it is vulnerable. With the amount of vendor disputed vulnerabilities, it is the least you can do if you want anyone to take you seriously.
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!
There are already two Microsoft IE vulnerabilities posted. This should prove to be a fun blog!
p.s. Anyone else have flashbacks to SoD and the HP Bug of the Week? =)