Mozilla - Vote for this bug!

[Bio]

Sup!

Da gibt's einen Bug, der wäre es wert, eine Stimme zu bekommen, denn diese Verbesserung würde Mozilla zu einem wirklich verdammt sicheren Browser machen:

http://bugzilla.mozilla.org/show_bug.cgi?id=153950

Gruesse,

Bio

[Kube]

Hallo Bio,

für die Englischnichtversteher unter uns hier die Übersetzung des Änderungsvorschlags (übersetzt von Lycos):

<schnipp>
Es würde wundervoll sein, wenn Durchführung des Misten auf dem Netz
oder den Zubehören in einem chroot (oder im Gefängnis, für y'all Bd
Völker) erfolgt war, für Sicherheit. Einen Prozeß als ' niemand '
laichend, würde Benutzer für Sicherheit außerdem sehr vorteilhaft
sein. Für die Millionen der Leute, die sich nicht für Sicherheit
interessieren, denke ich, daß diese Bestimmungen in der Bewahrung
ihrer Perioden des Maschine Vollständigkeit Überschusses lang des
Netzes surfend und der zahlreichen böswilligen email Zubehöre sehr
nützlich sind. Insbesondere denn allgemeine Zugang Maschinen und
eingebettete dünne Klienten, diese ist eine sehr große Prämie für
die Unixy Leute.
</schnapp>

Also ich bin mir nicht sicher, ob ich alles verstanden habe. Bin natürlich dafür :-)

Gruß,
Kube

[Henryk Plötz]

Moin,

Da gibt's einen Bug, der wäre es wert, eine Stimme zu bekommen, denn diese Verbesserung würde Mozilla zu einem wirklich verdammt sicheren Browser machen:

Man erkläre es mir, aber was soll das eigentlich werden? Man führt keine Software direkt aus dem Browser aus. Und wenn man es doch tut, dann hat man gute Gründe dafür und ein chroot wäre da eher unangebracht (jetzt mal davon abgesehen, dass man tendentiell eine Gesamtkopie von /usr/lib in dem chroot bräuchte).

Das ganze mit einem anderen User zu tun, hmm, ja, von mir aus. Wenn das aber alle unter dem gleichen anderen User tun (Linux ist nunmal kein reines Single-User-System) wäre das wieder ein privilegierter User auf seine Art. (Ähnlich wie diese doofe Idee alle möglichen Server als 'nobody' zu betreiben wodurch nobody plötzlich ziemlich mächtig war.)

Unbeirrt davon: Das Programm hätte doch dann ganz sicher Zugriff auf den X-Server womit jegliche 'Sicherheit' erstmal dahin ist. Denn selbst wenn das Programm kein rm -rf ~ machen können sollte, könnte es immernoch dem Fenstermanager/Desktop Environment sagen es solle ein xterm öffnen und dann diesen Befehl gefolgt von einem Enter in das xterm eingeben. (Ja, ich weiss dass es Sicherheits-Erweiterungen für X dagegen gibt. Aber verbreitet sind die soweit ich sehen kann nicht. Und ohne die ist das ganze vollkommen witzlos.)

[Bio]

Sup!

Man erkläre es mir, aber was soll das eigentlich werden? Man führt keine Software direkt aus dem Browser aus. Und wenn man es doch tut, dann hat man gute Gründe dafür und ein chroot wäre da eher unangebracht (jetzt mal davon abgesehen, dass man tendentiell eine Gesamtkopie von /usr/lib in dem chroot bräuchte).

Tja, Du Schlauberger, es geht ja auch um Sicherheit für den Fall, das jemand einen Buffer-Overflow im Browser entdeckt und plötzlich beliebigen Code ausführen kann.

Das ganze mit einem anderen User zu tun, hmm, ja, von mir aus. Wenn das aber alle unter dem gleichen anderen User tun (Linux ist nunmal kein reines Single-User-System) wäre das wieder ein privilegierter User auf seine Art. (Ähnlich wie diese doofe Idee alle möglichen Server als 'nobody' zu betreiben wodurch nobody plötzlich ziemlich mächtig war.)

Nicht, wenn man das Programm in viele Teile aufspaltet, die miteinander kommunizieren und sich dabei gegenseitig auf die Finger schauen, und wo jedes Teilprogramm nur die Rechte hat, die es braucht, und die Teilprogramme, die tendenziell gehackt werden könnten (die, die aus dem Netz geholte Inhalte verarbeiten), die wenigsten Rechte haben.

