Topic: Sandbox, AV und Co.: Damit bin ich nun sicher, oder? (Sicherheits-Sammelthread) (Read 2268 times)

Bei mir gibt das Kommando "ldd /bin/bash" laufend andere Adressen aus, bei mir sieht's also gut aus.

Hey kneim,


Dass scanelf beim Kernel keine Ausgabe produziert liegt daran, dass es nur die Infos zu ELF-Binärdateien zurückliefert. Der Kernel hingegen ist kein ELF-Binary. Er schafft erst die Bedingungen für das ELF.

Bei der scanelf-Geschichte hatte ich mich undeutlich ausgedrückt. Dafür bitte ich um Nachsicht.

Es kam mir vor Allem auf das fehlende "X" bei "STK" an. Das ist der Hinweis darauf, dass der Stack nicht ausführbar ist.

"ET_EXEC" (Flag für "ausführbare eigenständige Datei") oder "ET_DYN" (Flag für "Shared Object": Mir fällt gerade keine gute Übersetzung dafür ein) sagen für sich genommen nichts über die Schutzmechanismen eines Programms (vgl. man scanelf).

Als ein Test eignet sich da besser ein ldd (zweimal ausgeführt).

Ein Beispiel auf meinem Testsystem:

bill@mahoney ~ $ ldd /bin/bash
        linux-vdso.so.1 (0x00007395c4653000)
        libreadline.so.6 => /lib64/libreadline.so.6 (0x00007395c41e6000)
        libncurses.so.5 => /lib64/libncurses.so.5 (0x00007395c3f8c000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007395c3d88000)
        libc.so.6 => /lib64/libc.so.6 (0x00007395c39dd000)
        /lib64/ld-linux-x86-64.so.2 (0x00007395c4433000)
bill@mahoney ~ $ ldd /bin/bash
        linux-vdso.so.1 (0x0000685972062000)
        libreadline.so.6 => /lib64/libreadline.so.6 (0x0000685971bf5000)
        libncurses.so.5 => /lib64/libncurses.so.5 (0x000068597199b000)
        libdl.so.2 => /lib64/libdl.so.2 (0x0000685971797000)
        libc.so.6 => /lib64/libc.so.6 (0x00006859713ec000)
        /lib64/ld-linux-x86-64.so.2 (0x0000685971e42000)

Bitte beachte, wie sich die Adressen der eingebundenen Libraries verändern. Das zeigt, dass ASLR bei der /bin/bash tatsächlich greift.




KVM ist aber nur der Hypervisor. Du brauchst dann noch irgendwas, was das konfiguriert und aufruft. QEmu, AQEmu und LibVirt habe ich schon damit getestet. Eine Rundum-Sorglos-Lösung war keines davon.

Gruss
Bill

Hey flipperfish,


Das gilt IMHO auch weiterhin für ExecShield. Zumindest habe ich es bisher nicht in der Kernelkonfiguration gesehen. Vermutlich muss es gepatcht werden, wenn man kein RedHat, Fedora oder CentOS hat.
Im Standardkernel ist dafür aber PaX vorhanden. Grsecurity muss ebenfalls nicht mehr durch einen separaten Kernelpatch nachgereicht werden.

Standardmäßig scheinen bisher alle aktuellen Linuxdistros (abgesehen von "Damn Vulnerable Linux") ASLR einzusetzen. Wie es dabei mit den restlichen Schutzmaßnahmen aussieht, kann ich nicht beurteilen. Mir fehlt schlicht die Zeit, um mir selbst ein aktuelles Bild davon zu machen.

Das ist einer der Gründe, warum ich hoffe, in diesem Thread vielleicht etwas dazuzulernen.

Gruss
Bill

Die Ausgabe sieht so aus:
$ scanelf -e /bin/bash
TYPE      STK/REL/PTL    FILE
ET_EXEC   RW- R-- RW-    /bin/bash

Auf den Linux-Kernel angewendet, gab es keine Ausgabe.

randomize_va_space ist bei Debian 7.4 auf 2 gesetzt.

Danke für den Hinweis über KVM. Kannte ich noch nicht, sehe ich mir genauer an.

Wie sieht es denn damit derzeit bei den gängigen Linux-Distributionen aus? Als ich das letzte mal Nachforschungen zu diesem Thema angestellt habe, war es eher so, dass man noch zusätzliche Kernel-Patches wie "grsecurity", "execshield", etc. für alles, was über das NX-Bit hinausging, benötigte.

Wie schon erwartet: kein Beispiel gefunden.

/thread

Browserplugins die zum Standard gehoeren sollten:

Adblock, NoScript, Https everywhere.

Grueße

Das dürfte der wichtigste Tip sein.

Also alle Programme / Services weg, die nicht zum Arbeiten benötigt werden. Bei einer Standarddesktopinstallation läuft > 80% Müll, der nie benötigt wird. In vielen Fällen gehört der Virenscanner übrigens ebenfalls in diese Kategorie. Das meiste davon wird ein Standard-User aber leider auch nicht los. Beim Browser sollte man sich überlegen, ob man wirklich jedes verfügbare Plugin benötigt. Und ganz schnell ist man an dem Punkt, wo man sich entscheiden muss: Bequemlichkeit/Spielzeuge oder Sicherheit.

Hey giletto,


Prozesse im Taskmanager, top oder ps erzählen dir nur dann die Wahrheit, falls sich da nicht ein Rootkit eingenistet hat. Dieses kann bestimmte Aufrufe umleiten und dadurch eine heile Welt vorgaukeln.


Genau das war mal die Absicht hinter diesem Thread. Weil ich nicht alles wissen kann, wollte ich mal darüber diskutieren, wie so der Stand aus anderer Sicht ist.

