Die Panda Desktop Firewall lässt sich mit einfachsten Mitteln aushebeln.
Die Firewall filtert nur nach dem Pfad des auszuführenden Programms, was besonders bei Interpretersprachen fatal ist. Hat man einen Interpreter
freigegeben, z.B. /usr/bin/python2.4, der unter Anderem von Gajim (einem
Instant-Messenger) und QuodLibet (einem Music-Player) benutzt wird,
können andere Programme, die denselben Interpreter nutzen, ohne eine
weitere Warnung ins Internet.
Zum Testen installiert man also zwei Python-Programme wie Gajim und
QuodLibet. Startet man Gajim mit einer Jabber-Verbindung, so wird man
von der Panda-Firewall auf diese neue Verbindung hingewiesen und kann
sie aktivieren. Startet man nun einen RadioStream in QuodLibet, so kann
QuodLibet ohne eine weitere Warnung Daten mit dem Internet austauschen.
Eine weitere Schwachstelle ist, dass die Firewall keine Prüfsummen der
freigegebenen Anwendungen erstellt. Tauscht man also eine Programm-Datei
gegen eine andere - eventuell manipulierte - Version aus, fällt das der
Firewall nicht auf.
Nur als einfaches Beispiel: Den Textbrowser lynx in der Panda Firewall
freigeben und die /usr/bin/lynx gegen /usr/bin/wget austauschen. Lädt
man jetzt mit diesem umbenannten wget eine Datei aus dem Netz
lynx www.domain.tld/datei.txt
wird man von Panda nicht auf diese Manipulation hingewiesen. Man mag
natürlich argumentieren, dass das Manipulieren von Dateien in /usr/bin
nur für root möglich ist. Aber User installieren Software auch in ihr
Homeverzeichnis wo auch Malware die geeigneten Rechte hätte. (Das
betrifft u.a. auch Klik).
Nächste Schwachstelle: Fügt man ein Programm in die von Gnome zu
startenden Programme, sprich in die aktuelle Gnome Session ein, so
werden diese Programme zum Teil VOR dem Starten der Panda Firewall
ausgeführt. Eine Malware, hätte hier also Gelegenheit ihr Werk zu tun.
Als Beispiel. Fügt man das triviale Script
!/bin/bash
wget www.domain.tld/datei.txt
in die GNOME-Session ein. So hat man nach dem Einloggen die Datei
"datei.txt" auf der Festplatte.
Ob die Firewall also einen Schutz darstellt, muss bei solch trivialen
Exploits in Frage gestellt werden.
Auch der Mail-Schutz ist nicht sehr durchdacht. Erscheint einem die
Lösung mit einem Proxy in Anbetracht der Vielzahl an Mailclients unter
Linux anfänglich noch als eine gute Idee, so ändert sich das, wenn man
seine Mail über das SSL-IMAP-Protokoll liest.
Eine SSL-verschlüsselte IMAP-Session (getestet über den IMAPS-Port 993)
umgeht den Mailproxy. In einem Test mit einem gezippten Virus, wurde
dieser erst beim Versuch, ihn zum Entpacken auf der Festplatte
abzuspeichern entdeckt. Ein Virus, der beispielsweise über ein Bild eine
Lücke in einem Mailprogramm ausnutzt, würde so wohl eventuell nicht
entdeckt werden. Aus Mangel an einem geeigneten Beispielobjekt konnten
wir das leider nicht testen.
Benutzer alternativer Desktops scheinen gar nicht zur Zielgruppe des
Programms zu gehören. Auf einem Xubuntu-System konnte das Programm nur
mit spanischsprachigen Dialogen aufwarten und musste nach jedem
Einlogvorgang von Hand neu gestartet werden.
All diese Lücken im Schild wurden innerhalb weniger Stunden von einem
Nachtwächter und einem Maschinenbauer gefunden. Und das vollständig ohne
tiefgreifende Kenntnisse in Programmierung oder Reverse Engineering zu
benötigen.
Eine Diskussion wurde schon im Original-Forumsbeitrag begonnen.