Unbeirrt davon: Das Programm hätte doch dann ganz sicher Zugriff auf den X-Server womit jegliche 'Sicherheit' erstmal dahin ist.

Ach ja? Warum?

Denn selbst wenn das Programm kein rm -rf ~ machen können sollte, könnte es immernoch dem Fenstermanager/Desktop Environment sagen es solle ein xterm öffnen und dann diesen Befehl gefolgt von einem Enter in das xterm eingeben.

Dadurch hat das Programm aber keine erweiterten Rechte, und auch wenn es möglich sein sollte, dass der X-Server einem chroot-Programm eine Shell gibt, die dann ausserhalb des chroots ist, so ist es doch wesentlich schwieriger, in einem exploit den code für das öffnen einer shell über den X-Server einzubauen als nur einen normalen shellcode, denke ich.

(Ja, ich weiss dass es Sicherheits-Erweiterungen für X dagegen gibt. Aber verbreitet sind die soweit ich sehen kann nicht. Und ohne die ist das ganze vollkommen witzlos.)

Geht so. Man kann ja den X-Ausgabe-Teil auch noch abspalten von der Rendering-Engine, so dass die Rendering-Engine nur noch die fertigen Bildchen an den X-Ausgabe-Teil schickt, der dadurch wahrscheinlich ziemlich schwer zu hacken wird.

Gruesse,

Bio

[Henryk Plötz]

Moin,

Tja, Du Schlauberger, es geht ja auch um Sicherheit für den Fall, das jemand einen Buffer-Overflow im Browser entdeckt und plötzlich beliebigen Code ausführen kann.

Gut, so wie es aussieht haben wir verschiedene Bug-Reports gelesen. In dem den ich gelesen habe ging es darum heruntergeladene Programme und Attachments wenn man sie schon ausführt, in einem chroot auszuführen, weil die 'eventuell' (muahaha) gefährlich sein könnten. Vom Browser steht da weit und breit nichts (d.h. doch: in deinem Kommentar).

Unbeirrt davon: Das Programm hätte doch dann ganz sicher Zugriff auf den X-Server womit jegliche 'Sicherheit' erstmal dahin ist.

Ach ja? Warum?

Naja, Programme die aus dem Browser ausgeführt werden haben üblicherweise kein xterm drumherum. Und wenn sie dann nicht mit dem X-Server reden um ihre Ausgaben anzuzeigen ist das ganze etwas witzlos.

Dadurch hat das Programm aber keine erweiterten Rechte, und auch wenn es möglich sein sollte, dass der X-Server einem chroot-Programm eine Shell gibt, die dann ausserhalb des chroots ist, so ist es doch wesentlich schwieriger, in einem exploit den code für das öffnen einer shell über den X-Server einzubauen als nur einen normalen shellcode, denke ich.

Der 'exploit code' besteht in diesem Fall aus den Befehlen um die Tastendrücke für Strg-Alt-T (icewm) oder Alt+F2 (KDE) oder ähnlich über den X-Server an den Fenstermanager oder das Desktopenvironment zu schicken. Nicht grade rocket science.

[Bio]

Sup!

Naja, Programme die aus dem Browser ausgeführt werden haben üblicherweise kein xterm drumherum. Und wenn sie dann nicht mit dem X-Server reden um ihre Ausgaben anzuzeigen ist das ganze etwas witzlos.

Ich denke, Programme, die aus dem Browser ausgeführt werden, wie Applets oder Plugins, machen ihre Ausgaben über eine Plugin-Schnittstelle und nicht direkt via X-Server.

Der 'exploit code' besteht in diesem Fall aus den Befehlen um die Tastendrücke für Strg-Alt-T (icewm) oder Alt+F2 (KDE) oder ähnlich über den X-Server an den Fenstermanager oder das Desktopenvironment zu schicken. Nicht grade rocket science.

Tastendrücke an das System zu schicken, die wie vom User kommend aussehen, sollte für ein Programm, dass nicht unter der Kennung des Users läuft, gar nicht möglich sein.

Bio

[Henryk Plötz]

Moin,

Ich denke, Programme, die aus dem Browser ausgeführt werden, wie Applets oder Plugins, machen ihre Ausgaben über eine Plugin-Schnittstelle und nicht direkt via X-Server.

