Sharutils buffer overflow bug.

[Shaun Colley]

Hi,

I've noticed a rather simple buffer overflow type bug
whilst looking at the shar source code (shar.c).  Note
that the issue does exist in the latest release of
sharutils, 4.2.1.

The bug occurs when parsing command line arguments for
the -o option.  Any option arguments passed with -o
are copied blindly into a buffer, without bounds
checking:

-- offending code --
[...]

static char output_base_name[50];

[...]

case 'o':
        strcpy (output_base_name, optarg);
        if (!strchr (output_base_name, '%'))
          strcat (output_base_name, ".%02d");
        part_number = 0;
        open_output ();
        break;

[...]
-- offending code --

As can be seen, output_base_name is only 50 bytes
long, so any arguments passed via the '-o' option
longer than 50 bytes should overflow the buffer, thus
causing a buffer overflow condition.

Below is a demonstration of how to reproduce the bug:

--- 
address@hidden sharutils-4.2.1]# shar --version
shar - GNU sharutils 4.2.1
address@hidden sharutils-4.2.1]# shar -o `perl -e
'print "a"x99999'`
Segmentation fault (core dumped)
address@hidden sharutils-4.2.1]# gdb -c core.5464
GNU gdb 5.2.1-2mdk (Mandrake Linux)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General
Public License, and you are
welcome to change it and/or distribute copies of it
under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as "i586-mandrake-linux-gnu".
Core was generated by `shar -o
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'.
Program terminated with signal 11, Segmentation fault.
#0  0x4009c6c6 in ?? ()
(gdb) info reg
eax            0x61     97
ecx            0x4806a301       1208394497
edx            0xbffe9cff       -1073832705
ebx            0x6f     111
esp            0xbffe70b8       0xbffe70b8
ebp            0xbffe7218       0xbffe7218
esi            0x80516c0        134551232
edi            0x3      3
eip            0x4009c6c6       0x4009c6c6
eflags         0x10202  66050
cs             0x23     35
ss             0x2b     43
ds             0x2b     43
es             0x2b     43
fs             0x2b     43
gs             0x2b     43
fctrl          0x0      0
fstat          0x0      0
ftag           0x0      0
fiseg          0x0      0
fioff          0x0      0
foseg          0x0      0
fooff          0x0      0
---Type <return> to continue, or q <return> to quit---
fop            0x0      0
xmm0           {f = {0x0, 0x0, 0x0, 0x0}}       {f =
{0, 0, 0, 0}}
xmm1           {f = {0x0, 0x0, 0x0, 0x0}}       {f =
{0, 0, 0, 0}}
xmm2           {f = {0x0, 0x0, 0x0, 0x0}}       {f =
{0, 0, 0, 0}}
xmm3           {f = {0x0, 0x0, 0x0, 0x0}}       {f =
{0, 0, 0, 0}}
xmm4           {f = {0x0, 0x0, 0x0, 0x0}}       {f =
{0, 0, 0, 0}}
xmm5           {f = {0x0, 0x0, 0x0, 0x0}}       {f =
{0, 0, 0, 0}}
xmm6           {f = {0x0, 0x0, 0x0, 0x0}}       {f =
{0, 0, 0, 0}}
xmm7           {f = {0x0, 0x0, 0x0, 0x0}}       {f =
{0, 0, 0, 0}}
mxcsr          0x0      0
orig_eax       0xffffffff       -1
(gdb) quit
---

It is obvious that the boundaries of
'output_base_name' are overflown - this just verifies
the suspicion given by the 'strcpy (output_base_name,
optarg)' call.

Notice the value of EAX:

---
eax            0x61     97
---

As we know, the hex value for 'a' is 0x61, so we
obviously have *some* control over some registers on
stack.  It is possible that ESP or EIP are
overwritable by supplying more garbage data via the
'-o' switch (increase the amount of a's I supplied,
for example).

The issue is definately a buffer overflow, I have
reproduced this condition many times, and it's pretty
obvious since the dangerous 'strcpy' call is used.


Although 'shar' is not SUID root or SGID, nor does it
have any other special privileges, I suppose this
issue still could be considered a security risk - I
assume that arbitrary code execution is possible due
to this bug, and if an Internet daemon or a CGI script
called 'shar' with user-specified data, this could
open the door to a security issue.

For example, say there was a silly CGI script which
let a user specify an output file to generate a shar
archive with, a naughty user could perhaps craft an
exploit buffer, pass it to the CGI script which calls
'shar -o <userinput>, and maybe run arbitrary code.

Just a thought.  Maybe it would just be a bug rather
than a vulnerability.

I'm sorry if this is already a known bug - I have
searched the Internet for 'shar buffer overflow' via
google and securityfocus.com/bugtraq for the same sort
of search.  I didn't find a bug report about it, so I
reported it.  Hope it helps :).



Thank you for your time.
Shaun.


        
        
                
___________________________________________________________
WIN FREE WORLDWIDE FLIGHTS - nominate a cafe in the Yahoo! Mail Internet Cafe 
Awards  www.yahoo.co.uk/internetcafes