Ist das ganze Message System nicht ein riesen Security Loch?
-
hustbaer schrieb:
mgaeckler schrieb:
[Es kann nicht sein, daß ALLE Rechner kompromitierbar sind, nur damit ein paar Leute irgendwelche nette Gimmicks ausführen können.
Moment, du vermischt hier was!
Wenn ich einen Prozess übernehmen kann, der unter meinem eigenen Account läuft, dann ist deswegen noch lange nicht das ganze System kompromitiert.OK, ich habe mich nicht klar genug ausgedrückt. Ich meine natürlich nicht unbedingt, daß gleich das ganze System übernommen wird, aber es genügt ja schon ein Autostartobjekt in HKEY_CURRENT_USER zu installieren, das bei jeder Anmeldung des Benutzers gestartet wird. Dieses könnte dann den Rechner Teil eines Botnetzes werden lassen oder versuchen, Passwörter auszuspionieren. Gerade letzteres scheint ja wohl mit der DLL-Injection nicht besonders schwierig zu sein.
Es soll ja auch generel ziemlich einfach sein, so manchen Leuten eine Schadsoftware unterzujubeln. Man denke nur an Mails mit Anhängen wie z.B. GeileMuschis.jpg.exe. Wenn so ein Anhang sinch dann auch noch leicht per DLL-Injection in eine andere Anwendung einhängen kann, dann halte ich das für sehr bedenklich. Mal schauen, was diese Windows Integrity Mechanism bringen.
mfg Martin
-
mgaeckler schrieb:
OK, ich habe mich nicht klar genug ausgedrückt. Ich meine natürlich nicht unbedingt, daß gleich das ganze System übernommen wird, aber es genügt ja schon ein Autostartobjekt in HKEY_CURRENT_USER zu installieren, das bei jeder Anmeldung des Benutzers gestartet wird.
Sowas kann ein Prozess natürlich nur, wenn er entsprechende Rechte hat...
mgaeckler schrieb:
Gerade letzteres scheint ja wohl mit der DLL-Injection nicht besonders schwierig zu sein.
Ja, so ist das halt; ist ja nicht so, dass Code Injection unter anderen Betriebssystemen, wie z.B. Linux, irgendwie weniger einfach wäre...
-
hustbaer schrieb:
Ey, nochmal: du übersiehst hier dass man das nicht in allen Fällen machen kann.
Das geht z.B. wenn ich ein Programm A starte, und ein Programm B in der selben Session starte, beide unter meinem Account laufen lasse, dann können die sich gegenseitim im Speicher rumpfuschen.Das finde ich schlimm genug, sonst hätte ich geschrieben, daß da 100 Zeppeline nebeineinander durchpassen. Dann wäre nämlich das gesamte Berechtigungsystem von Windows für die Katz.
mfg Martin
-
mgaeckler schrieb:
hustbaer schrieb:
Ey, nochmal: du übersiehst hier dass man das nicht in allen Fällen machen kann.
Das geht z.B. wenn ich ein Programm A starte, und ein Programm B in der selben Session starte, beide unter meinem Account laufen lasse, dann können die sich gegenseitim im Speicher rumpfuschen.Das finde ich schlimm genug, sonst hätte ich geschrieben, daß da 100 Zeppeline nebeineinander durchpassen.
Was empfielst du denn als sichere Alternative?
-
dot schrieb:
mgaeckler schrieb:
OK, ich habe mich nicht klar genug ausgedrückt. Ich meine natürlich nicht unbedingt, daß gleich das ganze System übernommen wird, aber es genügt ja schon ein Autostartobjekt in HKEY_CURRENT_USER zu installieren, das bei jeder Anmeldung des Benutzers gestartet wird.
Sowas kann ein Prozess natürlich nur, wenn er entsprechende Rechte hat...
Das kann jeder Prozess, den der Benutzer gestartet hat. Sei es wissentlich oder aus Dummheit.
dot schrieb:
mgaeckler schrieb:
Gerade letzteres scheint ja wohl mit der DLL-Injection nicht besonders schwierig zu sein.
Ja, so ist das halt; ist ja nicht so, dass Code Injection unter anderen Betriebssystem, wie z.B. Linux, irgendwie weniger einfach wäre...
Aha, gibt es sowas in Linux auch? Ich merke schon, daß es eine gute Idee war, meinen Mailserver und meinen Proxyserver so zu konfigurieren, daß sie keine EXEs durchlassen. Die werden kommentarlos weggeworfen (/dev/null).
mfg Martin
-
mgaeckler schrieb:
Das kann jeder Prozess, den der Benutzer gestartet hat. Sei es wissentlich oder aus Dummheit.
Ähm, das ist aber ein prinzipielles Problem. Jeder Prozess, den der Benutzer mit gewissen Rechten startet, sei es wissentlich oder aus Dummheit, kann unter jedem mit bekannten Betriebssystem die ihm verliehenen Rechte missbrauchen, um entsprechenden Schaden anzurichten!? Was genau kann da jetzt das OS dafür!?
-
dot schrieb:
mgaeckler schrieb:
hustbaer schrieb:
Ey, nochmal: du übersiehst hier dass man das nicht in allen Fällen machen kann.
Das geht z.B. wenn ich ein Programm A starte, und ein Programm B in der selben Session starte, beide unter meinem Account laufen lasse, dann können die sich gegenseitim im Speicher rumpfuschen.Das finde ich schlimm genug, sonst hätte ich geschrieben, daß da 100 Zeppeline nebeineinander durchpassen.
Was empfielst du denn als sichere Alternative?
So ähnlich wie ich das vorhin beschrieben habe:
Das System entscheidet ausschließlich an Hand eines Eintrags unter HKEY_LOCAL_MACHINE, das ja nur der Admin ändern darf, welche DLLs sich in welche Anwendung(en) einklinken dürfen. Sobald ein (Installations)programm versucht, so einen Schlüssel zu verändern, wird der Admin gefragt, ob er dieses zulassen will.
Für diejenigen Admins, die einen ganzen Rechnerpark einrichten müssen, könnte natürlich auch eine Policy eingeführt werden, so daß der arme Admin dies nicht für jeden Rechner einzeln bestätigen muß.Auf diese Art kann sich ein DAU nicht so leicht eine Schadsoftware einfangen, die diese Wege der Spionage nutzen will.
Wenn der DAU natürlich ein SuperDAU ist und immer mit Adminrechten am Rechner sitzt, dann ist, wie ich schon schrieb, sowieso alles zu spät.
mfg Martin
-
dot schrieb:
mgaeckler schrieb:
Das kann jeder Prozess, den der Benutzer gestartet hat. Sei es wissentlich oder aus Dummheit.
Ähm, das ist aber ein prinzipielles Problem. Jeder Prozess, den der Benutzer mit gewissen Rechten startet, sei es wissentlich oder aus Dummheit, kann unter jedem mit bekannten Betriebssystem die ihm verliehenen Rechte missbrauchen, um entsprechenden Schaden anzurichten!? Was genau kann da jetzt das OS dafür!?
Das OS kann was dafür, weil es nicht mehr Kontrollmöglichkeiten zur Verfügung stellt. Ein Beispiel:
Es wäre doch z.B. recht praktisch, wenn ich im System festlegen könnte, die Datei darf zwar von den Benutzern x, y und z bearbeitet werden aber nur mit dem Programm p. Mit *Nixen könnte man sowas ähnliches realisieren, da es dort das setuid-bit gibt. Aber das bereitet auch leider immer wieder Probleme und ist auch nicht so recht das gelbe vom Ei vor allen Dingen, weil diese Prozesse dann häufig gleich mit Superuserrechten laufen. Außerdem ist es nicht genau das was ich meine.
mfg Martin
-
mgaeckler schrieb:
Es wäre doch z.B. recht praktisch, wenn ich im System festlegen könnte, die Datei darf zwar von den Benutzern x, y und z bearbeitet werden aber nur mit dem Programm p.
Und was genau hindert dich unter Windows nun daran, das festzulegen?
-
dot schrieb:
mgaeckler schrieb:
Es wäre doch z.B. recht praktisch, wenn ich im System festlegen könnte, die Datei darf zwar von den Benutzern x, y und z bearbeitet werden aber nur mit dem Programm p.
Und was genau hindert dich unter Windows nun daran, das festzulegen?
Das Wissen um so eine Option hindert mich daran. Wo soll denn so eine Option sein? Ich kenne sowas nicht.
mfg Martin
-
Einfachste Lösung, die mir spontan einfällt: Du machst einen User a, der entsprechende Rechte im entsprechenden Ordner hat und gibst den Usern x, y und z das Recht, das jeweilige Programm als User a auszuführen...
-
dot schrieb:
Einfachste Lösung, die mir spontan einfällt: Du machst einen User a, der entsprechende Rechte im entsprechenden Ordner hat und gibst den Usern x, y und z das Recht, das jeweilige Programm als User a auszuführen...
Das könnte vieleicht eine Lösung sein. Aber ist es dann nicht so, daß die Anwender x, y und z jedesmal, wenn sie die Anwendung starten, das Kennwort von a eingeben müssen. Wie sieht es dann mit Netzlaufwerken aus? Kann das Programm dann auch auf die Netzlaufwerke der Benutzer zugreifen?
Solche Lösungen könnten zwar besonders kritische Probleme lösen, für einen allgemeinen Gebrauch erscheinen sie mir aber zu umständlich und werden daher für gewöhnlich von den Anwendern nicht angenommen.
mfg Martin
-
Wie sieht es dann mit Netzlaufwerken aus? Kann das Programm dann auch auf die Netzlaufwerke der Benutzer zugreifen?
Je nachdem welche Rechte du User a gegeben hast. Wenn das Programm als User a läuft sollte es eigentlich keine Kontrolle über z.b. die Daten von Benutzer x haben (korrigiert mich wenn ich mich irre). Und Passwort musst du ja keins festlegen für User a.
Solche Lösungen könnten zwar besonders kritische Probleme lösen, für einen allgemeinen Gebrauch erscheinen sie mir aber zu umständlich und werden daher für gewöhnlich von den Anwendern nicht angenommen
Für normale User reicht es ja auch nicht immer als Admin unterwegs zu sein, diese Lösung ist eher für Systeme mit mehreren Benutzern die unterschiedliche Rechte haben. Und ja, sowas zu konfigurieren ist immer etwas Aufwand, aber den hat man immer, oder hast du einen Vorschlag wie es besser gehen würde ?
-
Ideal wäre wenn jede Anwendung in einer Sandbox laufen würde und Löcher in die Sandbox nur durch Zustimmung des Nutzers geschlagen werden dürften (zum Beispiel für IPC oder Zugriff auf Teile des Dateisystems)
...aber ich befürchte dann hat man mehr mit den Berechtigungen zu tun als man tatsächlich produktiv arbeiten kann
-
DarkShadow44 schrieb:
Wie sieht es dann mit Netzlaufwerken aus? Kann das Programm dann auch auf die Netzlaufwerke der Benutzer zugreifen?
Je nachdem welche Rechte du User a gegeben hast. Wenn das Programm als User a läuft sollte es eigentlich keine Kontrolle über z.b. die Daten von Benutzer x haben (korrigiert mich wenn ich mich irre).
So sollte es sein und so ist es auch. Sonst wäre Kleinweich völlig verblödet.
DarkShadow44 schrieb:
Und Passwort musst du ja keins festlegen für User a.
Wo ist dann der Schutz? Wäre es dann auch nicht für ein Schadprogramm ein leichtes da einzudringen?
DarkShadow44 schrieb:
Und ja, sowas zu konfigurieren ist immer etwas Aufwand, aber den hat man immer, oder hast du einen Vorschlag wie es besser gehen würde ?
Da sind wir jetzt an einen Punkt, der zeigt, daß es sich hier um kein triviales Problem handelt. Bei den Kleinweichlösungen kommt es mir aber so vor, daß sie häufig die Symptome eines Fehlers beseitigen ohne den Fehler selbst zu beheben. Der Hauptgrund dürfte dabei wahrscheinlich sein, daß sie mit aller Gewalt an Konzepten festhalten, die zur Homecomputerzeit noch akzeptabel waren, aber heute eigentlich nicht mehr tragbar sind.
Eine Lösung für sowas zu finden, ist allerdings natürlich auch nicht einfach. Ein sicheres System muß nämlich
- Vom Konzept her so einfach sein, daß der Betriebsystementwickler bzw. -progammierer wenig bis gar keine Fehler machen kann.
- Der Anwendungsentwickler sollte sich ebenfalls wenig bis gar keine Gedanken darüber machen müssen.
- Für den Administrator, darf das ganze auch nicht zu umständlich sein (erst recht bei einem privat PC, der nicht von einem Fachmann gewartet wird)
- Und zu guter letzt, der Anwender selbst sollte nicht zu viel behindert werden.
Eine sehr schwere Aufgabe. Ich mache mir darüber schon seit vielen Jahren Gedanken und ich bin zu den Schluß gekommen, daß die OS Hersteller auf jeden Fall alte Zöpfe mal abschneiden müssen und sich mal wirklich darauf konzentrieren müssen, endlich mal sichere Systeme zu konzipieren.
mfg Martin
-
mgaeckler schrieb:
Eine Lösung für sowas zu finden, ist allerdings natürlich auch nicht einfach. Ein sicheres System muß nämlich
- Vom Konzept her so einfach sein, daß der Betriebsystementwickler bzw. -progammierer wenig bis gar keine Fehler machen kann.
- Der Anwendungsentwickler sollte sich ebenfalls wenig bis gar keine Gedanken darüber machen müssen.
- Für den Administrator, darf das ganze auch nicht zu umständlich sein (erst recht bei einem privat PC, der nicht von einem Fachmann gewartet wird)
- Und zu guter letzt, der Anwender selbst sollte nicht zu viel behindert werden.
Eine sehr schwere Aufgabe. Ich mache mir darüber schon seit vielen Jahren Gedanken und ich bin zu den Schluß gekommen, daß die OS Hersteller auf jeden Fall alte Zöpfe mal abschneiden müssen und sich mal wirklich darauf konzentrieren müssen, endlich mal sichere Systeme zu konzipieren.
Tja, der Anwender muss Administrator-Rechte haben, sonst laufen manche Spiele nicht.
-
volkard schrieb:
Tja, der Anwender muss Administrator-Rechte haben, sonst laufen manche Spiele nicht.
Ja das war leider nach der Einführung von Windows NT ein großes Problem. Viele Anwendungen, die nach NT portiert worden sind, gingen immer noch davon aus, daß der Benutzer Adminrechte hat. Auch sind viele Anwendungen davon ausgegangen, daß derjenige, der die Anwendung installiert hat, auch derjenige ist, der sie benutzt. Da werden dann wichtige Einstellungen unter HKEY_CURRENT_USER gespeichert und später nicht mehr gefunden. Das ist dann allerdings ein Problem, das man MS wirklich nicht anlasten kann.
mfg Martin
-
volkard schrieb:
Tja, der Anwender muss Administrator-Rechte haben, sonst laufen manche Spiele nicht.
Das finde ich zu unpräzise. Die Spiele brauchen keine Administratorrechte, sie wollen gar keine Windows-Domäne konfigurieren. Sie wollen einfach nur auf ihren Installationsordner zugreifen, was meiner Meinung nach keine überzogene Forderung darstellt. Es sollte die Möglichkeit geben zu sagen, dass das Spiel auf seinen Installationsordner und auf seine Registry-Keys zugreifen kann, aber nicht auf andere Installationsordner (Expansions mal ausgenommen) und nicht auf die Keys anderer Programme und Nutzerpasswörter ändern schon gar nicht.
mgaeckler schrieb:
Wenn der DAU natürlich ein SuperDAU ist und immer mit Adminrechten am Rechner sitzt, dann ist, wie ich schon schrieb, sowieso alles zu spät.
Da gehe ich auch nicht mit. Auch als Administrator muss ich die Möglichkeit haben geilemuschies.jpg.exe so auszuführen, dass es nichts kompromittieren kann. Ich bin generell dagegen, dass ich als einzelner Nutzer schizophren sein muss und mal Admin und mal Nutzer und mal eingeschränkterer Nutzer sein muss. Völlig falsche Denkweise. Ich bin immer Administrator. Nur dürfen die Programme, die ich ausführe, nicht mit Adminrechten gestartet werden. Also braucht man Programmrechte, die ungleich der Nutzerrechte sind. Damit lösen sich alle Probleme. Ich werde nie begreifen warum das nicht Standard ist bzw. noch nie versucht wurde.
-
nwp3 schrieb:
Also braucht man Programmrechte, die ungleich der Nutzerrechte sind. Damit lösen sich alle Probleme. Ich werde nie begreifen warum das nicht Standard ist bzw. noch nie versucht wurde.
Ist doch Standard auf jedem modernen OS!? Nur sind die Defaulteinstellungen halt nirgendwo so extrem wie du es gerne hättest, weil das Ding dann kein Mensch mehr würde benutzen wollen...
-
nwp3 schrieb:
volkard schrieb:
Tja, der Anwender muss Administrator-Rechte haben, sonst laufen manche Spiele nicht.
Das finde ich zu unpräzise. Die Spiele brauchen keine Administratorrechte, sie wollen gar keine Windows-Domäne konfigurieren. Sie wollen einfach nur auf ihren Installationsordner zugreifen, was meiner Meinung nach keine überzogene Forderung darstellt. Es sollte die Möglichkeit geben zu sagen, dass das Spiel auf seinen Installationsordner und auf seine Registry-Keys zugreifen kann, aber nicht auf andere Installationsordner (Expansions mal ausgenommen) und nicht auf die Keys anderer Programme und Nutzerpasswörter ändern schon gar nicht.
Genau, sowas wäre z.B. ganz praktisch. Dann könnte man sagen der Installationsordner XYZ der Anwendung XYZ darf auch nur von der Anwendung geändert werden. Der Eigentümer einer Datei/eines Ordner kann nicht nur festlegen welche Benutzer/Gruppen was damit machen dürfen sondern auch mit welchen Anwendungen. Eine Anwendung könnte dann schon beim Installieren festlegen, ich brauche Schreibrechte auf diese oder jene Unterverzeichnisse.
nwp3 schrieb:
mgaeckler schrieb:
Wenn der DAU natürlich ein SuperDAU ist und immer mit Adminrechten am Rechner sitzt, dann ist, wie ich schon schrieb, sowieso alles zu spät.
Da gehe ich auch nicht mit. Auch als Administrator muss ich die Möglichkeit haben geilemuschies.jpg.exe so auszuführen, dass es nichts kompromittieren kann. Ich bin generell dagegen, dass ich als einzelner Nutzer schizophren sein muss und mal Admin und mal Nutzer und mal eingeschränkterer Nutzer sein muss. Völlig falsche Denkweise. Ich bin immer Administrator. Nur dürfen die Programme, die ich ausführe, nicht mit Adminrechten gestartet werden. Also braucht man Programmrechte, die ungleich der Nutzerrechte sind. Damit lösen sich alle Probleme. Ich werde nie begreifen warum das nicht Standard ist bzw. noch nie versucht wurde.
Das wäre sicherlich wünschenswert. Nixen kennen dazu ja z.B. den Systermaufruf chroot, damit Programme, die vom Admin gestartet werden, nicht gleich das ganze System übernehmen können.
mfg Martin
