Ist das ganze Message System nicht ein riesen Security Loch?
-
mgaeckler schrieb:
Es ist halt immer ein Problem, wenn man versucht ein System von einem Homecomputer in die professionelle Conmputerwelt zu migrieren. Hier merkt man halt ganz klar, wo die Wurzeln dieses Windows liegen.
Was genau meinst du damit? Wie wäre dieses "Problem" denn deiner Meinung nach zu lösen, bzw. wie löst man es in dieser "professionellen Computerwelt"? Einen Absender mitschicken und immer Abfragen, ist jedenfalls in etwa so sinnvoll, wie rund um die Uhr einen Clown vor die Bank stellen, damit etwaige Einbrecher was zu lachen haben...
-
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.
Das Problem ist natürlich, dass so eine punktuelle Absicherung nichts bringt wo eh jeder Prozess in jedem Prozess beliebig drin rumschreiben kann. 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.
-
DarkShadow44 schrieb:
Man kann Nachrichten, von Prozessen, die man nicht kennt, einfach verwerfen.
Da nun einmal Messages geschickt werden, interessiert es doch von wem.
Also aus dem eigenen Prozess(en) oder von einem Fremdprozess.Bringt nunmal nichts, zumindest nichts als Schutzmaßnahme. Wenn man überprüfen kann von wem die Message kommt gibt man halt vor das System zu sein...
Was ist das für eine Argumentation? Ein Schloß bei dem ich auch gleich den Schlüssel deponiere ist so sinnlos wie ein Kropf. Schreibst Du die Geheimzahl Deiner EC-Karte auf die Karte selber, weil sie eh nix nützt, da ein potentieller Angreifer, Dir ja eine Waffe an die Schläfe halten kann?
Ach ich hab noch ein Argument für Dich: Da Du gegen einen Atombombenschlag nichts ausrichten kannst, mußt Du Dein Haus nicht mehr absprerren. Nützt ja eh nichts.
Sorry mehr fällt mir dazu nicht mehr ein.
mfg Martin
-
dot schrieb:
Was genau meinst du damit? Wie wäre dieses "Problem" denn deiner Meinung nach zu lösen, bzw. wie löst man es in dieser "professionellen Computerwelt"? Einen Absender mitschicken und immer Abfragen, ist jedenfalls in etwa so sinnvoll, wie rund um die Uhr einen Clown vor die Bank stellen, damit etwaige Einbrecher was zu lachen haben...
Windows wurde vor rund 30 Jahren auf einem Einzelplatzsystem ohne irgendwelche Schutzmassnahmen konzipiert. Damals war die schlimmste Bedrohung für so einen Rechner Bootsektor- und Linkviren. Dagegen konnte man sich relativ leicht schützen. Das merkt man einfach der Windows API einfach immer noch an, auch wenn es mittlerweile einige Schutzmassnahmen gibt. Bei X11 sieht das z.B. ganz anders aus. 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.
MS hätte z.B. folgendes machen können:
Jede Nachricht, die mit PostMessage oder SendMessage verschickt wird, wird vom System mit der InstanceID des Absenders ergänzt. Der Messagepuffer, der von GetMessage bzw. PeekMessage gefüllt wird, enthält nun diese InstanceID. Anwendungen, die nicht ferngesteuert werden wollen, könnten nun überprüfen, ob die InstanceID zum System gehört oder zu einer anderen Anwendung. Ganz einfach.
Jetzt kommst sicherlich Du daher und sagst, aber MS könnte das schlampig implementiert haben und ein Angreifer, die Nachricht manipulieren, bevor sie ausgeliefert wird. Also nützt das nix. Mag sein, aber solche Fehler könnte MS beheben. Wenn die API das nicht hergibt, kann man auch nichts beheben ohne alle Anwendungen zu beeinflussen, denen das egal ist.
mfg Martin
-
nwp3 schrieb:
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.
Das Problem ist natürlich, dass so eine punktuelle Absicherung nichts bringt wo eh jeder Prozess in jedem Prozess beliebig drin rumschreiben kann. 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.Danke, Du hast es verstanden. Genau so habe ich es gemeint.
mfg Martin
-
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...
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...
http://theinvisiblethings.blogspot.co.at/2011/04/linux-security-circus-on-gui-isolation.html
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.
-
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...
Naja...
Zu dem Zeitpunkt wo NT gebaut wurde war diese Art von Sicherheit noch kein Thema.
-
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.