Wie wäre es mit dem folgenden Empfehlungskatalog?

1) Das OS muss NX-Stack, Stack-Canaries und ASLR unterstützen. Weiter oben erwähnte ich Windows Vista/7 mit EMET. Das ist IMHO schon eine recht brauchbare Kombi. Windows XP ist wegen des fehlenden ASLR im Kernel keine Empfehlung mehr. Falls Linux, dann nur mit diesen Features.

2) Der Virenschutz hat sich nach diesen Features und der Firewall einzuordnen. D.h. auch hierbei muss der Virenscanner unter EMET gestellt werden. Sollte der das nicht verkraften (weil z.B. ASLR die Heuristik behindert), dann gehört der entsorgt und ausgetauscht.

3) Es sollte überlegt werden, wofür der Computer genutzt wird. Alles was in 90% der Fälle nicht mit dem Computer gemacht werden soll, gehört als Programm in die Tonne. Tests gehören ausgelagert (z.B. in VMs oder auf separate Rechner). Es ist eben besser, erst gar keine Bedingungen für Schädlinge zu bieten, als mit irgendwelchen Werkzeugen Infektionen bekämpfen zu wollen.

4) Backups sind sehr wichtig. Nicht nur beim versehentlichen Löschen von Dateien, sondern auch wenn mal doch Erpressungssoftware mit Datenverschlüsselung sich einnisten sollte.

Ich bitte um weitere Vorschläge, Ideen und Anmerkungen. Über eine sachliche Diskussion würde ich mich freuen.

Gruss
Bill

Edith wieder: Ich hatte nur auf den zweiten Teil reagiert. Die Antwort auf den ersten Teil habe ich oben mal kurz geschildert.

Hey oda.krell,


Wenn das deine Art zu diskutieren ist, dann bist du eh falsch hier. Du bleibst nicht sachlich. Aus meiner Sicht ist es kein Verlust, wenn du schweigst.


Was ich damit ausdrücken wollte, ist einfach nur, dass man heute nicht alles glauben darf, was im Internet oder per Buchdruck verbreitet wird.
Die Qualität in diesem Bereich hat in den letzten Jahren stark nachgelassen.


Heuristik in der AV-Industrie ist nur ein PR-Begriff. Ein sprachlicher Container. Deshalb sieht man auch kaum technische Details dazu. Du bist hier nur derjenige, der nicht kapiert, dass es sich dabei um einen Sammelbegriff für Beliebiges handelt. Es ist jedoch naheliegend, dass man einen "vollautomatischen Kaffeesatzleser am USB-Port" nicht so gut verkaufen kann, wie irgendwelche "dynamischen und statischen Analyseverfahren".

Um es in deiner Sprachwelt auszudrücken.

Ich: "Intel baut hauptsächlich Chips."
Du: "Nein, AMD baut Chips. Du liegst also falsch."
Ich: "Naja, Chips kann eigentlich jeder herstellen, da gibt es ja kein verbrieftes Recht zu."
Du: "Du liegst aber immernoch falsch, weil AMD Chips baut."

Weil du alles vorgekaut haben möchtest, formuliere ich das mal um.

Ich: "Heuristiken sind eigentlich nur statische und dynamische Analyseverfahren..."
Du: "Nein, Heuristiken sind HMMs. Du liegst also falsch."
Ich: "Naja, Heuristiken sind eigentlich ein unscharfer Sammelbegriff."
Du: "Du liegst immernoch falsch, weil Heuristiken nur das sind, was Google ausspuckt (HMMs)."

Merkst du was?


Och damit kann ich im großen Stil dienen. Sind ja genügend Exchanges in den letzten Jahren geplatzt. Früher oder später habe ich ein Beispiel, welches auch dir gefällt. Fangen wir also mal an: Vircurex, Mt. Gox, ... (wird vielleicht fortgeführt)

Es geht nämlich gar nicht um "mit FreeBSD, OpenBSD, Ubuntu, Windows, Debian, MacOSX, (beliebige weitere Systeme bitte hier einfügen) ist man sicher", sondern um die Einsicht, dass "wenn die genutzte Software Fehler hat, hilft nicht mehr viel".

Bis der nächste Patch kommt, kann man eigentlich nur beten, dass es nicht ausgenutzt wird. Glücklicherweise gibt es Kernelfeatures, welche die Welt wenigstens ein bisschen zusammenhalten.
Die Wichtigsten sind einfach "Nicht-ausführbarer Stack" (Linux: NX-Stack, Windows: DEP, Begriff erklärt sich selbst), "Stacksignalisierer" (Stack-Canaries oder auch Stack-Protectors, die sind dafür da, dass man nicht irgendeine unsauber implementierte Stackvariable so überschreiben kann, dass man die Rücksprungadresse manipulieren kann) und "Address Space Layout Randomization" (ASLR, Damit man sich nicht durch geschicktes Anspringen von Library-Funktionen ein ROP-Programm zusammenbauen kann). Es gibt noch einige andere Möglichkeiten, die verhindern, dass billigst erstellte (und verbuggte) Software den Totalschaden des Systems verursacht. Die bekanntesten Konzepte seien hier nur kurz erwähnt, weil sie immer noch nicht Endanwendertauglich sind: Role Base Access Control  und Mandatory Access Control. Die entsprechenden Programme hierzu heißen unter Linux SELinux (MAC, Fedora hat das standardmäßig drin), AppArmor (MAC) und Grsecurity (RBAC).
Jedoch diese Sachen vernünftig zu konfigurieren kann wirklich viel Zeit kosten. Deshalb sind die nicht für die breite Masse verfügbar. Die Ausnahme bildet Fedora, welche dafür vor Jahren mit Stack-Protectors äußerst sparsam umgingen (ob sich das geändert hat, kann ich nicht beurteilen). Auch hier ist die gesamte Sicherheit aber nur so gut, wie der schwächste Teil.

