| System: |
Linux/Unix
|
| Topic: |
Insecure output file handling in uudecode
|
| Links: |
AERAsec/uudecode-pipe-exploit code,
CVE: CAN-2002-0178,
Security Focus #4120,
RHSA-2002-065,
ae-200205-037,
SecurityFocus/Bugtraq VulnID 4742,
CERT VU#3360832,
CSSA-2002-040,
ae-200210-102,
OAR-2002:895,
ae-200210-110
|
| ID: |
ae-200204-033
|
Release time: 12 Apr 2002
uudecode is a small utility (mostly contained in package sharutils) which
decodes text previously encoded using uuencode.
Usually such text looks like i.e.
begin 644 /tmp/myfile.sh
M(R$O8FEN+W-H"F5C:&\@(DAE;&QO(&%L<V\A(@IE8VAO(")0<F]G<F%M.B`D
I,"(*96-H;R`B5'EP92`@(#H@:6YS=&%L;"!N;W<@82!P<F]G<F%M(@H`
`
end
uudecoding such text will normally create a new file named '/tmp/myfile.sh'.
Unfortunately, uudecode doesn't check whether this file already exists. Also it
doesn't check whether this existing file is a symlink or a pipe. In addition,
no user checks are done.
If using uudecode to extract data into unsecure directories (like /tmp or
/var/tmp) this can be used for a race condition and perhaps local root exploit, if root runs programs which extract
uuencoded data with filenames which are predictable by normal user.
AERAsec tests both methods 'symlink attack' and piping successfully on Linux systems.
This possiblitiy is sure not new, but AERAsec found this issue during inspecting shell code of an installer program
of a commercial Linux software which uses well-known filenames in unsecure
temp directories.
Affected sytems: possible all Linux/Unix
Affected applications: installers, which transport programs in uuencoded
data and filenames of unsecure directories, perhaps more...
Solutions:
1) On Linux use e.g. Openwall patch for
kernel 2.2.x to
avoid such symlinks and pipe attacks. This would be catched and logged
like:
kernel: Security: denied writing FIFO of 1001.100 by UID 0, EUID 0, process
bash:2591
kernel: Security: not followed symlink of 1001.100 by UID 0, EUID 0, process
uudecode:3348
For 2.4.x kernels using grsecurity
patch produces logs like
grsec: denied writing FIFO (tmp/testfile) of 1001.1001 by (bash:1258) UID(0)
EUID(0), parent (login:889) UID(0) EUID(0)
grsec: not following symlink (tmp/testfile2) [03:02]:193533 of 1001.1001 by
(bash:1258) UID(0) EUID(0), parent (login:889) UID(0) EUID(0)
2) Contact your Linux/Unix vendor for a more secure uudecode binary
3) Check installer programs whether they use uudecode for data transport,
e.g.
cat installerfile | grep begin
begin 600 /var/tmp/file1
begin 600 /var/tmp/file2
begin 600 /var/tmp/installer
Ask vendor whether such installer is secure enough...
Note 1 [16 Jul 2002]: in additition, block and char devices and Unix domain
sockets are also candidates
for protection, think about (on e.g. Linux systems):
begin 600 /dev/hda
...
Note 2 [16 Jul 2002]: the mentionend commercial program containing
the insecure uudecode usage in the installer is ISS
RealSecure Server Sensor for Linux (checked file: rsss6.5.2001.351-i686-linux-release.gz) with the
well-known (dig into the installer program...) file name for uuencoded data
"/var/tmp/dmn6.5.2001.351-i686-linux-release". ISS was informed on 10 Apr 2002
via e-mail and responded on 11 Apr 2002. Unfortunately they have not released a
fixed version until today on their download webpage.
|