seq bug -- out of bounds read (off by one)

[Daniel Dunbar]

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>