Ist das ganze Message System nicht ein riesen Security Loch?
-
MFK schrieb:
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.
Mein Browser ist so konfiguriert, daß er zwar allen Webseiten erlaubt, Cookies zu setzen, er verwirft diese aber sofort beim Beenden des Browsers. Nur wenigen Websites habe ich erlaubt, Cookies dauerhaft zu speichern.
Grundsätzlich fände ich eine Idee ähnlich wie es bei Android gemacht wird nicht schlecht. Eine Anwendung, die besondere Rechte braucht, schreibt dies in Ihrem Manifest und beim Installieren wird der Benutzer gefragt, ob er der Anwendung diese Rechte gewähren will.
So kann ich meinem GPS-Logger erlaupen, meine Position zu speichern. Wenn er aber auf die Idee käme mein Telefonbuch zu durchsuchen, darf er sich bei mir seine Papiere abholen. Um Dein wirklich schönes Beispiel aufzugreifen, bei der Installation der Eingabehilfe wird der Anwender gefragt, ob die Anwendung sich in andere Programme einklinken darf oder nicht.
Damit hätten wir die Möglichkeiten solche (ich benutze jetzt mal meine Worte) "Gimmicks" zu benutzen, ohne gleich alle Rechner kompromitierbar zu machen.
mfg Martin
-
@mgaeckler
DLL injection kann man ganz ohne Registry machen.
Hier sind drei Wege beschrieben die alle ohne Registry auskommen:
http://www.codeproject.com/Articles/4610/Three-Ways-to-Inject-Your-Code-into-Another-ProcesUnd soweit ich weiss reicht es dafür auch wenn der eigene Prozess in der selben Window-Station mit dem selben Account läuft wie der wo man sich rein-injecten will.
-
hustbaer schrieb:
@mgaeckler
DLL injection kann man ganz ohne Registry machen.
Hier sind drei Wege beschrieben die alle ohne Registry auskommen:
http://www.codeproject.com/Articles/4610/Three-Ways-to-Inject-Your-Code-into-Another-ProcesUnd soweit ich weiss reicht es dafür auch wenn der eigene Prozess in der selben Window-Station mit dem selben Account läuft wie der wo man sich rein-injecten will.
Ohje. Danke für diesen Artikel. Ich entwickele seit 25 Jahren Anwendungen für Windoof und habe mich noch nie mit diesem Thema auseinander gesetzt, habe aber auch noch nie sicherheitsrelevate Software machen müssen. Aber das sind ja keine Scheunentore, die Kleinweich da für die Schadprogrammierer geöffnet hat, da passen zwei Zeppeline (und ich meine jetzt nicht die Musiker von Led Zeppelin) nebeneinander durch.
Ich wußte zwar, daß es Hooks gibt (habe vor gut 20 Jahren mal einen Artikel darüber im Microsoft System Journal gelesen, habe mich aber nie näher damit beschäftigt, weil ich keinen Anwendungsfall dafür für mich gesehen habe. Damals war es auch nicht ganz so problematisch. Anwendungen hatten damals keinen eigenen Adressraum, einem Angreifer wäre es also eh leicht gefallen und die Wege in ein System einzudringen, waren auch nur begrenzt vorhanden. Ich frage mich aber, warum Kleinweich diese Funktionen nicht im Zuge des Umstiegs zu Windows NT nicht hat fallen gelassen oder zumindest eingeschränkt hat. Damit tretten sie ja alle Bemühungen seitens der CPU-Hersteller, Prozesse voneinander abzuschotten, mit Füssen oder haben die ernsthaft gedacht, die MMU wurde nur eingeführt, um Arbeitsspeicher auf der Festplatte simulieren zu können?
mfg Martin
-
-
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.
-
mgaeckler schrieb:
Damit tretten sie ja alle Bemühungen seitens der CPU-Hersteller, Prozesse voneinander abzuschotten, mit Füssen oder haben die ernsthaft gedacht, die MMU wurde nur eingeführt, um Arbeitsspeicher auf der Festplatte simulieren zu können?
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.Wenn du auf dem selben PC, z.B. per Remote Desktop, Programm C startest, und wir beide keine Admins sind, dann kann Programm C weder Programm A oder B stören, noch von denen gestört werden.
Und genau so wenig kannst du ohne Admin Rechte in Systemprogrammen (z.B. Diensten) rumpfuschen.
Probleme gibt es da nur, wo ein Prozess X der mit niedrigeren Privilegien unter nem Userkonto läuft von einem anderen Prozess/dem OS als "vertrauenswürdig" angesehen wird, und der abdere Prozess/das OS diesem Prozess X daher bestimmte Dinge erlaugen. Wenn sich ein böses Programm dann in Prozess X reinhackt, dann könnte es also über Umwege böse Dinge tun.
Also nix mit Scheunentoren. Drachen ja, aber keine Scheunentore
-
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