Außerdem habe ich nicht behauptet, dass AV komplett nutzlos sei. Nur sie haben nicht die Bedeutung, die sie sich selbst zuschreiben wollen. Es ist nur PR, weil da viel Geld drinsteckt.
Deshalb wird fieberhaft nach neuen Features gesucht. Aber ob das damit besser wird, bleibt abzuwarten. Bisher war die Nachrichtenlage eher ernüchternd.

Jetzt würde ich aber schonmal gerne etwas Sachliches von dir lesen.

Gruss
Bill

Dürfte eine der sichersten Methoden sein, rechtzeitig eine Infizierung zu erkennen. Früher hat mir eine Firewall unter Windows immer gesagt, welches Programm gerade wieder was in's Internet senden will.

Ich habe, wie oben beschrieben, mehrere gleiche Laptops, mit jeweils kleinem RZ in Form von VMs darauf. Der Ausgang in das Internet ist eine FritzBox. Wie könnte man da ein Netzwerk-Monitoring aufbauen? Ich bin kein Netzwerk-Crack, sollte also noch einfach zu bedienen und zu interpretieren sein.

Duerfte schwer sein, da ich Ein und ausgehenden Traffic per Monitor ueberwache, genauso wie ich Systemprozesse und anderen Prozesse immer wieder durchsehe, wer oder was sich da reingeschlichen hat.

Ich muss sagen: WOW, hier sind ja einige absolute Cracks am Werk, wenn ich das so lese. Was ihr hier an Fachwissen um euch werft, respekt respekt. Fuer so etwas habe ich nicht die Zeit, liest sich aber interessant.

Leider kann ich nicht unterscheiden, wer eventuell nur auf wichtig macht, und von wem es substantiell ist. Ich werd aber definitiv weiter lesen.

Eventuell bringt ja der eine oder andere eine - so ist es beinahe 100% sicher - Erklaerung fuer den Standard User. Es muss kein Nerd Rechner sein spaeter, in dem nichtmal das NSA einbrechen kann, aber falls ich etwas oben vergessen habe, waere es interessant, zu wissen wo die Luecke sein kann.

Kann man nie zu 100% wissen, aber wenn das zeitliche Verhalten, die Speicher und Prozesstabellen und der externe gemessene Netzwerkverkehr unauffällig ist, hat man schon mal viel gewonnen. Da ich auf meinem System auch entwickle, fallen mir öfters Unstimmigkeiten auf. Bisher waren es dann immer Fehler im Betriebssystem oder einfach ein unerwartetes Verhalten. Gerade das zeitliche Systemverhalten ist oft wertvoll, da man damit sogar Unstimmigkeiten im SMM Handler oder im Secure Mode findet, die sich einer normalen Analyse gerne mal entziehen. Wenn da plötzlich ein paar us fehlen, wird es spannend. Externe Uhren und Messgeräte lassen sich nun mal schlecht überlisten.

Richtig gemein sind allerdings die neueren Entwicklungen mit eigener Rechenkapazität. Die können bis zu einem auslösenden Ereignis das gesammte System überwachen und so bis zur Aktivierung komplett unbemerkt bleiben. Die Schadsoftware kommt in diesem Fall aber (bewusst oder unbewusst) vom (bzw. über den) Hersteller und nicht vom bösen Hacker.

Letzter Beitrag von mir zu diesem Thema, zu unerfreulich das ganze:

a) Jetzt auch noch Geschwurbel re: P=NP? Du lässt echt keine Gelegenheit aus, huh?
b) Was "Heuristik" im allgemeinen heisst ist völlig egal. Wie es im Bereich der AV verwendet wird: das identifizieren von unbekannten oder nicht sicher (via Signatur) erkannten Viren. Ende der Semantikdiskussion, hat nämlich rein garnix mit dem Thema zu tun.
c) Und jetzt auch noch vage Andeutungen Richtung Sicherheit unter Linux. Einfach mal *einen* dokumentierten Fall finden in dem Bitcoin durch Schadsoftware unter Linux abhanden gekommen sind. Wäre sehr gespannt das zu hören.

Hey oda.krell,


Metamorphe Viren ist einfach die Virenklasse, die Standardmuster (ich meine mich an 14 Verschiedene erinnern zu können) durchlaufen um die Signatur eines Virus zu ändern, ohne dessen Laufzeitverhalten zu beeinflussen. Das kann bei der Infektion eines neuen Systems geschehen.
Das Anwendungsgebiet ist die Signaturerkennung per Heuristik. Das liegt daran, dass Heuristik kein festgelegter Begriff ist und dass die Grenzen (ähnlich wie bei der Sandbox) verwaschen und nicht klar unterscheidbar sind. Eine Heuristik in z.B. der Graphen- oder Pfadsuche wäre z.B. der A*-Algorithmus. Nur weil wir jetzt noch eine Technik mit dem Etikett "Heuristik" aus dem Hut zaubern heißt das nicht, dass alle anderen Techniken keine Heuristiken waren. Vielleicht schaust du mal nach, was der Begriff "Heuristik" eigentlich meint. Dann wirst du wahrscheinlich zu dem Ergebnis kommen, dass damit nahezu alles bezeichnet werden kann, was irgendwie mit Suchen und Finden zusammenhängt.

Es geht bei dem von dir angesprochenen Themenfeld darum, eine bekannte Virensignatur in der Datenbank per Ähnlichkeitsanalyse mit einem Programm in Verbindung zu bringen, dessen Signatur eine völlig Andere ist. Mein letzter Stand ist der, dass es (noch) nicht richtig funktionieren würde. Besonders dann, wenn mehrere Muster kombiniert würden, wären die Erfolgsaussichten nicht allzu rosig.
Sollte das implementiert werden, wäre das wirklich mal was Neues. Das heißt nicht, dass es dann besser funktionieren würde, aber wenigstens könnten wir noch mehr Augenwischerei betreiben.

