headers
Ulf Harnhammar | 20 Apr 2005 17:43
Picon

Advisories and bugs since last time

Hello,

I failed concentrating on my university essay ;) I've done some work on it, but I've
also audited more stuff, resulting in DSA-700 and DSA-706. Number 700 is an XSS bug
in mailreader, that occurs because it uses spaces at the end of tags to signify that
they're OK but it forgets to remove tags that come in from the network with spaces
at the end. Number 706 is a stack-based remote buffer overflow in axel when handling
redirects. (More details can be found in my Advogato diary at
http://advogato.org/person/metaur/ .) Neither mailreader nor axel look especially secure,
so I'm sure someone who spends more time auditing them will find other vulnerabilities.

I have also found and filed some bugs:

#302273 (format strings cause crashes in didiwiki)
#302454 (trackballs follows symlinks as gid games)
#304525 (ilohamail has multiple XSS bugs)
#305255 (gzip (!!) has a directory traversal bug when using "gunzip -N")

The new OpenBSD song is out now BTW ;)

http://www.openbsd.org/lyrics.html#37

// Ulf Härnhammar
Permalink | Reply | 1 comment |
headers
Steve Kemp | 28 Apr 2005 02:27

My first Firefox bugs ..


  I've just reported two firefox + mozilla DOS bugs.

  Both cause 100% CPU + Memory usage, then a crash.

  Already fixed on the trunk branches, but affecting the most recent
 stable builds of both.

  More details when they are public :)

Steve
--
# The Debian Security Audit Project.
http://www.debian.org/security/audit
Permalink | Reply | 0 comments |
headers
Javier Fernández-Sanguino Peña | 28 Apr 2005 10:40
Picon
Favicon
Gravatar

Re: Advisories and bugs since last time

On Wed, Apr 20, 2005 at 05:43:25PM +0200, Ulf Harnhammar wrote:
> Hello,
> 
> I failed concentrating on my university essay ;) I've done some work on it, but I've
> also audited more stuff, resulting in DSA-700 and DSA-706. Number 700 is an XSS bug
> in mailreader, that occurs because it uses spaces at the end of tags to signify that
> they're OK but it forgets to remove tags that come in from the network with spaces
> at the end. Number 706 is a stack-based remote buffer overflow in axel when handling
> redirects. (More details can be found in my Advogato diary at
> http://advogato.org/person/metaur/ .) Neither mailreader nor axel look especially secure,
> so I'm sure someone who spends more time auditing them will find other vulnerabilities.

Added to the list in the website.

> I have also found and filed some bugs:
> 
> #302273 (format strings cause crashes in didiwiki)
> #302454 (trackballs follows symlinks as gid games)
> #304525 (ilohamail has multiple XSS bugs)
> #305255 (gzip (!!) has a directory traversal bug when using "gunzip -N")

Added too.

> The new OpenBSD song is out now BTW ;)

:-)

Regards

Javier
(Continue reading)

Permalink | Reply | 0 comments |
headers
Javier Fernández-Sanguino Peña | 28 Apr 2005 11:23
Picon
Favicon
Gravatar

Re: Six more + gpsd

On Wed, Jan 26, 2005 at 11:58:03PM +0100, Ulf Härnhammar wrote:
> Hello,
> 
> I have a bunch of new Debian bugs:
(...)

Added too.

Regards

Javier
Permalink | Reply | 0 comments |
headers
David A. Wheeler | 1 May 2005 04:18
Favicon
Gravatar

What kinds of tools work? How best to use tools? What doesn't work?

Hi -- I'd like to know what people here think about
tools to find/counter security vulnerabilities
(source scanning tools, fuzzers, etc.).

Can people here post their thoughts on how effective various tools are?
What works? What doesn't?  Are there tools or types of tools
that seem to be really effective, & when, or are they all hopeless?
What are the best ways to use them?  Is there any way to tell
that a tool is more effective than using only eyeballs & grep?

I _am_ the author of Flawfinder, but I'm not looking for
comments specifically on that. Instead, I'm trying to learn more
generally what works & what doesn't.  You don't need to
sugar-coat things; if something just isn't helpful, say so.

I'm aware of the info about security auditing tools at:
   http://www.debian.org/security/audit/tools
but that page just describes how to USE a few tools.
I want to know what tools/approaches seem to be EFFECTIVE.

Thanks for your time!!

--- David A. Wheeler
Permalink | Reply | 2 comments |
headers
Imran Ghory | 1 May 2005 13:56
Picon

Re: What kinds of tools work? How best to use tools? What doesn't work?

On 5/1/05, David A. Wheeler <dwheeler <at> dwheeler.com> wrote:
> Hi -- I'd like to know what people here think about
> tools to find/counter security vulnerabilities
> (source scanning tools, fuzzers, etc.).

Well I've though about this a bit as with a lot of tools I've had to
write wrappers or scripts to mangle their outputs into a more usefull
format. I primarily use source scanning tools and have found their
primary problem is generating false-positives, as these make it nearly
impossible to identify the real vulnerabilities,

Often simple heuristics can quickly identify if a vulnerability is
serious or not. For example for format string vulnerabilties I ignore
the output of flawfinder, its4, et al and instead rely on pscan, which
although it uses relatively crude tests is much better at correctly
identifiying format vulns.

There are some specific cases where pscan give false positives (for
example it reports gettext() uses as vulnerabilities, it can't
identify #defined constant formating strings as secure). And some
areas where it could be improved to find more vulnerabilities (for
example it could be used in conjuction with a variable taint tracing
system to identify user defined functions which are vulnerable to
format strings vulns and then add these to it's database). But despite
these problems I still prefer it over vuln scanners for this type of
vulnerability.

To give another example of a crude heuristics I use myself is for
sprintf type buffer overflow bugs, I check what format specifiers we
are using, sprintf(dest, "%s", evilvar) is much more risky than
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steve Kemp | 1 May 2005 19:39

Re: What kinds of tools work? How best to use tools? What doesn't work?

On Sat, Apr 30, 2005 at 10:18:26PM -0400, David A. Wheeler wrote:
> Hi -- I'd like to know what people here think about
> tools to find/counter security vulnerabilities
> (source scanning tools, fuzzers, etc.).

  An interesting topic.

> Can people here post their thoughts on how effective various tools are?
> What works? What doesn't?  Are there tools or types of tools
> that seem to be really effective, & when, or are they all hopeless?
> What are the best ways to use them?  Is there any way to tell
> that a tool is more effective than using only eyeballs & grep?

  I've been thinking about this for a while and here are some comments.

  One thing I think is growing on me is that most of the automated
 scanning tools have way too many false positives to be as useful as I'd
 like.  When you end up having to look at each one by hand it takes
 almost as long as it would if you were to use your eyes in the first
 place!

  As Imran said earlier there are a lot of cases where some simple
 heuristics which are easy to describe can make a lot of difference,
 but they may be hard to code, or may just be wrong!

  Right now the biggest success I've been having has come from using
 a set of protocol fuzzers.  Things that will generate "random"
 output which can be fed to tools.  The big problem is that these
 are very much domain specific.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane