GNU bug report logs - #16855
report a bug about shuf

Previous Next

Package: coreutils;

Reported by: valiant xiao <s2exqx <at> gmail.com>

Date: Sun, 23 Feb 2014 18:59:03 UTC

Severity: normal

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16855 in the body.
You can then email your comments to 16855 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-coreutils <at> gnu.org:
bug#16855; Package coreutils. (Sun, 23 Feb 2014 18:59:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to valiant xiao <s2exqx <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-coreutils <at> gnu.org. (Sun, 23 Feb 2014 18:59:03 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: valiant xiao <s2exqx <at> gmail.com>
To: bug-coreutils <at> gnu.org
Cc: xuyongjiande <at> sina.com, Yu Chen <chyyuu <at> gmail.com>, bug-shuf <at> gnu.org
Subject: report a bug about shuf
Date: Sun, 23 Feb 2014 16:03:59 +0800
[Message part 1 (text/plain, inline)]
Hi,


We have found a bug in shuf, and we think it may be result a security
problem.
we compile coreutils 8.22 which is download from
http://ftp.gnu.org/gnu/coreutils/, and run it on
my box that is ubuntu 12.04 x64. the bug details as follows.

### Bug overview

    shuf -er or shuf -eer [ segment fault]
    impact [coreutils 8.22 ]

```
[15:03:59]xqx <at> server:~/data/xqx/projects/coreutils-8.22$
./obj-gcov/src/shuf -er
Segmentation fault (core dumped)

```

### Analysis

    when shuf execute -e without give the expected input lines, it will
assign n_lines to 0 in "write_random_lines" while the "repeat" (-r) be set.
and this var will be as the genmax parameter when "randint_genmax" function
called. the code as follows in shuf.c:

```
369   for (i = 0; i < count; i++)
370     {
371       const randint j = randint_choose (s, n_lines);
372       char *const *p = lines + j;
373       size_t len = p[1] - p[0];
374       if (fwrite (p[0], sizeof *p[0], len, stdout) != len)
375         return -1;
376     }
377

```

    'j' will be a random number between 0-0xffffffffffffffff in my 64bit
ubuntu, and 'p' will be a unexpected point which will be access next. when
p point to an ilegal memory, it will be error when access it, which may be
result in a Segmentation fault.

    if an attacker could control the random which gened by randint_choose,
it may be get the infomation without an legal authority.  However, It may
be difficult.



yours

xqx
[Message part 2 (text/html, inline)]

Reply sent to Paul Eggert <eggert <at> cs.ucla.edu>:
You have taken responsibility. (Sun, 23 Feb 2014 23:38:02 GMT) Full text and rfc822 format available.

Notification sent to valiant xiao <s2exqx <at> gmail.com>:
bug acknowledged by developer. (Sun, 23 Feb 2014 23:38:03 GMT) Full text and rfc822 format available.

Message #10 received at 16855-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: valiant xiao <s2exqx <at> gmail.com>, 16855-done <at> debbugs.gnu.org
Cc: xuyongjiande <at> sina.com, Yu Chen <chyyuu <at> gmail.com>
Subject: Re: bug#16855: report a bug about shuf
Date: Sun, 23 Feb 2014 15:37:41 -0800
[Message part 1 (text/plain, inline)]
Thanks for the bug report.  I've committed the attached patch.
[shuf.diff (text/plain, attachment)]

Information forwarded to bug-coreutils <at> gnu.org:
bug#16855; Package coreutils. (Mon, 24 Feb 2014 01:05:02 GMT) Full text and rfc822 format available.

Message #13 received at 16855 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: 16855 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, s2exqx <at> gmail.com
Subject: Re: bug#16855: report a bug about shuf
Date: Mon, 24 Feb 2014 01:03:55 +0000
On 02/23/2014 11:37 PM, Paul Eggert wrote:
> Thanks for the bug report.  I've committed the attached patch.
> 
> shuf.diff
> 
> 
> From 24eb395471176e24762b08bfcef7562911537504 Mon Sep 17 00:00:00 2001
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sun, 23 Feb 2014 15:34:48 -0800
> Subject: [PATCH] shuf: with -r, don't dump core if the input is empty
> 
> Problem reported by valiant xiao in <http://bugs.gnu.org/16855>.
> * NEWS: Document this.
> * src/shuf.c (main): With -r, report an error if the input is empty.
> * tests/misc/shuf.sh: Test for the bug.
> ---
>  NEWS               |  3 +++
>  src/shuf.c         | 15 +++++++++++----
>  tests/misc/shuf.sh |  4 ++++
>  3 files changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/NEWS b/NEWS
> index e72942b..2df246d 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -22,6 +22,9 @@ GNU coreutils NEWS                                    -*- outline -*-
>    it would display an error, requiring --no-dereference to avoid the issue.
>    [bug introduced in coreutils-5.3.0]
>  
> +  shuf -r no longer dumps core if the input is empty.
> +  [bug introduced in coreutils-8.22]
> +
>  ** New features
>  
>    od accepts a new option: --endian=TYPE to handle inputs with different byte
> diff --git a/src/shuf.c b/src/shuf.c
> index d4641fe..2a91072 100644
> --- a/src/shuf.c
> +++ b/src/shuf.c
> @@ -576,11 +576,18 @@ main (int argc, char **argv)
>    /* Generate output according to requested method */
>    if (repeat)
>      {
> -      if (input_range)
> -        i = write_random_numbers (randint_source, head_lines,
> -                                  lo_input, hi_input, eolbyte);
> +      if (head_lines == 0)
> +        i = 0;
>        else
> -        i = write_random_lines (randint_source, head_lines, line, n_lines);
> +        {
> +          if (n_lines == 0)
> +            error (EXIT_FAILURE, 0, _("No lines to repeat"));

Thanks for the quick fix.

I was wondering if we do want to error if there is no input,
rather than silently exit(0)?

  $ shuf -r -n1 /dev/null
  shuf: No lines to repeat

I guess that makes sense since we can't fulfil the request
to repeat forever, or with -n; at least up to n.
I.E. rather than this being a transformation of the input,
the input in insufficient to generate the requested output.

thanks,
Pádraig.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Mon, 24 Mar 2014 11:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 10 years and 6 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.