[flo]

Bis jetzt ging es hier relativ friedlich zu, das soll auch so bleiben.

Wenn ihr aber trotzdem meint euch nicht an die Regeln zu halten, dann ziehe ich daraus die Konsequenzen.

(PS:Der den ich meine, der weis schon warum)

Dieser Beitrag wurde von Flo bearbeitet: 14. Oktober 2005 - 12:56

[Rika]

Ist kein Schadcode. Natürlich ist immer möglich, aus einer VM mit Paravirtualisierung (Xen, UML, ...) auszubrechen, man kann es bestenfalls etwas schwerer machen.
Reine Virtualisierung bzw. Pseudo-Virtualisierung a la VMware, VirtualPC (wobei ich sagen würde, daß da auch eingies an Paravirtualisierung drinhängt) oder Bochs ist theoretisch sicher und nur durch Implementierungsfehler umgehbar.

[W@yne]

Zitat (Flo: 14.10.2005, 13:56)

Wenn ihr aber trotzdem meint euch nicht an die Regeln zu halten, dann ziehe ich daraus die Konsequenzen.

Ich denke, dass es dem Boardfrieden nicht sonderlich zuträglich ist, wenn ein wild gewordener S-Mod hier regelmäßig Diktator spielt, weil ihm persönlich etwas gegen den Strich geht, was die Boardregeln nicht verletzt und darüberhinaus eine sinnvolle Konversation weiterbringt. Wenn man über Sicherheit diskutiert, sollte es kein Tabuthema sein, das zu kennen, was man bekämpfen soll. Himmelherrgottkruzifixzefixnochamol ... ich geh schlafen, bis denne...

[shiversc]

ich glaube du hast, mal eben, ganz grundsätzliche verständnisprobleme.

wenn ein team-mitglied etwas verbietet, was die regeln nicht hergeben, dann hat das den sellben charakter wie eine festgeschreibene regel. dabei speilt es überhaupt keine rolle welchen, offiziellen, rang dieser mod hat.

es ist und bleibt unerwünscht hier schadcode zu veröffentlichen.

[Rika]

<style>
.wrapper { border: 1px solid; }
.menu { position: relative;
display: inline;
white-space: nowrap; }
.menu a { padding: 1px; }
</style>
<div class="wrapper"><div class="menu"><a href="http://nowhere.invalid">
Ein Stück Code als Erläuterung einer inherenten Schwäche eines Konzeptes ist allerdings kein Schadcode, sondern etwas, daß man sich problemlos selbst aus dem Verständnis des Problems ableiten kann. Vor allem schadet er nicht.</a></div></div>

[jerrison]

ich würd mal gerne öffentliche schwachstellen sehen die zeigen, wie aus ner vmware umgebung ausgebrochen wird.
habe selber ipcop auf einer viruellen maschine im einsatz und KEINE sonstigen "internet" dienste dahinter, ist nur zum surf-schutz. Bisher gab es da gar keine probleme, und es geht schliesslich darum auch einfach anwendbare konzepte an heimuser zu vermitteln, denke ich.

[Graumagier]

jerrison sagte:

ich würd mal gerne öffentliche schwachstellen sehen die zeigen, wie aus ner vmware umgebung ausgebrochen wird.

Das ist nicht notwendig, da das nicht das Problem bei der Sache ist. Das Problem ist schlicht und ergreifend die Tatsache, dass die Pakete zunächst ungefiltert über den Host laufen.

[jerrison]

und wie sollen die pakete den host auch "erreichen" wenn der nur pakete vom gast animmt? macspoofen wäre natürlich noch eine option, aber was an "standard"-würmern und viren draussen da ist geht nicht auf sowas ein. und ein homesystem zu knacken ist wirtschaftlich nicht lukrativ, also, aufwand kontra nutzen.

[Graumagier]

jerrison sagte:

und wie sollen die pakete den host auch "erreichen" wenn der nur pakete vom gast animmt?

Das bringt bei Fehlern im TCP/IP-Stack oder bei DoS-Angriffen aber gar nichts.

jerrison sagte:

macspoofen wäre natürlich noch eine option, aber was an "standard"-würmern und viren draussen da ist geht nicht auf sowas ein.

Gegen "Standardwürmer" brauche ich aber keinen IPCop.

Dieser Beitrag wurde von Graumagier bearbeitet: 24. Oktober 2005 - 11:41

[puppet]

