Ich schreibe schon seit geraumer Zeit davon, dass die Erkennungsraten der Virenscanner langsam aber sicher schlechter werden und wir irgendwann einen Paradigmenwechsel weg vom Blockieren von Schadsoftware hin zum Erlauben von guter Software benötigen. Vielleicht wird es jetzt langsam soweit. Immerhin scheinen die False Positives der diversen Virenscanner so schmerzhaft zu werden, dass das Internet Storm Center (ISC) eine National Software Reference Library (NSRL) mit rund 40 Millionen Programmen und ihren Hash-Werten zusammengestellt hat.
Und jetzt könnte Cloud-Scanning plötzlich Sinn machen. Vor jedem Aufruf eines Programms oder einer ausführbaren Datei verifiziert das Betriebssystem das Programm gegen die NSRL und wenn das Programm enthalten ist, dann wird es ausgeführt (und das Ergebnis gecacht). Wenn nicht, prüft eine einfache Heuristik ob das Programm möglicherweise Schadcode enthält. Ich könnte mir vorstellen, dass damit die Abhängigkeit der Virenscanner von Patternupdates sinkt. Allerdings enthält dieser Entwurf noch viele ungelöste Probleme, beispielsweise wie eine manipulationssichere Kommunikation mit der NSRL möglich ist (DNS kann leicht manipuliert werden, HTTPS ist sehr aufwendig) und wie verfahren werden soll, wenn die NSRL nicht verfügbar ist. Außerdem halte ich die teilweise verwendeten MD5-Hashes für nicht gerade vertrauenerweckend. Und natürlich hilft das ganze Verfahren nicht gegen Schadprogramme die sich z.B. in Office-Dokumenten oder PDF verstecken.
Aber mein Eindruck ist, Whitelisting kommt, wenn wohl auch erst in einigen Jahren. Für die nahe Zukunft wünsche ich mir jedenfalls, dass die NSRL direkt in das Betriebssystem integriert wird und von verschiedenen Virenscannern einfach genutzt werden kann. Für Linux sollte sich sowas einfach realisieren lassen. Und wenn die NSRL (digital signiert) auf dem System vorhanden ist, kann ClamAV oder jeder andere Scanner auf diese Daten zurückgreifen.
(via Heise)
Hallo Christian,
da zeigst du ganz klar in die richtige Richtung. Wir haben vor Jahren Anti Exploit implementiert und uns mit dieser Problematik beschäftigt. Das Problem beim Whitelisting sind zunächst aber die Interpreter, hier sind allerlei Tweaks erforderlich. Und je mehr man darüber nachdenkt, desto mehr Probleme in dieser Klasse gibt es.
MD5 ist lange tot, aber das liesser sich alles reparieren. Die Prüfsummen könnte man auch für eine gewisse Zeit cachen, das würde gegen Serverausfällt (oder sagt man heute Cloudausfällt;) helfen. Wichtig ist daber aber ein TTL zu setzen, sonst kann man eine Signatur nicht mehr vernünftig zurückziehen. Interessant wäre sicherlich auch ein Web-of-Trust…
Unterm Strich denke ich ein kombinierter Ansatz aus Whitelist, Blacklist und WoT könnte interessant sein. Und Prüfsummen würde ich nicht auf Binary-Ebene sondern auf Segment-Ebene machen, da hätte ich irgendwie ein besseres Gefühl dabei.
Benjamin
Comment by Benjamin Schweizer — 20. Februar 2010 @ 21:08
Gut, das AntiExploit hat ja nun MD5-Prüfsummen für Exploits, also böse Programme. Ich kann aber zum Glück einen Compiler bedienen und ein paar Zeilen C schreiben mit dem Ergebnis, daß dann die Prüfsummen nicht mehr passen. Beliebtes Spiel auch bei Schadprogrammen, ein paar Bytes modifizieren und die Signatur passt nicht mehr, der Virus tut aber noch.
Mit dem Whitelisting gehe ich aber den umgekehrten Weg. Alle guten Programme erhalten eine Prüfsumme, die bösen nicht. Niemand kompiliert irgendwelche Windows-Bibliotheken neu und für den Linux-Kernel muß ich halt die Prüfsummendatei selbst anpassen. Jedenfalls können die Angreifer ihre Schadprogramme weitgehend verändern, sie kommen doch nicht durch. Wenn man konsequenterweise nur erlaubte Programme startet.
Der Witz ist, das könnte man jetzt schon wenn man nur alle Programme und Dateien konsequent digital signieren würde. Aber das läßt sich nicht realisieren, weil unsere auf Vertrauen basierende Zertifikatsinfrastruktur das nicht hergibt.
Meine Überlegung ging eigentlich in die Richtung, Virenscanner so zu verbessern/erweitern, daß primär Whitelisting stattfindet, d.h. z.B. alle Windows-Systemdateien als MD5-Hash bekannt sind und nicht mehr gescannt werden müssen. Dafür kann für alle unbekannten Programme eine möglichst paranoide Heuristik verwendet werden. Die darf gerne auch potentiell viele False Positives haben, weil alle wichtigen Programme in der Whitelist enthalten sind. So könnte man z.B. weitgehend auf Patternupdates verzichten. Ich sehe halt nur das Problem, daß heute Schadprogramme z.B. in der Hosts-Datei einträge manipulieren damit Virenscanner keine Patternupdates mehr laden können. In Zukunft werden die DNS-Abfragen manipuliert, damit keine Whitelist-Anfragen mehr möglich sind.
Es könnte interessant sein, im Rahmen eines Forschungsprojekts mal einen Virenscanner zu implementieren der Whitelisting mit einer Heuristik kombiniert und auf Patternupdates verzichtet.
Comment by Christian — 21. Februar 2010 @ 16:33
Hallo!
So etwas gibt es schon seit geraumer Zeit fuer NetBSD und nennt sich veriexec (http://www.netbsd.org/docs/guide/en/chap-veriexec.html).
Ich wuerde niemals ein System einsetzen wollen, dass online abprueft, ob ich ein Programm ausfuehren darf oder nicht (u.A. wegen von dir schon genannten Problemen).
Ist die Liste hingegen von mir selbst gepflegt (OSS sei Dank), so ist mir das Prinzip durchaus sympathisch.
Mir ist klar, dass man dies dem durchschnittlichen Windows-Anwender schon allein wegen dem Einsatz von closed-source Software nicht zumuten kann.
Insgesamt glaube ich, dass der Einsatz von Virenscannern weiter problematisch bleiben wird (heute: Snakeoil-Syndrom, kuenftig: Abgriff von Anwendungsnutzungsprofilen, Manipulation durch staatliche Stellen, usw.).
Comment by Thomas Penteker — 22. Februar 2010 @ 21:23
Hübsch. Interessant, daß es das nur für NetBSD gibt. Irgendwie scheint da noch kein besonderer Bedarf zu bestehen. Das erinnert mich an die Diskussion von Host-basierten IDS so um die Jahrtausendwende. Da rannten auch dutzende Vertreter rum und wollten Tripwire verkaufen aber so richtig zum fliegen ist das nirgends gekommen. Statt dessen hampeln wir mit DEP und ASLR rum.
Comment by Christian — 23. Februar 2010 @ 23:14
Ja, zusammen mit systrace ist das Ganze ziemlich maechtig.
veriexec fuer Linux waere schon cool..
Comment by Thomas Penteker — 24. Februar 2010 @ 00:57
Da wird sich nur leider keiner finden der das implementiert …
Comment by Christian — 24. Februar 2010 @ 17:22
Kommentare gesperrt wegen Spam
Comment by Christian — 10. April 2010 @ 18:37