Ist das ganze Message System nicht ein riesen Security Loch?
-
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.
-
MFK schrieb:
mgaeckler schrieb:
Kannst Du mir ein sinnvolles Beispiel für eine Problemlösung nennen, die diesen Schmarrn rechtfertigt?
Eingabehilfen für Behinderte.
OK, seh ich ein, das könnte das rechtfertigen.
Was mich jetzt interessieren würde: diese DLL-Injection, kann die eigentlich jeder einrichten oder ist dafür ein Adminaccount erforderlich? Will heissen, ist der RegistryKey nur unterhalb HKEY_LOCAL_MACHINE oder sucht Windows (auch) in HKEY_CURRENT_USER.
Wenn er nämlich nur in HKEY_LOCAL_MACHINE gesucht wird, ist die Installation einer solchen Anwendung nur mit Adminrechten möglich. Man kann sich also ein Schadprogramm nicht so leicht einfangen (diejenigen, die mit Adminaccounts ins Internet gehen, denen kann man eh nicht mehr helfen).
Dann wäre diese Feature durch Dein Beispiel in meinen Augen durchaus akzeptabel. Was aber wiederum bedeuted, daß das ursprüngliche hier diskutierte Problem immer noch vorhanden ist und durch die Angabe einer Absenderadresse (wohl gemerkt durch das System nicht dem Absender) behoben hätte werden können.
mfg Martin
-
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!?
