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.