[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
seq bug -- out of bounds read (off by one)
From: |
Daniel Dunbar |
Subject: |
seq bug -- out of bounds read (off by one) |
Date: |
Sun, 23 Mar 2008 16:49:52 -0700 (PDT) |
Hi Jim,
Thanks for the quick reply on the ptx bug.
We have found another minor bug (non-crashing) in seq. An example problem input
is:
--
address@hidden:src$ ./seq -f %0 1
./seq: memory exhausted
--
The problem is in seq.c:213 (in 6.10 source),
if (! strchr ("efgaEFGA", fmt[i]))
which I believe should be
if (!fmt[i] || ! strchr ("efgaEFGA", fmt[i]))
In the cases when fmt[i]=='\0' then strchr returns a pointer to the end of the
"efgaEFGA" string,
and the subsequent for loop preface increments i, thus jumping over the
terminating null. The
for loop then performs out of bounds reads until the next 0 or %[^%]. We
attempted to get a
more interesting crash since this loop is incrementing suffix_len in the
meantime, but it appears
that all format string arguments that generate this bug are later rejected by
asprintf in print_numbers().
- Daniel
----- Original Message ----
From: Jim Meyering <address@hidden>
To: Cristian Cadar <address@hidden>
Cc: address@hidden; address@hidden; address@hidden
Sent: Friday, March 21, 2008 3:11:02 AM
Subject: Re: ptx bug -- unbounded buffer overflow
Cristian Cadar <address@hidden> wrote:
> Hello, I'm part of a research group at Stanford, working on
> automatic
> bug-finding tools. We are currently testing coreutils, and we
> found a
> crash bug in ptx due to an unbounded buffer overflow.
>
> Here is a trivial test case that triggers the bug in the
> current
> version of coreutils (6.10):
>
> $ ptx -F\\
>
> Another example, which overflows more bytes would be:
> $ ptx -F\\ abcdef
>
> (the overflow increases w/ the length of the second argument).
>
> The problem is in function copy_unescaped_string(const char
> *string),
> which in the presence of backslashes can advance the pointer
> "string"
> past the end of the buffer. This in turn causes an unbounded
> overflow
> of the buffer malloc-ed at the very beginning of the function,
> which in
> turn can be used to corrupt the heap metadata and crash the
> program.
Thank you for finding/reporting that. It is indeed a bug.
I've included a patch and a test-suite addition below.
Are your tools freely available?
If you have any more reports like that, please send them in soon.
I expect to make a new release in the next week or two.
<snip>
- seq bug -- out of bounds read (off by one),
Daniel Dunbar <=