Die Windows Sandbox wird immer mehr zu einer Spieloase. Nachdem Longorn herausgefunden hatte, dass die Sandbox das Passwort pw123 hat, konnte Tero Ahonen dann noch weitergehen und die Sandbox von außen steuern. Vor zwei Tagen hatten wir euch ja schon gezeigt, dass er es schaffte ein Programm auch nach einem Neustart starten zu lassen.
Normalerweise wird bei jedem Start der Sandbox eine neue Version installiert, damit alles was dort ausprobiert wurde auch gelöscht wird. In dem neuen Versuch von Tero hat er die Systernals mit dem Befehl psexec zu Hilfe gezogen, um über die Eingabeaufforderung in Windows 10 (Host) die Notepad.exe in der Sandbox (Gast) zu starten.
Ob das von Microsoft so gewollt ist, lassen wir mal außen vor. Solange man nur in die Sandbox kommt ist es ja noch ok. Umgedreht wäre es schon ein Sicherheitsproblem. Denn die Sandbox soll ja alles nach außen abschotten. Bis die Sandbox dann auch in der finalen Windows 10 Version erscheint, kann sich aber noch einiges ändern.
Auch wenn ich die Sandbox derzeit nicht gestartet bekomme, ist es interessant, was man doch schon alles machen kann, was die Redmonder so sicherlich nicht vorgesehen hatten.
Heute hab ich mal in die Glaskugel geschaut und gesehen, die Sandbox wird eine Totgeburt.
Vor allem denke ich das es die Sandbox eh nicht in die Finale 1903 schaft, da sie eben auch noch nicht bei jedem funktioniert. Haben wir ja schon öfter gesehen, wie z.B. die Tabs. Und 2 Monate dafür zum testen ist auch viel zu kurz. Wird also wohl wieder ein Rohrkrepierer.
Das mit den Tabs ist ja auch etwas schwieriger umzusetzen. Die Tabs haben alle auf EDGE aufgebaut. Microsoft wird ja schon lange vor der öffentlichen Ankündigung gewusst haben, dass sie EDGE in der jetzigen Form aufgeben und auf Chromium umbauen. Problem ist, dann ist EDGE keine UWP mehr, was die TABS in der Form wie es sie gab, nutzlos werden lässt.
Da muss noch einiges umgebaut werden, sodass die TABS funktionieren. Funktioniert haben diese ja nur mit Apps, der neue “EDGE” wird aber eine klassische Desktop Anwendung. Da wird Microsoft selbst noch nicht wissen, wie sie das dann umsetzen.
ja, beta. Man merkts
1. Sessiongenerierte Zufalls-Usernames und Passwörter. Starteste die Maschine neu lautet der Autologin auf einen ganz anderen Benutzernamen und ein ganz anderes Kennwort. Wichtig: Nicht basierend auf Zeit oder Hardware-ID. Zeichenfolgen die ähnlich YubiKey OTP erstellt sind (und dennoch von der Hardware-ID des Hosts abhängen).
2. Prozess der VM auf nt-authority\system Ebene sperren. Erwarte immer, dass ein Angreifer auf gleicher Berechtigungsebene kommt. – Somit ist der einzige Weg in die VM die buffer overflow code injection (Sprich: Den Host-RAM genau so zu manipulieren dass der VM-RAM-Anteil etwas falsches schreibt), was weitaus härter ist als remote process execution via psexec.
3. Um code injection zu minimieren… memory data encryption. Ich gehe davon aus dass MS das tut – (den VM-RAM im Host-RAM irgendwie verschlüsseln) – hierzu die Encryption Keys wie bei 1. von der Session abhängig machen. HW-ID, Zeit, Windows-Host-Lizenz, letzter Telemetriedatensatz etc. – Je mehr desto besser.
— pw123 . ich gehe wirklich stark davon aus dass es ein Symptom aus der Entwicklungszeit ist und genau so lange brauchen wird wie bei Android die AppOps (Berechtigungseinschränkungen von Apps in den Android-Einstellungen), also minimum noch 1 1/2 bis zwei Jahre zum stable-release vergehen werden.