7740241 2002-01-03 00:13 +0100 /230 rader/ <SQEHXLLBQUJX@spammotel.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-01-03 00:46 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <20345>
Ärende: BSCW: Vulnerabilities and Problems
------------------------------------------------------------
From: SQEHXLLBQUJX@spammotel.com
To: bugtraq@securityfocus.com
Message-ID: <02010300133200.01518@somatic>
------------------------------------------------------------------------
-=\ BSCW Security Issues - Audit report 02 - 7. Sept. 2001 \=-
------------------------------------------------------------------------
BSCW is a groupware system that runs on a webserver. For more
information about BSCW visit the developer website
(http://bscw.gmd.de/ and http://www.orbiteam.de).
While auditing the BSCW system, i discovered two more vulnerabilities.
This document explains the vulnerabilities, how i did notice them and
what you can do to fix them.
-----------------------------------------------------------
-=\ Vulnerability no. 1: insecure default configuration \=-
-----------------------------------------------------------
Type:
Insecure default configuration.
Effect:
Gives unwanted people the possibility to
register as user of the BSCW server.
Software affected:
All 3.x versions of BSCW, version 4 not tested, but probably as
well.
Severity:
Low risk / Medium risk
Very high risk, if other security issues exists
Solution:
Think.
-=\ Description \=-
Normally the BSCW software is configured to allow self registration of
users. This enables the administrator to register himself as the first
user, after setting up the server. Self registration can normally
be done by accessing:
http://your.bscwserver.url/pub/english.cgi?op=rmail
Although allowing self registration of users can be a wanted
configuration, in most cases this isn't the case. Many BSCW servers
have are targeted to a closed user community. In my opinion the BSCW
system should register the server admin in the install procedure and
should not allow self registration out of the box. If the admins have
to enable the self registration of users by changing a configuration
file, they might think twice about it. The major danger of self
registration is not that you give unwanted users access to your
system and allow them to put files there. You give them access to a
complex script running on your webserver and the possibility to
exploit security holes. I checked for BSCW servers with a popular
internet search engine and was able to self register in quite a lot
of them, even on those that seemed to be there for a closed user
community.
You should think twice before setting up self registration, the better
choice is to change the configuration, so that only a couple of
trusted users are allowed to register new users.
Example (line of config.py located in your <bscw-dir>/src/):
MAY_REGISTER = ['joedoe','jane']
Allows the users "joedoe" and "jane" to invite new users into the
system. Note that users classified as admins are allowed to invite new
users also.
-------------------
-=\ Fix \=-
-------------------
No fix for this, as it isn't a real bug. Maybe a changed installation
procedure, without the need to enable self registration, would be a
good idea. If you don't need self registration of users, set the
MAY_REGISTER directive in your config.py file.
--------------------------------------------------------------
-=\ Vulnerability no. 2: shell meta characters not filtered \=-
---------------------------------------------------------------
Type:
Some shell meta characters are not filtered from user input when
calling external programs.
Effect:
Gives malicious a user the possibility to run any shell script he
wants, under the UID of the BSCW software.
Software affected:
All 3.x versions of BSCW running under Unix like OS. Version 4 not
tested (probably vulnerable too. edit: Bug has been fixed in the
21. Dec. Version 4 release). Depending on how external programs
are called under Windows, a similar vunerability may exist in BSCW
for Windows.
Severity:
Ouch. Very high risk.
Solution:
Change the way external tools are called immediately. If you dont
need and external conversion tool, diable it. Wait for a patch from
GMD/Orbiteam.
-=\ Description \=-
The BSCW system gives the users the possibility to convert files into
other formats (e.g. GIF into JPEG). This is done by calling external
tools. The user can enter the filename of the converted file. Since
the user input is handed as parameter to the external programs, which
are called via a shell, shell meta characters should be filtered out
of the user input. Most of them are filtered by BSCW, but there are a
few which aren't:
&;^()[]{}
The dangerous characters are "&",";","^". I'll explain the
vulnerability, using the conversion of a JPEG to a GIF as example:
After you have set your skill level in your userprofile to "Expert",
you have the ability to convert certain file formats into another
format. BSCW achieves this by calling external helper tools.
Lets say we have a file "test.jpg" in a folder we can access. We
click on the "convert" option. In the following dialog we choose our
settings for the conversion, we select "GIF" and "no encoding". We
can enter the name of the outputfile also, the default is the the
name of the file ("test.jpg" in our case). We dont change the
name. Hitting the convert button gives you a file named "test.gif".
Now we enter some shell meta characters as file name:
"'`/\|<>*?&;^()[]{}
And get an output similar like this:
Some text that the conversion wasnt successfully.
(
/bin/X11/djpeg -gif -outfile /BSCW/Tmp/@8279_1/&;^()[]{}
/BSCW/Tmp/@8279_1/@8279_2
) 2>&1
.
This is the output of the shell call which the BSCW system
did. Looking at the metachars you can see that "'`\|<>*? are
filtered, while &;^()[]{} are not. The @8279_1 and @8279_2 are
internal object reference codes that BSCW creates. Now we use ;ls; as
file name for the conversion (; is the command separator for shell
commands), we get something like:
/bin/X11/djpeg: can't open /BSCW/Tmp/@8558_1/
@8558_2
sh: /BSCW/Tmp/@8558_1/@8558_2: cannot execute
(
/bin/X11/djpeg -gif -outfile /BSCW/Tmp/@8558_1/;ls;
/BSCW/Tmp/@8558_1/@8558_2
) 2>&1
.
We executed the "ls" command (output is "/BSCW/@8558_1/@8558_2"). So
there is one file in this temporary directory, which is in fact our
"test.jpg" file. Then we get the "cannot execute" error, since the
shell tries to execute "/BSCW/Tmp/@8558_1/@8558_2" (we separated it
in the commandline by ";").
Now we create our exploit shell script:
echo code executed on webserver
uname -a
We use "test.jpg" as name for this script and upload it on the BSCW
server, setting the MIME type to "jpeg" manually in the upload
dialog. Since the BSCW creates the temp file for conversion without
the exec bit set, we have to execute by calling the shell with the
file as argument. We do this by giving ";sh" as file name for the
converted file:
/bin/X11/djpeg: can't open /BSCW/Tmp/@9586_1/
code executed on bscw server:
SunOS marin 5.8 Generic_111848-01 sun4u sparc SUNW,Ultra-4
(
/bin/X11/djpeg -gif -outfile /BSCW/Tmp/@9586_1/;
sh /BSCW/Tmp/@9586_1/@9586_2
) 2>&1
.
-------------------
-=\ Fix \=-
-------------------
The configuration for calling external conversion programs are in the
file "config_converters.py", located in the "/src" directory of your
BSCW installation. It contains one entry for each conversion
possibility (gif->jpeg, jpeg->gif, gif->ps ...). Those Entries look
like this:
# JPEG -> GIF (0.8)
('image/jpeg', 'image/gif', '0.8',
'/usr/bin/X11/djpeg -gif -outfile %(dest)s %(src)s',
'Colors, if more than 256'),
Change it to:
# JPEG -> GIF (0.8)
('image/jpeg', 'image/gif', '0.8',
'/usr/bin/X11/djpeg -gif -outfile "%(dest)s" "%(src)s"',
'Colors, if more than 256'),
Do this for all the conversion programs. That way parameters are
quoted and not interpreted.
Thomas Seliger
tom[at]wiretap(dot)de
(7740241) / <SQEHXLLBQUJX@spammotel.com>/-(Ombruten)