blog post and open source vulnerabilities to blog about

[Greg.Beeley at LightSys.org (Greg Beeley)]

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:mparsons1980 at 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 at 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.
> _______________________________________________