GNU Sharutils buffer overflow vulnerability.

From: Shaun Colley (
Date: 04/06/04

  • Next message: Joshua J. Berry: "[ GLSA 200404-03 ] Tcpdump Vulnerabilities in ISAKMP Parsing"
    Date: Tue, 6 Apr 2004 20:04:15 +0100 (BST)


    Product: GNU Sharutils -
                  shar utility
    Versions: Latest - GNU sharutils 4.2.1
                  Assumed all
    Bug: Buffer overflow
    Impact: Attackers can possibly execute arbitrary
    Risk: Low/Medium
    Date: April 6, 2004
    Author: Shaun Colley
                  Email: shaunige yahoo co uk



    GNU sharutils is a common GNU package, included with
    most Linux distributions, designed to create and
    unpack SHell ARchives, which are used to send large
    binaries through email with more ease.

    Vendor's description

    "GNU shar makes so-called shell archives out of many
    files, preparing them for transmission by electronic
    mail services. A shell archive is a collection of
    files that can be unpacked by /bin/sh. A wide range of
    features provide extensive flexibility in
    manufacturing shars and in specifying shar smartness.
    For example, shar may compress files, uuencode binary
    files, split long files and construct multi-part
    mailings, ensure correct unsharing order, and provide
    simplistic checksums.
    GNU unshar scans a set of mail messages looking for
    the start of shell archives. It will automatically
    strip off the mail headers and other introductory
    text. The archive bodies are then unpacked by a copy
    of the shell. unshar may also process files containing
    concatenated shell archives. "
    The 'shar' utility included as part of the GNU
    sharutils package is prone to a buffer overflow
    vulnerability due to lack of bounds checking when
    processing the '-o' command-line flag.
    A stack-based buffer overflow vulnerability exists in
    the popular 'shar' utility packaged in the GNU
    sharutils distribution, due to lack of bounds checking
    when handling the '-o' command-line option.
    During the command-line argument parsing routine, when
    the '-o' flag is encountered, 'shar' performs a
    'strcpy()' call to blindly copy the user-supplied
    argument after '-o' without bounds checking, into a
    fixed length buffer, output_base_name, which has only
    50 allocated to it.  
    Below is the offending code:
    --- shar.c snippet ---
    static char output_base_name[50];
    while (optchar = getopt_long (argc, argv,
                                    long_options, NULL),
             optchar != EOF)
        switch (optchar)
    case 'o':
            strcpy (output_base_name, optarg);
            if (!strchr (output_base_name, '%'))
              strcat (output_base_name, ".%02d");
            part_number = 0;
            open_output ();
    --- EO shar.c snippet ---
    As the above code snippet implies, the argument
    following the '-o' flag is copied into
    output_base_name, using the dangerous 'strcpy()' call.
     Since there is no check made on the length of the
    argument before copying it into a small, fixed length
    buffer, an excessively long string could allow for
    program flow control information to be overwritten,
    such as the Instruction Pointer (EIP), potentially
    allowing arbitrary code to be executed.
    Although the 'shar' utility is not SUID or SGID by
    default, nor does it run with any special privileges,
    if a website contained a CGI script which invoked
    'shar' with the '-o' switch and allowed a
    user-supplied filename for '-o', an attacker could
    potentially execute arbitrary command by successfully
    exploiting the buffer overflow condition.
    The '-o' option is the only command-line flag able to
    trigger this buffer overflow bug, as no other options
    cause 'shar' to perform a blind 'strcpy()' call with
    an unchecked buffer.
    The buffer overflow condition can be reproduced by
    supplying an overly long string following the '-o'
    option when invoking 'shar', in place of where 'shar'
    expects a base filename.
    Reproduction of the condition can be triggered by
    issuing a command similar to the one below:
    bash$ shar -o `perl -e 'print "a"x2000'`
    Segmentation fault (core dumped)
    Note that although GNU shar is not SUID or SGID by
    default, if a website contained a CGI script that ran
    shar with '-o' as a flag with user-supplied data, it
    may be possible for a potential attacker to execute
    arbitrary code.
    Another situation where this issue may be exploited by
    a potential attacker is when a third-party application
    with SUID/SGID privileges invokes 'shar' with the '-o'
    flag, with user-supplied data.
    I contacted the vendor, GNU, and received no response
    within 4 1/2 days.
    Although this issue isn't to be considered a serious
    security threat, there are instances where this can be
    exploited by a would-be attacker to execute code, such
    as in the circumstances suggested above (cgi script,
    sXid program, etc).  Therefore, it would be considered
    good practice to apply the fix regardless of whether
    your system is likely to be compromised as a result of
    the issue.
    I have written a simple patch below to fix the buffer
    overflow bug:
    --- shar-bof.patch ---
    --- shar.1.c    2004-04-06 16:26:55.000000000 +0100
    +++ shar.c      2004-04-06 16:32:32.000000000 +0100
    @@ -1905,7 +1905,7 @@
           case 'o':
    -       strcpy (output_base_name, optarg);
    +       strncpy (output_base_name, optarg,
            if (!strchr (output_base_name, '%'))
              strcat (output_base_name, ".%02d");
            part_number = 0;
    --- EOF ---
    Apply the patch, and rebuild:
    bash# patch < shar-bof.patch && make && make install
    Issue the above reproduction command, and a
    segmentation fault should no longer be produced.
    bash$ shar -o `perl -e 'print "a"x2000'`
    shar: No input files
    Try `shar --help' for more information.
    This issue was discovered and researched by Shaun
    Colley / shaun2k2 - <shaunige yahoo co uk>.
    The information contained within this advisory was
    believed to be accurate at the time of it's
    publishing.  However, it may be inaccurate at times,
    so don't consider any information 'set in stone'.
    Direct flames to /dev/null.  Don't waste my time and
    yours with emails complaining about my non-cooperation
    with standard and non-standard "disclosure" policies -
    I'm not interested.
    Thank you for your time.
    Yahoo! Messenger - Communicate instantly..."Ping" 
    your friends today! Download Messenger Now

  • Next message: Joshua J. Berry: "[ GLSA 200404-03 ] Tcpdump Vulnerabilities in ISAKMP Parsing"