Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111022005621.GA31654@openwall.com>
Date: Sat, 22 Oct 2011 04:56:21 +0400
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: hardlink(1) has buffer overflows, is unsafe on changing trees

On Fri, Oct 21, 2011 at 03:29:41PM +0530, Huzaifa Sidhpurwala wrote:
> On 10/20/2011 08:27 PM, Josh Bressers wrote:
> 
> >>The hardlink(1) program from Fedora is susceptible to buffer overflows of
> >>fixed-size nambuf1 and nambuf2 buffers when run on a tree with deeply
> >>nested directories and/or with long directory or file names.  I was able
> >>to reproduce the problem (got a segfault) by running the program on a
> >>directory containing 20 nested directories with 250-character names.
> >
> >CVE-2011-3630 hardlink buffer overflows
> >https://bugzilla.redhat.com/show_bug.cgi?id=746709
> 
> FORTIFY_SOURCE should really be able to catch this buffer overflow.
> The buffer being overflown here in in BSS, But strcat() is used to 
> append to this buffer and __builtin___strcat_chk catches it, resulting 
> in the program being terminated.

Besides the strcpy() and strcat() with obviously known target buffer
size, there are also:

          strcpy (stpcpy (nambuf2, n2), ".$$$___cleanit___$$$");

and:

      strcpy (p, di->d_name);

where "p" points somewhere inside nambuf1.

These will just need different reproducers.

Alexander

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.