At the OWASP Open Review project we run Fortify scans for open source project maintainers. There is some summary information on the main page, but the actual detailed scan info is only available to the project maintainers. (Echoing James McGovern's concerns we didn't want it to end up being the "OWASP Open Source 0Day-Publication Project")
More info can be found here: <http://owasp.fortify.com/> I do like the idea of looking at CVEs for open source projects. That is good real-world data that can demonstrate patterns. Thanks, Dan > -----Original Message----- > From: sc-l-boun...@securecoding.org [mailto:sc-l- > boun...@securecoding.org] On Behalf Of Greg Beeley > Sent: Tuesday, March 16, 2010 2:37 PM > To: SC-L@securecoding.org > Subject: Re: [SC-L] blog post and open source vulnerabilities to blog > about > > Matt, > > You can find quite a list of OSS vulnerabilities over an CVE > (cve.mitre.org) > or NVD (nvd.nist.gov), but here are a couple ones that I tend to use > for > illustrative purposes when teaching. > > - Apache Chunked Encoding vuln (#CVE-2002-0392), an integer overflow. > Of > particular interest because when it was first discovered it was not > believed > to be exploitable to gain remote root, but due to a nuance in a > memcpy() / > memmove() implementation, it was (I think I'm remembering this right). > An > example that non-exploitability depends on more than just the program > itself, > but also on the underlying systems (libraries, compiler, hardware, > etc). > > - OpenSSH crc32 compensation attack detector vulnerability (#CVE-2001- > 0144). > Of interest because this was a remote-root vulnerability in a piece of > code > that was used solely to try to thwart an SSH protocol 1 cryptographic > attack. > A good example of more code introducing more bugs, even when the "more > code" > had an important security purpose. > > - Never made it into any distributed code, as it was in version control > only, > but there was a Linux kernel vulnerability that was a backdoor attempt. > (http://kerneltrap.org/node/1584). Of interest because it was > apparently an > intentional "typo" bug to create a backdoor. A good example of > something that > could have easily slid by, but the way that version control was set up > as well > as the many eyes working on the kernel, resulted in it coming to light > quickly. > > - A sendmail bug publicized back in 2006 (#CVE-2006-0058) was of > interest > because the vulnerability was not a "typical" buffer overflow, but was > due to > (if I remember correctly -- the discussion of this vuln was pretty > opaque at > the time, so I could be wrong on this) the intermixing of static and > automatic > C function variables in a fairly complex attack scenario (where a > residual > static pointer was pointing to a previous incarnation of an automatic > buffer), > resulting in an attacker being able to overwrite a section of the stack > if the > attack was timed "just right" (it didn't need the nanosecond precision > that > was widely publicized at first). A good example of complex code being > more > difficult to secure. > > - Greg Beeley > LightSys > > Matt Parsons wrote, On 03/16/2010 10:41 AM: > > > > > > Hello, > > > > I am working on a software security blog and I am trying to find open > > source vulnerabilities to present and share. Does anyone else have > any > > open source vulnerabilities that they could share and talk about? I > > think this could be the best way to learn in the open source > community > > about security. I have a few but I would like to blog about a > > different piece of code almost every day. > > > > > > > > God Bless. > > Matt > > > > > > > > > > > > http://parsonsisconsulting.blogspot.com/ > > > > > > > > > > > > Matt Parsons, MSM, CISSP > > > > 315-559-3588 Blackberry > > > > 817-294-3789 Home office > > > > "Do Good and Fear No Man" > > > > Fort Worth, Texas > > > > A.K.A The Keyboard Cowboy > > > > mailto:mparsons1...@gmail.com > > > > http://www.parsonsisconsulting.com > > > > http://www.o2-ounceopen.com/o2-power-users/ > > > > http://www.linkedin.com/in/parsonsconsulting > > > > http://parsonsisconsulting.blogspot.com/ > > > > http://www.vimeo.com/8939668 > > > > > > > > 0_0_0_0_250_281_csupload_6117291 > > > > > > > > untitled > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > --- > > > > _______________________________________________ > > Secure Coding mailing list (SC-L) SC-L@securecoding.org > > List information, subscriptions, etc - > http://krvw.com/mailman/listinfo/sc-l > > List charter available at - > http://www.securecoding.org/list/charter.php > > SC-L is hosted and moderated by KRvW Associates, LLC > (http://www.KRvW.com) > > as a free, non-commercial service to the software security community. > > _______________________________________________ > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L@securecoding.org > List information, subscriptions, etc - > http://krvw.com/mailman/listinfo/sc-l > List charter available at - > http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC > (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________