Ok, nehmen wir mal an du verwendest VMware auf einem System wo Windows läuft, dann verwendest du das Bridged Networking damit das Gast-System auch ohne Probleme (und ohne weiteren Aufwand) im Netzwerk vom Host-System erreichbar ist.
Nun kann man nicht nur am Host die Pakete für das Gast-System empfangen (der Kernel/IP-Stack vom Host verwirft die Pakete für das Gast-System ja einfach, das VMware Brdige Protocol was weiter unten liegt leitet die Pakete nur vor dem verwerfen an das Gast-System weiter, somit haben beide Systeme die Pakete erhalten), sondern man kann auch ohne Probleme am Gast-System die Pakete für das Host System mitlesen.
Bsp: Host-System mit Windows XP SP2 (hier: 192.168.0.1/fileserver-FastEt) mit VMware mit Linux 2.4 (hier: 192.168.0.22/nova), FE Interface vom Hostsystem ist mit dem VMnet0 gebridged (eth0).
Beim SSH Login von einem Client (hier 192.168.0.21/puppetxps) auf 192.168.0.22 (was ja das Gast-System ist) kann ich nun am Host ohne Probleme die SSH-Session mitverfolgen (decryption jetzt mal außen vor):

Da ja eine offene RDP-Verbindung zum Host-System besteht kann man somit vom Gast (hier über SSH) die RDP Verbindung verfolgen:

Hätte nun jemand wirklich in der VM mitgelauscht und z.B. den Aufbau der RDP Verbindung verfolgt hätte er somit schonmal ein Passwort um Zugriff auf das Host-System zu haben (-> aktueller RDP MitM Attack). Dies trifft auf den gesamten Netzwerkvehr vom Host-System zu, also auch Windows Datei- und Druckerfreigabe (NetBIOS, MS-DS/SMB), FTP-Server, RDP, VNC, Routingprotokolle, HTTP, POP3, SMTP usw.
Das ist natürlich dann ärgerlich wenn auf dem Host-System z.B. auch im Internet gesurft wird (so wie es letztens im Thread "Firewall-Idee" gepostet wurde), da man so ohne Probleme alles mitsniffen kann.

Dieser Beitrag wurde von puppet bearbeitet: 24. Oktober 2005 - 13:19

[jerrison]

in meiner lösung hab ich 2 nics verwendet, eine für das gastsystem (beim host deaktiviert) und eine für den host. geht dein ansatz nicht auch davon aus, dass sich jemand zutritt zu dem gastsystem verschafft? in der praxis also das virtuelle firewall system kompromiert?
diesen satz dann bitte genauer erklären: "da man so ohne Probleme alles mitsniffen kann"
was heisst "ohne Probleme"?
danke für die (auf)klärung

[Rika]

@shiversc: Seit nunmehr fast 11 Tagen steht mein Exploit für einen Boundary Error im IE hier drin. :-)

Zitat

und wie sollen die pakete den host auch "erreichen" wenn der nur pakete vom gast animmt?

Der Host muss sie erst einmal annehmen, um die sie an den Gast weiterzuleiten. Und idR macht man das nicht auf Layer 2, sondern auf Layer 3 und 4 und durchläuft damit den kompletten TCP/IP-Stack des Hostsystems und beachtet auch dessen Netzwerkfunktionen. Was passiert, wenn du's auf Layer 2 machst, hat 'puppet' ja schon erläutert.

[jerrison]

der ansatz geht doch aber davon aus, dass das gastsystem schon kompromitiert worden ist...in bezug auf die ssh session die vom gast beim host mitliest.
ausserdem sehe ich in meiner lösung vor alle protokolle von ersten nic (für VMWare dediziert) zu entbinden und nur die bridge zuzulassen.
das "ohne probleme" mitsniffen halte ich da immer noch für eine nicht belegte behauptung :).

[Rika]

Nochmal:
Wenn du Bridging betreibst, dann kann das Gastsystem kompromittiert werden und beim Hostsystem mitsniffen. Es ist logisch, daß das dann geht, und puppet hat's auch schon gezeigt. Außerdem kann auch das Hostsystem bei seiner Bearbeitung der Pakete bis auf Layer 2 kompromittiert werden.

Wenn du NAT betreibst, dann kann das Hostsystem bei seiner Bearbeitung bis auf Layer 3 und 4 kompromittiert werden.

In beiden Fällen bietet das Hostsystem auch noch, je nach Konfiguration, Layer 7 auf dem Präsentierteller an.

Klipp und klar: Firewalls sollen Netzsegmente voneinander trennen. Virtuelle Netzsegmentierung können kollabieren, reale Segmentierungen nicht.