Ist das ganze Message System nicht ein riesen Security Loch?
-
dot schrieb:
mgaeckler schrieb:
Windows wurde vor rund 30 Jahren auf einem Einzelplatzsystem ohne irgendwelche Schutzmassnahmen konzipiert. [...]
In Geschichte hast du wohl leider so einiges nachzuholen...ich schlag vor, du fängst am besten dort an, nachzuschauen, was genau hinter dem "NT" in "Windows NT" steckt...
Mag sein, daß mein Geschichtswissen nicht so toll ist, Dein Leseverständniss tendiert jedoch gegen 0. Ich schrieb
mgaeckler schrieb:
Windows wurde vor rund 30 Jahren auf einem Einzelplatzsystem ohne irgendwelche Schutzmassnahmen konzipiert. [...]
Wenn ich von Windows NT schreiben hätte wollen, hätte ich geschrieben
Windows NT wurde vor ca 20 Jahren konzipiert.
dot schrieb:
mgaeckler schrieb:
Da muß ein X11-Client sich mit einem X11-Server explizit verbinden, da kann nicht einfach ein fremder Prozess einer Anwendung eine Nachricht schicken, heh der Benutzer hat gerade auf Shutdown geklickt.
Erklär mir doch bitte mal, wie genau dieses "explizit verbinden" auch nur irgendeine Form von Sicherheit bringt. Ist doch sogar genau das Gegenteil der Fall!? Es gibt hier überhaupt keine Isolation zwischen zwei vom selben Benutzer ausgeführten Anwendungen!? Nichtmal ansatzweise...Windows versucht es wenigstens...
Wo versucht Windows hier irgendeine Isolation?
dot schrieb:
http://theinvisiblethings.blogspot.co.at/2011/04/linux-security-circus-on-gui-isolation.html
Da sieht man mal, daß die Windows Freaks einfach die Natur von X11 nicht verstanden haben. Das ist nämlich Sache des X-Servers, unterschiedliche Clients unterschiedlich zu behandeln. Wer das nicht will, macht sich halt einen eigenen X-Server, der sich dann anders verhält ohne das X-Protokoll zu verletzen.
dot schrieb:
mgaeckler schrieb:
Jede Nachricht, die mit PostMessage oder SendMessage verschickt wird, wird vom System mit der InstanceID des Absenders ergänzt. [...]
Weiß nicht, wie oft ich es noch sagen muss, aber: Das nützt nichts. In dem Moment, wo eine Nachricht bei dir ankommt, ist es bereits zu spät.
Magst Du mich nicht verstehen, oder kannst Du nicht?
-
@mgaeckler
Die explizite Verbindung zum X Server ist aber tatsächlich vollkommen irrelevant.
Windows kennt auch den Account unter dem ein Prozess läuft, und die Session/Window-Station in der der Prozess läuft, und kann auf Grund dieser Informationen filtern.Der Grund warum die Filter so grosszügig beim Durchlassen sind, ist vermutlich historisch. Also damit nicht Unmengen an Programmen auf einmal nicht mehr funktionieren.
Wenn du versuchst aus deiner Session ne Window-Message an einen Prozess in einer anderen Session zu schicken, dann wirst du aber scheitern. (Kann sein dass es mit Admin-Rechten begrenzt möglich ist, aber allgemein geht es nicht.)
Ist das nicht "irgendeine Isolation"?Davon abgesehen ignorierst du immer noch fest dass Windows dir erlaubt in anderen Prozessen rumzupfuschen, so lange diese unter dem selben Account laufen wie der rumpfuschende Prozess.
Uns ist schon klar dass "das System die Absender-ID ausfülen kann". Dir ist nur nicht klar dass das nix bringt, weil der Absender die GetMessage Funktion im Empfänger-Prozess hooken kann, und dort einfach einif (msg.Absender == ich) msg.Absender = System;reinschreibt.
-
hustbaer schrieb:
Dir ist nur nicht klar dass das nix bringt, weil der Absender die GetMessage Funktion im Empfänger-Prozess hooken kann, und dort einfach ein
if (msg.Absender == ich) msg.Absender = System;reinschreibt.Es bringt nichts die Vordertür abzuschließen, die Hintertür ist ja offen.
Mit anderen Worten: Windows muss natürlich auch eine Möglichkeit bereitstellen, dass sich ein Prozess nicht hooken lässt, jedenfalls nicht ohne Zustimmung des Nutzers. Natürlich sind alle Sicherheitsmechanismen futsch sobald es ein einziges Sicherheitsloch gibt. Dann muss man halt alle Sicherheitslöcher stopfen.
Das ist aber eine Designentscheidung. Micro$oft sagt "Egal wenn ständig unser OS gehackt wird, solange es einfach zu benutzen ist ist es ok". Das ist eine vernünftige Entscheidung, aber nicht für jeden. Dass es kein anderes OS gibt was die Sicherheitsecke bedienen will ist tragisch. Eines Tages werde ich eins schreiben :p
-
hustbaer schrieb:
@mgaeckler
Die explizite Verbindung zum X Server ist aber tatsächlich vollkommen irrelevant.
Windows kennt auch den Account unter dem ein Prozess läuft, und die Session/Window-Station in der der Prozess läuft, und kann auf Grund dieser Informationen filtern.Danke für diesen Hinweis. Da muß ich Dir natürlich recht geben. Das Prinzip von Windows hat natürlich den Vorteil, daß der Fenstermanager von Windows weiß, mit welcher Kennung der Prozess läuft, zu dem ein Fenster gehört und kann daher Nachrichten von einem Prozess des Benutzers X zu einem Prozess des Benutzers Y blockieren. X11 hat diese Information nicht. Aber X11 hat die Information, welches Fenster zu welchem Client gehört und könnte beispielsweise nur einem Fenstermanager erlauben, fremde Fenster zu manipulieren.
hustbaer schrieb:
Der Grund warum die Filter so grosszügig beim Durchlassen sind, ist vermutlich historisch. Also damit nicht Unmengen an Programmen auf einmal nicht mehr funktionieren.
Das kommt, weil viele Basisfeatures von Windows darauf aufbauen.
DDE funktioniert mit Fensternachrichten. OLE baut auf DDE auf. All diese Features würden nicht mehr funktionieren, wenn Windows Nachrichten zwischen den Prozessen des selben Accounts blockieren würde.
hustbaer schrieb:
Wenn du versuchst aus deiner Session ne Window-Message an einen Prozess in einer anderen Session zu schicken, dann wirst du aber scheitern. (Kann sein dass es mit Admin-Rechten begrenzt möglich ist, aber allgemein geht es nicht.)
Ist das nicht "irgendeine Isolation"?Richtig. Diesen Fall habe ich aber jetzt auch nicht untersucht. Ich finde es aber auch schon problematisch, daß unterschiedliche Prozesse des selben Benutzers sich unkontrolliert Nachrichten schicken können. Sicher, in den meisten Fällen ist es unkritisch. Ich werde mich beispielsweise hüten meiner MIDI Software beizubringen, zu prüfen, ob die Nachrichten legitim sind. Das schlimmste, was ein Angreifer nämlich anrichten könnte, wäre, daß meine Synthis plötzlich auf der Bühne falsche Töne spielen.
hustbaer schrieb:
Davon abgesehen ignorierst du immer noch fest dass Windows dir erlaubt in anderen Prozessen rumzupfuschen, so lange diese unter dem selben Account laufen wie der rumpfuschende Prozess.
Uns ist schon klar dass "das System die Absender-ID ausfülen kann". Dir ist nur nicht klar dass das nix bringt, weil der Absender die GetMessage Funktion im Empfänger-Prozess hooken kann, und dort einfach einif (msg.Absender == ich) msg.Absender = System;reinschreibt.Hier kann ich Dir natürlich recht geben. Die Behebung des diskutierten Problems ist natürlich wenig zielführend, wenn man andere Scheunentore offen lässt.
mfg Martin
-
nwp3 schrieb:
Es bringt nichts die Vordertür abzuschließen, die Hintertür ist ja offen.
Eine bessere Analogie wäre wohl: Es bringt nichts, in der Straße dem Einbrecher aufzulauern, wenn man dem Haus zuerst alle Wände abreißt. Aber hier geht es ja wohl eher darum, alle Welt darauf aufmerksam zu machen, wie 1337 man sich doch in seiner "professionellen Computerwelt" fühlt, zu der Produkte von bösen kapitalistischen Firmen, deren Namen die lässigsten Wor$piele erlauben, natürlich nicht gehören, anstatt um den Versuch, das Problem zu verstehen...
-
Ach, ihr könnt euch doch überhaupt Nichts vorstellen was nicht von M$ vorgekaut wurde.
Man kann zum Beispiel in der MessageProc durchaus eine PID des Absenders mitgeben und 0 fürs System oder so. Das wird natürlich nicht vom schickenden Prozess beim Aufruf von SendMessage ausgefüllt, sondern automatisch vom System damit man eben nicht schummeln kann.Wie soll das sicher funktionieren? Ein Challenge Response System? Oder mittels Krypto-Funktionen? Wäre ein interresanter Ansatz, aber vermutlich etwas ineffizient.
Das Problem ist natürlich, dass so eine punktuelle Absicherung nichts bringt wo eh jeder Prozess in jedem Prozess beliebig drin rumschreiben kann.
Seit wann darf jeder Prozess andere Prozesse manipulieren?
Log dich mal als ein normaler Benutzer ohne viel Rechte ein. Da geht so einiges nicht mehr. (SetupDiGetClassDevs(),...).
Vermutlich ist das der Grund warum so viele ständig als Admin eingeloggt sind.
Das ist wahrscheinlich auch was mit Homecomputer vs professioneller Computer gemeint ist: Beim Homecomputer kann jeder Prozess alles machen, das macht vieles einfach. In professioneller Umgebung ist Sicherheit nicht völlig egal, und da kann man Windows vergessen. Linux übrigens auch.
Was ist den ein heutzutage ein professioneller Computer?
Im Allgemeinen verstehe ich dich hier nicht. Wenn es mir auf extreme Sicherheit ankommt, ist der Rechner nicht im Netz, der PC ist in einem Panzerschrank untergebracht und die Rechte der einzelnen Benutzer sind sehr strict definiert.
-
mgaeckler schrieb:
OLE baut auf DDE auf.
Das stimmt für OLE1, allerdings hat OLE2 vor ~20 Jahren bereits damit aufgeräumt. Das Flag COINIT_DISABLE_OLE1DDE kommt nicht von ungefähr! OLE1 hat den Sprung in dieses Jahrtausend glücklicherweise nicht überstanden.
-
Bitte ein Bit schrieb:
Log dich mal als ein normaler Benutzer ohne viel Rechte ein. Da geht so einiges nicht mehr. (SetupDiGetClassDevs(),...).
Glücklicherweise funktioniert SetupDiGetClassDevs, aufgerufen aus einem eingeschränkten User-Account, einwandfrei. Das Beispiel war jetzt nicht so der Burner.
-
Mox schrieb:
mgaeckler schrieb:
OLE baut auf DDE auf.
Das stimmt für OLE1, allerdings hat OLE2 vor ~20 Jahren bereits damit aufgeräumt. Das Flag COINIT_DISABLE_OLE1DDE kommt nicht von ungefähr! OLE1 hat den Sprung in dieses Jahrtausend glücklicherweise nicht überstanden.
OK, das mag sein, danke für den Hinweis, ich weiß das nicht so genau. Aber DDE gibt es immer noch.
mfg Martin
-
dot schrieb:
Aber hier geht es ja wohl eher darum, alle Welt darauf aufmerksam zu machen, wie 1337 man sich doch in seiner "professionellen Computerwelt" fühlt, zu der Produkte von bösen kapitalistischen Firmen, deren Namen die lässigsten Wor$piele erlauben, natürlich nicht gehören, anstatt um den Versuch, das Problem zu verstehen...
Ich finde es krass wie du urteilst, dass ich mich nicht mit dem Problem beschäftige. Windows hat Sicherheitsprobleme, eines davon wollen wir jetzt lösen, bzw. einen Lösungsvorschlag diskutieren. Ich finde das sehr löblich. Anscheinend ist es aber so extrem falsch und dumm was ich schreibe, dass du nicht glaubst, dass es ernst gemeint sein könnte oder ich mir das Problem überhaupt angesehen hätte.
Das Problem habe ich mir sehr wohl sehr lange überlegt und ich habe viele Ideen wie man es besser machen könnte. Bleibt also nur, dass ich so extrem dumm im Vergleich zu dir bin, dass meine jahrelangen Überlegungen gegen deine 5 Minuten-Überlegungen ein Witz sind. Deshalb erkläre mir bitte wieso es so dumm ist Sicherheitslücken schließen zu wollen bzw. Nachrichten auf Authentizität prüfen können zu wollen. Erklärung für Dumme natürlich.
-
dot schrieb:
Ein Prozess, der in der Lage ist, dir Nachrichten zu schicken, kann aber auf viel einfachere Art und Weise sowieso schon in deinen Prozess rein (DLL Injection; anyone?). Und sobald du dich nichtmehr darauf verlassen kannst, dass dein Code nicht sowieso bereits durch den anderen Prozess modifiziert wurde, wird dir alles Testen eines Absenders nicht mehr helfen...
dot schrieb:
In dem Moment, wo eine Nachricht bei dir ankommt, ist es bereits zu spät.
-
Ich kapier es immer noch nicht. Du bringst nur das Argument, dass das Schließen einer Sicherheitslücke nichts bringt, weil es noch andere gibt. Also kann man sich das Schließen von Sicherheitslücken komplett sparen. Dem widerspreche ich. Ein Betriebssystem kann sehr wohl verbieten, dass DLLs in den Prozess injected werden und dass der Speicher überschrieben wird und dass beliebig Nachrichten gefälscht werden können. Windows könnte sehr wohl verhindern, dass ein Prozess von einem anderen Prozess kompromittiert wird und Windows könnte auch garantieren, dass z.B. alle WM_MOUSEMOVE-Nachrichten tatsächlich von einem (verifizierten) Maustreiber und nicht von irgendeinem Prozess kommen. Demzufolge ist es nicht zu spät wenn ich die Nachricht kriege, es reicht, wenn z.B. eine MessageComesFromHardware()-Funktion hinzugefügt wird, die man auswerten kann wenn man möchte.
-
nwp3 schrieb:
Ein Betriebssystem kann sehr wohl verbieten, dass DLLs in den Prozess injected werden und dass der Speicher überschrieben wird und dass beliebig Nachrichten gefälscht werden können. Windows könnte sehr wohl verhindern, dass ein Prozess von einem anderen Prozess kompromittiert wird und Windows könnte auch garantieren, dass z.B. alle WM_MOUSEMOVE-Nachrichten tatsächlich von einem (verifizierten) Maustreiber und nicht von irgendeinem Prozess kommen.
Natürlich. Dann würde aber eine ganze Reihe von nützlichen Programmen nicht mehr funktionieren.
-
MFK schrieb:
nwp3 schrieb:
Ein Betriebssystem kann sehr wohl verbieten, dass DLLs in den Prozess injected werden und dass der Speicher überschrieben wird und dass beliebig Nachrichten gefälscht werden können. Windows könnte sehr wohl verhindern, dass ein Prozess von einem anderen Prozess kompromittiert wird und Windows könnte auch garantieren, dass z.B. alle WM_MOUSEMOVE-Nachrichten tatsächlich von einem (verifizierten) Maustreiber und nicht von irgendeinem Prozess kommen.
Natürlich. Dann würde aber eine ganze Reihe von nützlichen Programmen nicht mehr funktionieren.
Und ob das Manipulieren von Prozessen nützlich ist kann der Nutzer von Fall zu Fall festlegen. WOW-Bot ist nützlich, Virus der die Virenwarnung wegklickt ist nicht nützlich. Und schon wird ein ordentliches System draus.
-
MFK schrieb:
nwp3 schrieb:
Ein Betriebssystem kann sehr wohl verbieten, dass DLLs in den Prozess injected werden und dass der Speicher überschrieben wird und dass beliebig Nachrichten gefälscht werden können. Windows könnte sehr wohl verhindern, dass ein Prozess von einem anderen Prozess kompromittiert wird und Windows könnte auch garantieren, dass z.B. alle WM_MOUSEMOVE-Nachrichten tatsächlich von einem (verifizierten) Maustreiber und nicht von irgendeinem Prozess kommen.
Natürlich. Dann würde aber eine ganze Reihe von nützlichen Programmen nicht mehr funktionieren.
Korrekt, nur muß man halt die richtigen Prioritäten setzen. Es kann nicht sein, daß ALLE Rechner kompromitierbar sind, nur damit ein paar Leute irgendwelche nette Gimmicks ausführen können.
Kannst Du mir ein sinnvolles Beispiel für eine Problemlösung nennen, die diesen Schmarrn rechtfertigt?
mfg Martin
-
nwp3 schrieb:
Und ob das Manipulieren von Prozessen nützlich ist kann der Nutzer von Fall zu Fall festlegen.
Und wie soll das ablaufen?
-
mgaeckler schrieb:
Kannst Du mir ein sinnvolles Beispiel für eine Problemlösung nennen, die diesen Schmarrn rechtfertigt?
Eingabehilfen für Behinderte.
-
nwp3 schrieb:
Ich kapier es immer noch nicht. Du bringst nur das Argument, dass das Schließen einer Sicherheitslücke nichts bringt, weil es noch andere gibt. Also kann man sich das Schließen von Sicherheitslücken komplett sparen.
Das Problem ist, dass der Vorschlag hier keine Sicherheitslücke schließt, sondern eine Sicherheitslücke neu anstreicht, in der Hoffnung, dass ein paar alte, sehschwache Einbrecher vielleicht daran vorbeilaufen...
nwp3 schrieb:
Dem widerspreche ich. Ein Betriebssystem kann sehr wohl verbieten, dass DLLs in den Prozess injected werden und dass der Speicher überschrieben wird und dass beliebig Nachrichten gefälscht werden können. Windows könnte sehr wohl verhindern, dass ein Prozess von einem anderen Prozess kompromittiert wird und Windows könnte auch garantieren, dass z.B. alle WM_MOUSEMOVE-Nachrichten tatsächlich von einem (verifizierten) Maustreiber und nicht von irgendeinem Prozess kommen. Demzufolge ist es nicht zu spät wenn ich die Nachricht kriege, es reicht, wenn z.B. eine MessageComesFromHardware()-Funktion hinzugefügt wird, die man auswerten kann wenn man möchte.
Windows tut das alles doch bereits, dafür braucht es keine MessageComesFromHardware() Funktion oder sonstwas!? Das Problem ist, dass du deinem Windows, durch die Art und Weise, wie du es konfiguriert hast, ausdrücklich gesagt hast, dass es all das bitte ignorieren soll.
-
MFK schrieb:
nwp3 schrieb:
Und ob das Manipulieren von Prozessen nützlich ist kann der Nutzer von Fall zu Fall festlegen.
Und wie soll das ablaufen?
Genauso wie bisher auch.
Programm X will ins Internet: Zulassen | Verweigern.
Programm X will Programm Y Nachrichten schicken: Zulassen | Verweigern.
Programm X will in den Speicher von Programm Y schreiben: Zulassen | Verweigern.
Die DLL X soll ins Programm Y injiziert werden: Zulassen | Verweigern.Dann noch eine "Per Default alles Zulassen"-Option einbauen, damit die armen Omis nicht überfordert werden.
dot schrieb:
Windows tut das alles doch bereits!? Das Problem ist, dass du deinem Windows, durch die Art und Weise, wie du es konfiguriert hast, gesagt hast, dass es all das bitte ignorieren soll.
Vielleicht bin ich wieder nur zu blöd Windows zu bedienen, aber ich habe keine Ahnung wie ich Windows sagen kann, dass Notepad nicht DLL-injected werden darf. Oder dass Windows Media Player zwar meine P.. Videos lesen/abspielen, aber nicht löschen darf. Dass alle Email-Anhänge weder Prozesse manipulieren dürfen, noch auf Dateien aus meinem Home-Verzeichnis zugreifen dürfen.
-
nwp3 schrieb:
Dann noch eine "Per Default alles Zulassen"-Option einbauen, damit die armen Omis nicht überfordert werden.
Ich glaube, damit würdest du so ziemlich jeden User überfordern. Hast du deinen Browser auch so eingestellt, dass du jedes Cookie autorisierst, jedes Skript vor der Ausführung abnickst und jedes Plug-In manuell startest? Es geht ja nicht nur um die Entscheidung Ja/Nein. Du verlangst dem Anwender auch ab, dass er die Echtheit der angezeigten Informationen prüft und bewertet.