Wir hatten jedoch im letzten Jahr den Spaß, dass jemand P=NP bewiesen haben will. Wieso sollen wir nicht auch gleich mal alle anderen Probleme lösen können. Ist ja egal, dass es praktisch null Nährwert hat.

Außerdem ist Linux schon längst aus dem Welpenschutzstadium heraus. Da gibt es inzwischen auch ganz reale Bedrohungsszenarien.

Aber wenn du es eh viel besser weißt als alle anderen, dann kannst du doch mal ehrlich selbst einen Beitrag dazu schreiben. Darauf bin ich mal gespannt, wie du sachlich die Wichtigkeit der AV-Software erklärst. Bisher kam von dir wenig Überzeugendes.
Der Eindruck, dass du bisher nur pöbeln wolltest mag meiner subjektiven Meinung und der fortgeschrittenen Stunde geschuldet sein.

Gruss
Bill

Edith riet mir, dass ich nochmal Folgendes erwähne:
Für die "heuristische Erkennung" wie sie von oda.krell angeführt wurde, muss erst einmal eine Signatur des Muttervirus in der Datenbank vorhanden sein. Die AV-Hersteller betonten aber zuweilen vollmundig den Schutz vor noch unbekannten Bedrohungen durch Heuristiken. D.h. vor Bedrohungen, für die es eben noch keine Signatur gibt. Dass es sich dabei eben nicht um die von oda.krell erwähnte Lösung handeln kann, ist der naheliegende Schluss.

Mann, du bist lustig... Eine Mini-Vorlesung über's Halteproblem. Na danke.

Okay, wart mal 'ne Sekunde, ich geb dir im Gegenzug 'nen kurzen proof sketch von Gödel I.

[3 Seiten später]

uffz.

Und jetzt Gödel II.

