First it was the Month of Browser Bugs (MoBB), now it is the Month of Kernel Bugs (MoKB). When I first read about it, I immediately thought of thirty odd entries about Linux Kernel Local DoS conditions. My pessimism is born out of the numerous local DoS attacks against the Linux Kernel. Microsoft fans use this to say that Linux has so many more bugs than Microsoft, but i’m sure if we documented every way to make any version of Windows blue screen, we’d be cutting ourselves.
Fortunately, the MoKB has started out very well by offering vulnerabilities in Mac OS X Kernel Wireless Drivers, Linux, FreeBSD, Solaris, and Windows. Only 11 days in, and all of that! The folks putting this together are doing an outstanding job putting this together, researching the vulnerabilities and presenting them.
In the months and years to come, what else will we see? What would you like to see the most.. Month of ______ Bugs.
Fall behind and someone will always beat you to the punch! Gadi Evron posted an entry over at Securiteam on the topic of using Google’s Codesearch to find vulns. Since he and others are writing about this, I don’t have to! However, i’ll post a few more thoughts before anyone else maybe!
First, we have this great ability to (ab)use Google’s Codesearch to find vulnerabilities through fast code analysis. Is this a fun but very short fad? Or will we see people use this to disclose vulnerabilities and give credit to their method? Will it lead to a lot of false positives> like we’re seeing with remote file inclusion? Several ‘researchers’ are grep’ing for a single stringle, finding it, and posting it as a remote file inclusion vulnerability without really analyzing the code or testing their own “proof of concept”. Hopefully, researchers will use this new tool to not only find vulnerabilities, but truly validate their finding before disclosing.
Second, who is going to be the first to create an interface that smoothly links the Google Codesearch with a robust static code analyzer? Imagine a web interface where you choose a few key things like what language, what types of vulnerabilities, and click click for all the results. The program would then use the Codesearch results to pipe into the code analyzer and spit out a list of high probability vulnerabilities.
Some of these ideas courtesy of email discussions with Chris Wysopal, Mudge and others.
Paul Clark, Systems Librarian at the Wilderness Coast Public Libraries, has created an excellent timeline of Full Disclosure related articles. Unfortunately, mail to him is bouncing and it hasn’t been updated since 2004. Would be great to see someone pick this up.
Ever wondered what some of the bigger vendors do in response to vulnerability Disclosure? Federico Biancuzzi has written an article on his Disclosure survey which may answer the question for you. Apple, Computer Associates, Google, IBM, Microsoft, Novell, Oracle, Red Hat, SAP, Sun Microsystems and Yahoo all answered to one degree or another. As always, some of the vendors are a bit weak in the description. Take Oracle for example, who says they want researchers to wait for their patch before disclosing. Next he asks the two big vulnerability purchasing shops iDefense and TippingPoint’s ZeroDayInitiative (ZDI) their thoughts. Finally, he asks three prominent researchers; David Litchfield, H D Moore and Michal Zalewski.
No, this isn’t some odd contest with a disappointing reward. Date an OSVDB moderator! *shudder*
Think of dates in the context of vulnerability disclosure. Think of how many dates we don’t know, even in the more formal advisories (some with time lines even). OSVDB currently tracks three dates: Vulnerability Published, Vulnerability Discovered, Exploit Published. We have additional dates that we will add to the system as developer time permits, but unfortunately most vulnerabilities don’t come with the information we need. In a perfect disclosure world, each vulnerability posted would come with a robust timeline:
- Vulnerability Discovered
- Disclosed to Vendor
- Vendor Acknowledgement
- Vendor Patch
- Public Disclosure
This would allow VDBs to track better metrics, including vendor response time, patch development time and more. Are there more dates that would be relevant and of interest?
I’ve mentioned the sociology aspect of the hacker, vuln researcher and security companies before, specifically how they interact, how one will influence another and more. The list of fun ideas I have on these topics is great, and maybe some day i’ll find the time to write more on them. In the mean time, this obvious one popped up and focuses on vulnerability researchers, how they find bugs, and how some feed off the work of others. We see this often where ResearcherA will find a vulnerability in one script, disclose the information, and ResearcherB will followup shortly after with the same type of vulnerability in a different script of the same product.
Recently we’ve seen a rash of remote file inclusion bugs in various add-ons to Mambo and Joomla. These add-ons are typically not written by the same developers nor are they distributed with the base installation of each product. However, they all seem to have one thing in common: “mosConfig_absolute_path” (or sometimes “absolute_path”). The same variable is being exploited in dozens of different add-ons and being found by different people. If we examine the chain of disclosure, can we see patterns in who consistently does followup research (low hanging fruit) instead of finding original vulnerabilities? Are there more observations in the way they are disclosed such as reporting to exploit sites vs Bugtraq or Full Disclosure? Are there misplaced signs of ego that accompany what amounts to trivial vulnerability finds while others are more modest and take it for what it is? Is it surprising that as people jump on the bandwagon, more and more reports end up being inaccurate and not a real vulnerability?
While skimming the list,
strike-out text indicates the vulnerability has been disputed or proven false. The names of the researchers who didn’t fully check their find are in bold (and I’m curious if the other disclosures hold up under scrutiny). There is one occurrence of italics that potentially shows this type of “research” being used in the wild.
2006-08-21 bigAPE-Backup for Mambo – mdx
2006-08-20 Display MOSBot Manager for Mambo – O.U.T.L.A.W (Aria-security)
2006-08-20 EstateAgent for Mambo – O.U.T.L.A.W (Aria-security)
2006-08-19 CatalogShop for Mambo – O.U.T.L.A.W (Aria-security)
2006-08-18 Joomla x-shop – Crackers_Child
2006-08-18 Joomla Rssxt – Crackers_Child
2006-08-18 Kochsuite for Joomla – camino (Insecurity Research Team)
2006-08-18 mtg_myhomepage For Mambo – O.U.T.L.A.W (Aria-security)
2006-08-18 mambo-phphop Product Scroller – O.U.T.L.A.W (Aria-security)
2006-08-17 contentpublisher for Mambo – Crackers_Child
2006-08-17 MambelFish for Mambo – mdx
2006-08-17 JIM for Joomla – XORON
2006-08-17 mosListMessenger for Mambo – Crackers_Child
2006-08-17 anjel for Mambo – Crackers_Child
2006-08-16 Coppermine for Mambo – k1tk4t
2006-08-16 Reporter for Mambo – Crackers_Child
2006-08-16 com_lm for Mambo – Crackers_Child
2006-08-14 MMP for Mambo – mdx
2006-08-14 PeopleBook for Mambo – Matdhule
2006-08-10 Remository for Mambo – camino (Insecurity Research Team)
2006-08-07 JD-Wiki for Joomla – jank0 (hackbsd crew)
2006-07-31 Mambatstaff for Mambo – Dr.Jr7
2006-07-30 UHP for Mambo – Kurdish Security
2006-07-29 artlinks for Mambo – Dr.Jr7
2006-07-29 Colophon for Joomla – Drago84 (Exclusive Security Italian Security)
2006-07-28 Security Images for Joomla – Drago84
2006-07-28 MGM for Mambo – A-S-T TEAM
2006-07-28 Guestbook for Mambo – Matdhule
2006-07-24 PrinceClan Chess for Mambo – Tr_ZiNDaN
2006-07-20 MultiBanners for Mambo – Blue|Spy
2006-07-17 Mambo-SMF Forum – ASIANEAGLE
2006-07-17 VideoDB for Mambo – h4ntu (#batamhacker crew)
2006-07-17 LoudMouth for Mambo – h4ntu (#batamhacker crew)
2006-07-17 PollXT for Joomla – vitux
2006-07-17 Calendar for Mambo – Matdhule
2006-07-17 New Article for Mambo – Ahmad Maulana a.k.a Matdhule
2006-07-13 perForms for Joomla – “Vuln founded in a log file: lazy 0day!!! :D”
2006-07-12 Hashcash for Joomla – Ahmad Maulana a.k.a Matdhule
2006-07-12 SiteMap for Mambo – Ahmad Maulana a.k.a Matdhule
2006-07-12 HTMLArea3 for Mambo – Ahmad Maulana a.k.a Matdhule
2006-07-10 PccookBook for Mambo – Ahmad Maulana a.k.a Matdhule
2006-07-07 ExtCalendar for Mambo – Ahmad Maulana a.k.a Matdhule
2006-07-03 Galleria for Mambo – sikunYuk
2006-06-26 CBSMS Mambo Module – Kw3[R]Ln (Romanian Security Team)
2006-06-13 Jobline for Mambo – SpC-x
While all of this not necessarily useful to many, this line of research and observation is fascinating.
Symantec posted a message to Bugtraq earlier this month announcing the availability of a new advisory. The advisory presumably covers a vulnerability or issue in Symantec On-Demand Protection. If you are reading this blog entry a year from now, that is all you may find on it. Yes, even in this day and age, not everything is archived in Google cache or archive.org! In December of 2000, Elias Levy (moderator of Bugtraq at the time) said that such posts were not acceptable because security company web sites had a habit of disappearing, leaving no trace of the information behind. Years later, Symantec bought SecurityFocus (who hosts/moderates the Bugtraq mail list) and we see this rule being ignored, and of course the approved post comes from their owner. Some may argue that Symantec is huge and won’t disappear like those other companies. Many said the same about @stake but shortly after they were purchased, their new owner (Symantec) opted to yank all of the old advisories off the web site making Elias Levy’s concerns reality. As Chris Wysopal said in reply, Symantec needs to post their advisories to the list just like everyone else. While Symantec may stick around, their web site may change or corporate policy may be altered, and that information may not be readily available in the future.
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? =)