| System: |
Linux/Unix
|
| Topic: |
Unsicheres Anlegen von Dateien durch 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 ist ein kleines Programm (meistens im Paket sharutils beinhaltet)
welches Text, der zuvor von uuencode generiert wurde, dekodiert.
Üblicherweise sieht der Text folgendermaßen aus (Beispiel):
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
Wird dieser Text mit uudecode dekodiert, erzeugt dieser normalerweise eine
neue Datei mit dem Namen '/tmp/myfile.sh'.
Leider checkt uudecode nicht, ob diese Datei bereits existiert oder unter
diesem Namen ein symbolischer Link oder eine Named-Pipe angelegt ist.
Auch der Benutzer wird in diesem Fall nicht überprüft.
Startet root ein Programm, das uudecode benutzt, um Daten mit festgelegtem
Namen in unsichere Verzeichnisse zu extrahieren (wie z.B. /tmp oder /var/tmp),
so kann ein lokaler Angreifer beliebige Dateien des Systems überschreiben
oder die dekodierten Daten verändern.
AERAsec hat beide Methoden 'symlink attack' und 'piping' erfolgreich auf
einem Linux System nachvollzogen.
Diese Möglichkeit ist sicher nicht neu, aber AERAsec ist dieses Problem bei
der Inspektion von Shell-Code eines Installationsprogramms einer
kommerziellen Linux-Software aufgefallen, welche bekannte Dateinamen in
unsicheren Verzeichnissen benutzt.
Betroffene Syteme: wahrscheinlich alle Linux/Unix
Betroffene Programme: Installationsprogramme, welche selbst Programme in
uuencodierter Form transportieren mit Dateinamen in unsicheren Verzeichnissen,
eventuell weitere...
Lösungen:
1) Auf Linux kann z.B. der Openwall
patch für Kernels 2.2.x benutzt werden, um solche Attacken abzuwehren und
zu loggen:
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
Für 2.4.x Kernels gibt es den grsecurity
patch, welcher dann folgendes loggt:
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) Kontaktieren Sie Ihren Linux/Unix Hersteller, ob er eine sicherere Version
von uudecode zur Verfügung stellen kann
3) Überprüfen Sie Installationsprogramme, ob diese uudecode zum Datentransport
benutzen, z.B. mit
cat installerfile | grep begin
begin 600 /var/tmp/file1
begin 600 /var/tmp/file2
begin 600 /var/tmp/installer
Fragen Sie den Hersteller, ob solch ein Installer sicher genug ist...
Anmerkung 1 [16 Jul 2002]: zusätzliche schützenswerte Kandidaten sind block
und char Devices und Unix domain sockets, man denke nur an (auf z.B. Linux-Systeme):
begin 600 /dev/hda
...
Note 2 [16 Jul 2002]: das oben nicht näher genannte kommerzielle Programm,
welches den unsicheren uudecode-Aufruf in der Installationsroutine beinhaltet, ist
ISS RealSecure Server Sensor for Linux (überprüfte Datei:
rsss6.5.2001.351-i686-linux-release.gz) mit dem bekannten
(man muß nur das Installationsprogramm durchsehen...) Dateinamen für
uuencodierte Daten
"/var/tmp/dmn6.5.2001.351-i686-linux-release". ISS wurde am 10 Apr 2002
via e-mail informiert und antwortete am 11 Apr 2002. Leider haben sie bis
heute keine gefixte Version auf ihrer Download-Webpage zur Verfügung gestellt.
|