[Mehr oder weniger nochmal das selbe wie oben, aber jetzt komplett formalisiert. Dann zwei Zeilen die zu 'ner reductio ad absurdum führen, und fertig.]


..

Okay, mal ernst für 'ne Sekunde: AV sind nicht mein Fachgebiet. Aber ein kurzer Blick in WP und Google Scholar und ich finde
http://link.springer.com/article/10.1007%2Fs11416-006-0028-7
die erwähnen dass sie HMMs für eine Ähnlichkeitsanalyse verwenden.

Und ohne zu wissen wie gut die Erkennungsrate ist, oder welche kommerziellen Scanner sowas implementieren, kann ich schon mal frei Schnauze (alleine durch Kenntnis von HMMs) sagen dass (a) dein "Halteproblem" Argument komplett danebengreift wenn die Heuristik via statistische Ähnlichkeitsanalyse des Codes läuft, und (b) triviale "obfuscation" auch schon mal nicht mehr greift, weil ein sauber konstruiertes HMM Modell das mit hoher Wahrscheinlichkeit durchschauen sollte.

Und damit sind wir zurück beim Startpunkt:

Ich hab nie behauptet Heuristik klappt perfekt. Wüsste ich ehrlich gesagt auch nicht, wie schon gesagt: AV ist kein Fachgebiet von mir.

Aber du bist derjenige der sich ziemlich weit aus'm Fenster gelehnt hat mit, ich zitiere:
"Heuristik kannst du aufgrund des damit verbundenen Halteproblems vergessen."
Und genau diese Aussage, dass AV Heuristik wertlos ist, bedarf eben deutlich mehr Evidenz als deine allgemeinen Auslegung warum das Halteproblem es *prinzipiell* (aber zum Beispiel nicht notwendigerweise *praktisch*, in vielen Fällen) unmöglich macht, dass Schadsoftware durch Ausführungsanalyse bestimmt werden kann.


P.S. Das ganze Thema kann, m.E., deutlich schneller abgefertigt werden: Wer Bitcoin in mehr als trivialen Mengen besitzt, macht das nur auf einem anständig eingerichteten Linux (Zweit)Rechner. Und, just like that, sind 95% der Angriffsvektoren verschwunden.

Hey kneim,


Virtualbox verwende ich nicht mehr, weil die Systemisolierung mir nicht weit genug ging. D.h. es war für mich ein Unding, dass einfach mal alle Treiber für sämtliche Hardware geladen wird, ohne dass diese in der VM zur Verfügung gestellt werden sollte.

Dafür habe ich damals Benutzbarkeit opfern müssen (ich bin auf einen angepassten Kernel mit KVM gewechselt).

Beim Copy-and-Paste kann ich dir nur raten, dass du aufmerksam bleibst, was du kopierst. Ich kriege das Beispiel im Augenblick nicht mehr reproduziert, aber ich hatte mal die Situation, dass ich einen Text in Unicode per Copy-And-Paste rüberholte und damit beinahe auf die Nase fiel. Vielleicht fällt mir das Beispiel irgendwann wieder ein. Es sah auf jeden Fall harmlos aus und war dann für mich so einer dieser "Oha!"-Momente.

Die andere Gefahr ist eher eine theoretische Erwägung, als eine praktische Erfahrung. Deshalb weiß ich auch nicht, ob es eine reale Bedrohung ist.

Wenn du einen gemeinsamen Speicherbereich zwischen Host und Guest hast, dann liegt dieser wo genau? Meine Vermutung ist (ich kann es momentan nicht nachprüfen), dass dieser beim Hypervisor abgelegt wird (das Stückchen Programm, welches mit SUID laufen muss). D.h. dass eine Schwachstelle im Speichermanagement potenziell den Weg zu einer Privilege-Escalation ebnen könnte (also Aufruf einer Rootshell mit SUID über den Hypervisor). Dabei wäre diese Schwachstelle ebenfalls vom Guest aus erreichbar bzw. könnte vom Guest aus befüllt werden. Allerdings halte ich persönlich das Risiko für sehr gering, weil deine Zusammenstellung nicht weit verbreitet ist und weil da jemand ganz genau wissen müsste, wie es bei dir aussieht. Die Guests zu exploiten kann man eben auch nicht einfach mal so aus dem Ärmel schütteln.

Mal eine Frage an dich.

Was sagt eigentlich: "scanelf -e " bei dir?

Die folgende Ausgabe sollte zurückkommen:

TYPE        STK/REL/PTL    FILE
ET_DYN   RW- R-- RW-     

Darüberhinaus sollte dich auch mal

cat /proc/sys/kernel/randomize_va_space

interessieren.
Als Rückgabe sollte im Idealfall eine 2 kommen.
0 bedeutet, dass es abgeschaltet ist und sollte so nicht eingesetzt werden. Ach, das hatte ich noch nicht erwähnt. Es geht hierbei um die ASLR in Linux per grsecurity.

Gruss
Bill

Hey oda.krell,


Wenn Fragen auftauchen, dann bitte diese auch als Fragen an mich stellen. Damit kann ich viel besser umgehen.
Dein Einwand ist jedoch berechtigt, deshalb antworte ich einfach mal, als ob du gefragt hättest: "WTF ist das Halteproblem? Und wieso ist das problematisch für einen AV-Guard?". Hoffentlich treffe ich damit den Sinn deines Beitrags.

Halteproblem
Das Halteproblem ist die Tatsache, dass es keine formulierbare Abfolge von Arbeitsschritten (Fachchinesisch: "Algorithmus") gibt, damit ein Programm entscheiden könnte, ob ein beobachtetes Programm in einer Endlosschleife steckt oder irgendwann in der (fernen) Zukunft von selbst anhält.

Also z.B. du hast ein Programm laufen, welches sich nach dem Start nicht auf der GUI zeigte und dennoch als Prozess im Taskmanager steht. Die Frage ist jetzt: Ist das vernünftig gestartet? Vermutlich nicht. Also wie lange muss ich warten, bis es sich von selbst beendet? Vielleicht eine Sekunde? Hmm, nein es läuft noch. Muss ich vielleicht fünf Minuten warten? Eine Stunde? Ein Jahr? Ab wann kann ich von außen erkennen, dass es gerade in einer Endlosschleife festhängt?

Für diese Problemsituation gibt es keine durch einen Algorithmus formulierbare Lösung. Es gibt also kein Programm, welches andere Programme überwachen und dann automatisch neustarten könnte, sobald diese in einer Endlosschleife hängen würden.

Anmerkung: Dieses Problem wird auf Kernelebene elegant umschifft, indem Programme (welche sich aufhängen könnten) sich mit speziellen Werten in bestimmten zeitlichen Intervallen zurückmelden. Hängt sich dann das überwachte Programm auf, dann verstummen die Rückmeldungen und der Kernel startet einfach aufs geradewohl neu (Fachchinesisch: "Watchdog"). Das geht meistens gut. Manchmal geht das schief. Die Ursachen dafür führen zuweit von dem hier besprochenen Thema weg.

Falls das Halteproblem bis hierhin noch nicht verstanden wurde, dann bitte ich um Nachfragen. Schließlich kann ich nicht in deinen Kopf schauen und feststellen, dass da noch Erklärungen benötigt werden.

AV-Guards haben es schwer
Virenscanner brüsten sich mit zwei grundlegenden Konzepten der Heuristikerkennung.
Erstens: "Wir lassen das in einer emulierten Umgebung (leider wird auch das landläufig als "Sandbox" bezeichnet!) laufen und schauen mal, was für Aufrufe das Programm versucht. Sind die kritisch, dann vermuten wir, dass es sich um eine Schadsoftware handeln könnte." (dynamische Analyse)
Zweitens: "Wir schauen in das Programm selbst und versuchen dessen Funktionen zu erraten." (statische Analyse)

Punkt zwei funktioniert nicht zuverlässig, weil das Durchsuchen von Code ebenfalls Speicherplatz und Prozessorzeit kostet. Für den Virenprogrammierer ist die Option dann einfach in den Op- oder Bytecode ein bisschen Füllwerk reinzuschreiben, welches nur (scheinbar) endlos Variablen von A nach B (oder nach C oder nach D...) schaufelt und den Schadcode erst dann aufrufen würde, wenn das passende Ergebnis rauskommt. Für den Parser bleibt der problematische Teil "inaktiv" und deshalb wird dieser nicht untersucht. Ganz zu schweigen davon, dass Codeobfuscating eine sehr effektive Disziplin der Codegestaltung ist und deshalb die statische Analyse wenig Chancen hat, "guten" Code von "bösen" Code zu unterscheiden.
Als weitere Option kann auch der eigentliche Aufruf in den Schadcode als (zur Laufzeit zu erzeugendes) Ergebnis einer Funktion festgelegt werden. Das sollte auch den fortschrittlichsten Parser abbrechen lassen.
D.h. wir haben hier das Halteproblem, weil nicht erkannt werden kann, dass es sich nur um eine Köderfunktion handelt, welche vom (inaktiven) Schadcode ablenken soll.
Eine Zyklenerkennung funktioniert auch nur unter der Voraussetzung dass genügend gescannte Codeteile sich nicht verändern (sog. "Invarianten", darauf fussen auch sogenannte "partielle Korrektheitsbeweise" (PCA)). Aber so eine sich selbst erhaltende dynamische "Endlos"-schleife frisst Ressourcen und Zeit (ohne dass etwas Schlimmes passiert), weshalb der Parser dann irgendwann abbrechen muss.
Sollte er das nicht tun, ist die Situation schlechter: Ein geschickt zusammengebautes Programm würde dann zu einer endlosen Wartezeit führen, in welcher der Parser nicht mehr genügend Ressourcen für andere Programme zur Untersuchung hat (die Warteliste wächst unaufhörlich) oder der Benutzer einfach genervt ist, weil nach zwei Stunden ein Programm immernoch nicht starten kann (es wurde "noch" nicht vom AV-Guard freigegeben, aber das wird bestimmt gleich erledigt sein...).

Der erste Punkt ist jetzt hoffentlich leichter zu verdauen. Der Virenhersteller muss nur eine Warteschleife vor dem Schadcode einbauen, welche den Schadcode erst nach sagen wir mal ca. 15 Minuten startet. Das kann auch durch ein Ereignis stattfinden, welches auf jeden Fall eintreten wird. Es kann sich dabei auch einfach nur um die "Aktivierung am Freitag, den 13." handeln (und nur dann!). Aber hierbei könnte man der statischen Analyse vielleicht auf den Leim gehen, wenn das nicht geschickt genug verschleiert wird.
Besser ist z.B. die Ackermann-Funktion vorneweg zu implementieren. Dafür gute Werte zu wählen und den Algorithmus durch Füllwerte und Tricksereien zu verschleiern. Auch hier laufen wir in das Halteproblem: Wieviel Zeit können wir das zu untersuchende Programm in der emulierten Umgebung testen, bis wir sicher sein können, dass es keine Schadsoftware ist? Wieviel Wartezeit können wir dem Anwender zumuten?

Manche AV-Guards öffnen darüberhinaus noch ein weiteres Tor: Beim Aufruf eines Programms wird nur dieses untersucht. Wird dasselbe Programm dann außerhalb des AV-Guards aufgerufen, so kann dieses Programm weitere Funktionen in einer Bibliothek nachladen, ohne dass diese Funktionen nochmal durch den AV-Guard wandern. Eine simple Abfrage "Sobald der Starter keine emulierte Umgebung erkennt, soll die Schadsoftware nachgeladen werden. Andernfalls spiele mit zwanzig Variablen Bäumchen-wechsle-Dich." ist heute nur eine Frage des zeitlichen Aufwands.

Keine guten Aussichten. Was wir mit der Heuristik im Allgemeinen erkennen können, ist nämlich nur die Schadsoftware, die in einem der nächsten Signaturupdates ohnehin aufgelistet worden wäre.

Gruss
Bill

Ein bisschen zu einfach, oder? Vielleicht wird dein Rechner laufend im Botnetz für Angriffe auf Bitcoin-Börsen missbraucht, ohne dass du es merkst. Obwohl ich Admin und vorsichtig bin, bin ich mir vor allem bei Windows nie wirklich 100% sicher.

In meinem Bereich nutze ich Laptops mit SSD und als Host-OS Debian Linux 7.4, ohne jeden offenen Port nach außen. Nichts installiert außer einer DVD-Brenner-SW und VirtualBox. root-Login ausgeschlossen, und für die Nutzung der VirtualBox-SW einen separaten Normal Account. Angeschlossen habe ich einen externen Monitor, so dass ich bis zu zwei VMs im Sichtfeld habe.

Alle Tätigkeiten erfolgen in spezialisierten Linux-VMs. Einige als Live-Systeme, z.B. Linux Tails, oder Linux Mint für den Schmutz. Einige sind normal auf virtueller Disk installiert, z.B. mit VPN unter Ubuntu Linux für die Wallets oder eine Linux-VM als Arbeitssystem. Auch eine Windows-VM für WISO Börse ist dabei.

Auf welchen Webseiten ich rumturne, überlege ich mir für jede VM sehr genau. Im Zweifel sind dafür die Live-Linux-Systeme da. Die Browser erhalten bei mir meist die Addons noscript, Ghostery und Addblock Edge, konfiguriert sind sie ähnlich wie bei Tor.

Das Copy-and-Paste zwischen den VMs habe ich eingeschaltet. Ich muss ab und zu Text, längliche URLs oder Public Keys zwischen den VMs kopieren, sonst wird der Aufwand einfach zu hoch. Inwieweit kann das ein Sicherheitsproblem sein?

Viel einfacher Bill: Mir wurde bisher weder irgendein Account gehackt, noch Geld gestohlen, noch sonst was. Seems to be safe, i guess.

AV Heuristik mit "Halteproblem" abzufertigen ist ungefähr so sinnvoll wie einem Grundschüler der die Grundrechenarten lernt davon abzuraten wegen "Gödel I und II".

Der einzige der hier Bullshitbingo (deine Worte) spielt bist du.

Hi nochmal,

VT-X Boards + CPUs kosten quasi nixmehr. Bei AMD bekommst den Kram schon fuer kleine 3-Stellige Euro Betraege hinterhergeworfen.
Intel ist auch nicht wirklich teurer.

Ich gebe dir grundsaetzlich Recht, das es weiterhin Angriffsflaeche gibt - auch beim Virtualisieren.
Aber es ist bedeutend schwieriger ein Hostsystem ueber ein Gastsystem zu infizieren.
Sofern beide Systeme Patchmaeßig aktuell sind.

Ausm Geschaeft sehe ich zumindest das VMWare mit den Patches nicht pennt. Sehr regelmaeßig wird geliefert.
Kann's allerdings nur aus 'Consumer'-Sicht betrachten. Bin kein Guru der in Adress- und -Treiberebene damit hantiert

Grueße

Hey sQueeZer,


VT-x (also sprich Codenamen "Vanderpool" und "Pacifica") sind ein alter Hut. Darüberhinaus werden dabei nur Guest-Maschinen-Operationen direkt auf der CPU ausgeführt. Wird kein Hypervisor gestartet, so gibt es die theoretische Option für einen Angreifer diese Funktionalität für eine Blue-Pill zu nutzen. MS hatte damals auch eine Studie angefertigt (einfach mal die 2006er Trends abgrasen, bin jetzt zu faul zum Suchen).

Was nicht virtualisiert wird, das ist die Hardware darunter. Die wird auch weiterhin vom Hypervisor abstrahiert. Es sei denn du nennst ein Board inkl. CPU mit VT-d-Unterstützung dein eigen (also der IOMMU-Kram).

Sollte der vorhanden sein, so wird dieser dennoch über den Hypervisor aufgerufen. Nur dass dann die CPU nichtmehr irgendwelche Hardware und deren interne Adressen emuliert sondern direkt an die entsprechenden Bereiche in der realen Hosthardware weiterverweist. Der Unterschied ist dann nur, dass der Hypervisor keine CPU-Zyklen mehr mit der Emulation und Auswertung der Hardware und ihrer Sprungadressen verschwendet, sondern direkt auf die vom Host bereitgestellte Hardware verweisen kann.

Alles in Allem fällt bei jeder Virtualisierung ein Hypervisor an, welcher die Jobs irgendwie auf die mehr oder weniger potente Hardware rüberkarrt.
Der Schwachpunkt bleibt also bestehen und das unabhängig, ob du jetzt Virtualbox, Xen, KVM, VMware oder den Microsoft-Müll meinst.

Gruss
Bill

Edith sagt: Das war missverständlich ausgedrückt.

Hi Bill,

da die aktuelle Hardware mittlerweile VT-x unterstuetzt und spricht (Und auch von Virtualisierungssoftware genutzt wird),
muss nichtmehr zwingend ueber das Host-OS mit der HW Kommuniziert werden.

d.h. Treiber werden nicht 'in einer Wurst'  durchgeschleift. Die VM Kann direkt auf die HW zugreifen.

Natuerlich ist ne VM kein Allheilmittel, aber es erschwert die Sache aus Angreifersicht ENORM an Schrauben zu drehen,
die er normalerweise nicht anfassen sollte

Wenn man jetz auch noch den Guest isoliert, Copy/Paste verhindert und das Netzwerk nicht NAT-ted sollte man relativ safe sein.
Logo wuerde ich trotzdem keine 100% igen Viren/Trojaner oder sonstwas ausfuehren..
Auch nehm ich besser keinen 'wichtigen' Rechner als Host..

Damit fahre ich sehr sicher, das weiß ich.

Grueße

Hey giletto,


Woher weißt du, dass du nie Schadsoftware auf die Rechner bekommen hast? Haben dir das Virenscanner gesagt?
Die haben doch immernoch keine bessere Schutzwirkung, als in den 1990ern. Seit Aho-Corasick (1975 veröffentlicht, irgendwann während der 90er in AV-Programmen implementiert) wurde zwar immer weiter an der Signaturspeicherung und der Erkennung der Signatur gefeilt (optimiert wurden Speicherbedarf und Scangeschwindigkeit), aber der zentrale Schwachpunkt ist und bleibt die ursprüngliche Virensignatur selbst. Das alleine bietet einfach keinen Schutz mehr.
Ach, und das Bullshitbingo wie z.B. "Heuristik" kannst du aufgrund des damit verbundenen Halteproblems vergessen.
D.h. sich auf Virenscanner zu verlassen, bietet heute keine echte Schutzwirkung mehr. Zwar sind diese noch hilfreich, wenn bekannte Schädlinge aufgespürt werden sollen, aber das Verhältnis von bekannten zu unbekannten Schädlingen dürfte eher im Bereich 1:10000 oder schlechter zu vermuten sein.

Was vor fünf oder zehn Jahren wenigstens halbwegs Sicherheit versprach, bietet heute keinerlei verlässlichen Schutz mehr. Das liegt einfach in der Tatsache begründet, dass sich seit dem Jahrtausendwechsel eine komplett eigene Industrie um die Programmierung und den Vertrieb von Schadsoftware gebildet hat. Die Sicherheitsforscher kämpfen seitdem auf verlorenen Posten, weil diese nicht im Ansatz die paradiesischen Bedingungen haben, welche die Ganoven den Programmierern mit Moraldefiziten anbieten. Auch hier werden wieder die Falschen vom globalen Gesamtsystem belohnt.

War für einen guten Angriff mit entsprechender Software um 2000 herum noch Expertenwissen notwendig, um auf den Ergebnissen von Aleph One aufzubauen und mit hohem Zeitaufwand eigene Software zu schaffen. So hat sich der Wind gedreht: Heutzutage wird lediglich ein Budget von ca. 50 bis 500 USD benötigt und die Fähigkeit, eine Maus zu benutzen.

Die sog. "Virus Construction Toolkits" (bekanntes aber veraltetes Beispiel: "ZeuS") gibt es heute in einer Qualität, die noch vor zehn Jahren undenkbar war. Inklusive der Garantie, dass die damit erstellten Module von verschiedenen Virenscannern mit mehr als 70% Wahrscheinlichkeit nicht erkannt werden können.

Es gibt sogar Patches, Zusatzfeatures, regelmäßige Bugfixes, Kundenwünsche und Support für den mittleren Geldbeutel (ca. 500 bis 1000 USD pro Jahreslizenz, bevorzugt Bitcoin oder Western Union). Die einschlägigen Foren dafür verlinke ich mit Absicht nicht, weil ich das nicht weiterverbreiten und damit Kriminellen die Arbeit erleichtern will. Dazu kommt, dass auch schonmal in solchen Foren Schadsoftware verbreitet wurde.

Metasploit sammelt nur den frei erhältlichen Teil in der bekannten Exploit-Kollektion. Man kann aber davon ausgehen, dass die zahlende Kundschaft deutlich bessere Exploits als Schadsoftware-Modul erhält.

Gruss
Bill

Hey sQueeZer,


Dein Ansatz ist von der erreichten Sicherheit besser (wegen der vollständigen Isolation des Betriebssystems). Zumal einige Schadsoftware eine VM-Erkennung mitliefert und diese sich nur dann aktiviert, wenn keine VM vorhanden ist.
Wird das Konzept streng durchgesetzt, kann auch nicht aus dem Guest in den Host kopiert werden (und umgekehrt). Das bedeutet z.B. dass auch Kopieren per Strg-C im Guest und Einfügen per Strg-V im Host nicht möglich sein darf. Die Benutzbarkeit leidet also darunter.

Was die Angreifbarkeit angeht: Es ist grundsätzlich denkbar, dass ein im Guest genutzter Treiber für die Interaktion mit dem Host ausgenutzt werden kannt (der offensichtliche Angriffsablauf wäre dann: Guest, Treiber, Hypervisor). Vom Hypervisor aus wäre dann der Weg frei in das Hostsystem oder schlimmer auf die Hardware.

Festzuhalten bleibt also, dass auch VMs kein Allheilmittel darstellen. Als Testumgebung sind sie deshalb nur solange empfehlenswert, wie der Verbreitungsgrad niedrig ist und darüberhinaus auch die VMs selbst nicht ins Visier der Virenindustrie geraten sind. Ob sie auch über diesen Punkt hinaus Schutzwirkung bieten, werden wir wohl erst wissen, wenn wir diesen Punkt erreicht haben.

Xen könnte hierbei ein bisschen bessere Karten haben, weil der Hypervisor sehr kompakt und damit die Softwarequalität etwas leichter auditierbar ist.
Das ist auch der Grund, warum Qubes-OS (Serverstandort: Irland) auf Xen setzt. Es würde sich dabei auch um eine sehr gute Lösung handeln, wenn es keinerlei Schwachpunkte (Golem, Serverstandort: Deutschland) gäbe.

Gruss
Bill

Fuer sowas hab ich nen VM-Template was ich mir einfach kopiere. Darauf starte ich dann diesen 'Dreck' und fertig.
Danach loesche ich die VM und erstelle mir aus dem Template ne neue.

Sandboxkram und co. halte ich fuer Muell und grob fahrlaessig.

Hey giletto,


An dieser Stelle ein klares "Jein" für deine allgemeine Aussage.

Geht es darum, dass Daten unerlaubt überschrieben werden könnten, so ist eine Sandbox wie z.B. Sandboxie (SandboxIE, Serverstandort: Amerika) durchaus sinnvoll. Also z.B. das Installieren eines Toolbars als Firefox-Plugin wird in den Sandbox-verwalteten Festplattenbereich umgelenkt (sofern Firefox in der Sandbox lief). D.h. die ursprünglichen Firefox-Dateien bleiben in diesem Fall unangetastet und dementsprechend ist es leicht, die ungeliebte Toolbar rückstandsfrei zu beseitigen. Dasselbe gilt für viele Versionen des BKA-/GVU-Trojaners.

Jedoch gibt es drei Dinge zu bedenken.
Erstens, auch die besten Sandboxen (z.B. Chrome) von den besten Programmierern können Bugs enthalten (Pwn2Own, Serverstandort: Amerika).
Zweitens, die darunterliegenden Bibliotheken werden in der Regel nicht isoliert. D.h. ein böswilliger Mensch, welcher mit einer Sandbox rechnet, könnte es mal mit Return Oriented Programming (kurz: ROP) versuchen (deutsche Wikipedia, Serverstandort: Amerika).
Gegen ROP hilft wiederum Address Space Layout Randomization (kurz: ASLR), welche unter Windows XP nicht vorhanden und auch nicht nachrüstbar ist. Unter Windows Vista/7 (vielleicht auch 8.x) ist das Konzept jedoch so kaputt umgesetzt worden, dass das Enhanced Mitigation Experience Toolkit (kurz: EMET, Microsoft, Serverstandort: Amerika) nachgereicht werden musste.
Drittens, eine Sandbox verhindert nicht, dass ein Windowsaccount ausgelesen und einfach mal an ein paar Server geschickt wird. Das war auch nicht das Ziel einer Sandbox.

Abschließend bleibt festzuhalten: Jegliche Software, welche nicht benötigt wird und/oder gegebenenfalls aus einer fragwürdigen Quelle stammt, sollte auf keinen Fall gestartet werden. Nicht in einer Sandbox und vor Allem nicht auf einem System, welches du für deine alltäglichen Aufgaben und auch wichtigen Dinge nutzen willst. Hingegen solltest du dennoch so oft wie nur möglich auf Sandboxen aus vertrauenswürdigen Quellen zurückgreifen. Die Sandboxen sollten wiederum durch EMET überwacht werden.
Alternativ hierzu kannst du auch für jeden Zweck auf dem Betriebssystem einen eigenen Useraccount anlegen und diesen nur für den geplanten Zweck nutzen. Jedoch hast du dabei Einbußen in der Nutzbarkeit zu erwarten. Einfach mal so aus einer eMail zitieren geht dann z.B. nicht, wenn du Surfen und eMail-Korrespondenz getrennt hast. Dafür kann ein Programm dann auch nur das nach außen leiten, was in dem aktuellen Account liegt.

Gruss
Bill