Network Security

Network Security
Current Security Messages

After nearly 20 years of security news this service is discontinued. Some reasons are the very high number of vulnerabilities combined with automatically updating systems. So the necessity of this service is depreciated. We hope that you understand this decision.
Please visit us also at!

Most of the links lead to the corresponding files at CERT or other organisations. So changes take place immediately, especially which patches should be installed or which changes in the configuration should be made to avoid this vulnerability. Some of the files are transferred by FTP.

By the way: If we're not publishing well-known risks inheritant in any widely used platform or program that doesn't mean this particular platform or program is safe to use!

Here you find our network security search engine!

This is some information you send:

Your Browser

CCBot/2.0 (

Your IP address

(no reverse DNS resolution) []

Your referer

(filtered or not existing)

Current month, Last month, Last 10 messages, Last 20 messages (index only)

Chosen message with ID ae-200204-033

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/
uudecoding such text will normally create a new file named '/tmp/'. 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...

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.

(c) 2000-2017 AERAsec Network Services and Security GmbH