Bug#242597: GNU Sharutils buffer overflow. (fwd)

[Santiago Vila]

Hello.

I received this from the Debian bug system.
[ Please keep the cc: lines when replying ].

Note: I agree this is not a security bug, but I think it is a bug.

---------- Forwarded message ----------
From: Shaun Colley <address@hidden>
To: address@hidden
Date: Wed, 7 Apr 2004 16:37:54 +0100 (BST)
Subject: #242597: GNU Sharutils buffer overflow.
Resent-Sender: Santiago Vila <address@hidden>

Package: sharutils
Version: 4.2.1


When an overly long string is fed to 'shar' when using
the '-o' command-line option, a small, fixed length
buffer is overflowed, and thus important execution
flow information can be overwritten, such as the
Instruction Pointer (EIP).

Here is my console output:

---
bash$ shar -o `perl -e 'print "a"x20000'`
Segmentation fault (core dumped)
---

By examining the core file produced, it is apparent
that various registers/pieces of memory have been
overwritten by the a's spilling over the boundaries of
the small buffer.

Below is the offending code, in shar.c:

--- shar.c snippet ---
[...]

static char output_base_name[50];

[...]

while (optchar = getopt_long (argc, argv,

"+$BCDFL:MPQSTVXZab:cd:fg:hl:mn:o:pqs:wxz",
                                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 ();
        break;

[...]
--- EO shar.c snippet ---

As you can see, the argument following '-o' is copied
into a buffer only 50 bytes in length, using the
dangerous 'strcpy' function, without bounds checking.
Obviously, this allows a user to supply a long
argument following the '-o' option, causing
'output_base_name' buffer to be overflowed - hence a
buffer overflow.

Although unlikely, this problem could be exploited by
a malicious user to execute arbitrary code, such as if
'shar -o ...' was invoked from a web CGI script, or if
a third-party SUID root application invoked 'shar -o
...' with user-supplied input.  Another possible
instance of when this might be exploited is maybe when
a user has a line invoking 'shar -o ...' in their
'procmailrc' file, which automatically invokes shar
with the vulnerable option when "trusted" contacts
send shar archives.

Despite it not being a major security threat, the
small likelyhood of it being exploited exists,
nonetheless.  It's quite easy to fix, though.

I suggest the following fix:

---
--- 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 @@
        break;

       case 'o':
-       strcpy (output_base_name, optarg);
+       strncpy (output_base_name, optarg,
sizeof(output_base_name));
        if (!strchr (output_base_name, '%'))
          strcat (output_base_name, ".%02d");
        part_number = 0;
---

The above patch could be modified a little bit, but it
does do the job.  When the above patch is applied, and
the Sharutils package is rebuilt, the buffer overflow
no longer exists - this is due to bounds checking,
implemented by the strncpy() call.  Only the first 50
bytes will be copied into the 'output_base_name'
buffer by strncpy(), thus eliminating the buffer
overflow problem.

This issue exists in the latest release of GNU
Sharutils - GNU sharutils 4.2.1.




Thank you for your time.
Shaun.







____________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping"
your friends today! Download Messenger Now
http://uk.messenger.yahoo.com/download/index.html