Wie gesagt, in dem Bug den ich glaube gelesen zu haben ging es um sowas wie die Unix-Versionen von "$COWORKER schickt dir lustigeanimation.exe per mail" oder "Du lädst coolesprogramm.exe von einer Webseite herunter" wobei du jedes mal deinen Klickfinger nicht unter Kontrolle behalten kannst und die Programme direkt aus dem Browser ausführst.

Tastendrücke an das System zu schicken, die wie vom User kommend aussehen, sollte für ein Programm, dass nicht unter der Kennung des Users läuft, gar nicht möglich sein.

Ein handelsüblicher X-Server weiss gar nichts von Usern. Wenn ein Client eine authorisierte Verbindung zum X-Server hat, dann darf er auch dessen Dienste in Anspruch nehmen.

[Bio]

Sup!

Wie gesagt, in dem Bug den ich glaube gelesen zu haben ging es um sowas wie die Unix-Versionen von "$COWORKER schickt dir lustigeanimation.exe per mail" oder "Du lädst coolesprogramm.exe von einer Webseite herunter" wobei du jedes mal deinen Klickfinger nicht unter Kontrolle behalten kannst und die Programme direkt aus dem Browser ausführst.

Tja, stimmt, da sollte ich ggf. einen neuen Bug aufmachen und den Kommentar zurücknehmen ;-)

Tastendrücke an das System zu schicken, die wie vom User kommend aussehen, sollte für ein Programm, dass nicht unter der Kennung des Users läuft, gar nicht möglich sein.

Ein handelsüblicher X-Server weiss gar nichts von Usern. Wenn ein Client eine authorisierte Verbindung zum X-Server hat, dann darf er auch dessen Dienste in Anspruch nehmen.

Und welche Dienste mit zusätzlichen Rechten stellt ein XServer einem Programm/Client zur Verfügung, die das nicht auch gleich von der LibC bekommen könnte?

Gruesse,

Bio

[Henryk Plötz]

Moin,

Und welche Dienste mit zusätzlichen Rechten stellt ein XServer einem Programm/Client zur Verfügung, die das nicht auch gleich von der LibC bekommen könnte?

Ist das eine Trickfrage? Jedes Programm dass über eine Verbindung zum X-Server verfügt darf in der Regel unter anderem an beliebige Stelle auf dem Bildschirm malen, den Bildschirminhalt ansehen, Tastatur- und Mausevents abfangen und künstliche Tastatur-/Mausevents senden. Unabhängig davon unter welchem User, in welchem chroot, auf welchem Host es läuft.

Jetzt mal abgesehen davon dass das alles mit der libc nicht geht, steht da in riesigen, blinkenden Lettern "PRIVILEGE ELEVATION" drüber. Wenn das Programm weniger Rechte als der User hat dem der X-Server gehört kann es idR eins-fix-drei ein anderes Programm davon überzeugen das zu tun was es will (über synthetische Tastaturevents). Selbst wenn es unter dem User läuft dem der X-Server gehört kann es immernoch eingetippte Passwörter[1] abhören, und mit etwas Glück ist da das root-Passwort bei. Von DoS (wir schließen einfach mal jedes Fenster das aufgeht) ganz zu schweigen.

[1] Dagegen gibt es eine Möglichkeit (in xterm etwa über Strg-Linke Maustaste, dann 'Secure Keyboard') die aber nur spärlich genutzt wird.

[Axel Richter]

Hallo,

Man erkläre es mir, aber was soll das eigentlich werden?

Das ist das Ergebnis folgender Herangehensweise an das Thema Sicherheit:
"Wir machen es _nicht_ so, wie alle, die Sicherheit dadurch erreichen wollen, dass sie dem Nutzer bestimmte sicherheitsrelevante Aktionen verwehren. Das ist Gängelung des Nutzers. Wir machen es im Gegenteil so, dass der Nutzer machen kann was er will, ohne dass er etwas kaputt machen kann."

Das hört sich sehr gut an, bis jemand feststellt:
"Moment mal, wenn ich alles machen kann, was nichts kaputt macht, kann ich doch wieder nicht alles machen. Eben das, was etwas kaputt machen könnte, kann ich ja eben _nicht_ machen."

Der Preis dieser Erkenntnis steigt mit der Zeit, welche bereits in die Entwicklung dieser _völlig neuen_ Sicherheitsstrategie investiert wurde.

viele Grüße ;-))

Axel