Einschleusen von Schadcode in FF

Zitat von liracon

Noch ein Nachtrag:
die Rechte des Ordners, in dem MR TECH schreibt/liest sind für den Test definitiv auf Admin (vollzugriff), sonst nichts.

Dann hast du einen fatalen Bug in Windows gefunden.

>Das bedeutet: mal schnell vom Server-
>profil abmelden -> normales Userlogin
>einloggen, Job erledigen, Abmelden,
>wieder mit online-Rechten anmelden usw.

Was spricht dagegen nur die Programme
mit Adminrechten aufzurufen?

liracon erklärte Folgendes:

Zitat

[...]Auf das angegebene Netzwerklaufwerk kann diese Erweiterung (Mr. Tech) zugreifen. Ändere ich die Berechtigung dieses Speicherplatzes auf ADMIN only (keine Vererbung, keine weiteren Benutzerrechte), interessiert das MR TECH überhaupt nicht. Es wird unverändert alles aufgelistet (analog: über Browser installierte Addons in Verzeichnis zusätzlich speichern)[...]

Lesend oder Schreibend? Das sind zwei verschiedene Welten. Du sprachst Eingangs - wenn ich Dich hier richtig verstanden hatte - von FF-Erweiterungen, welche sich u.U. über das zugrundeliegende OS-System (Windows / Linux, etc.) Schreibberechtigungen für Unterordner aneignen könnten - und das ist definitiv - nach meinen bisherigen Kenntnissen - aus einer FF-Verfügung heraus, (selbst im Zuge von offenen Admin-Rechten auf so einem OS) nicht möglich. Die zugrundeliegende Programmiersprache solcher FF-Erweiterungen birgt - meiner Ansicht nach - nicht die Möglichkeit, kompromittierend auf OS-Routinen zugreifen zu können.

Du meintest dagegen vermutlich eher diverse FF-Erweiterungen aus unsicheren Quellen heraus, welche sich zwar als sicher ausgeben, jedoch u.U. - im Zuge einer Installation - eine gewisse "PayLoad" (undokumentierte Zusätze) an Malware in das zugrundeliegende OS - mit den entsprechenden Konsequenzen - einspeisen könnten. Das wäre jedoch ein anderes Thema...

liracon erklärte darüberhinaus:

Zitat

Somit schliesse ich daraus, dass Firefox nicht mit den eigentlich gewollten Benutzerrechten, sondern mit denen, des angemeldeten Users arbeitet. Dieser Rechtestatus wird dann von FF an die in seinem Environment ablaufenden Prozesse vererbt/delegiert.

Das ist absolut nichts Neues. Noch einmal - die Rechteverfügungen (also Personen und Prozesse auf Deinem System) - "erschaffst" Du nur über den System-Kontext der einzeldefinierbaren Anwendungen innerhalb des OS selber, zu welchen u.A. auch der FF (incl. seiner Erweiterungen) gehört.

"Platt ausgedrückt": Am System kommt definitiv keine Anwendung "unvorbehalten" vorbei...

Oliver

http://msdn.microsoft.com/de-de/library/cc464517(VS.71).aspx
http://msdn.microsoft.com/de-de/library/cc464506(VS.71).aspx

Zitat von Boersenfeger

.... ohne Admin-Rechte zu surfen, oder?

Nur zur Klarstellung, hier wird ohne Adminrechte gesurft!
Bei Installationen etc. gehts dann ja mit "Ausführen als".

Zitat von Oliver222

Die zugrundeliegende Programmiersprache solcher FF-Erweiterungen birgt - meiner Ansicht nach - nicht die Möglichkeit, kompromittierend auf OS-Routinen zugreifen zu können.

Erstmal nicht dass stimmt. Man kann aber eine Erweiterung (teilweise) in C(++) schreiben, in welches man auch Assembler einbinden könnte.
C bzw. Assembler würden, entsprechende Lücken im Betriebssystem vorrausgesetzt, sich durchaus dazu eignen.
Das führt allerdings dazu dass die Erweiterung stark von dem/der Betriebssystem/Architektur abhängig ist.

Ich schließe mich der ersten und ausführlichen Antwort von PIGSgrame an. Ein paar Worte würde ich aber gerne beitragen:

Zitat von liracon

Situation:
ein Schädling gelangt auf mein System. Dieser tauscht eine in FF vorhandene Erweiterung gegen eine mit irgendwelchen Schadcode versehene Erweiterung aus.

Wenn ein Angreifer es schafft ein Schadprogramm auf deinem Computer auszuführen ist es ganz einfach zu spät.
Wie zu einem anderen Thema hier im Firefox-Forum (Passwörter doch nicht sicher?) verlinke ich gerne wieder die
10 Immutable Laws of Security
Daraus das erste Gesetz:

Zitat

Law #1: If a bad guy can persuade you to run his program on your computer, it's not your computer anymore

D.h. falls ein Angreifer es schafft auf deinem Computer ein Programm auszuführen ist dein Computer nicht mehr sicher. Ob der Angreifer diese Möglichkeit nun nutzt um den Code von Firefox-Erweiterungen zu manipulieren oder deine Daten auf eine andere Weise ausspäht ist meines Erachtens unerheblich.
Die 10 Immutable Laws of Security sind auch nur eine von vielen Richtlinien und sie stammen sogar von Microsoft :P. Meiner Meinung nach sind sie aber sinnvoll formuliert und taugen tatsächlich als grundsätzliche Sicherheitsrichtlinien.

Ich denke einfach das es - abgesehen von einer Rechteverwaltung - wenig Sinn macht sich auf einem Computersystem vor "inneren" Bedrohungen zu schützen.
Und bei jeder Rechteverwaltung muss man auch wieder abwägen zwischen Sicherheit und Komfort.
Unter GNU/Linux ist es z.B. ganz normal, das man alle Anwendungen als eingeschränkter Nutzer ausführt und den Administrator-Account eben nur für administrative Aufgaben nutzt.
Dennoch habe ich als Benutzer natürlich Zugriff auf alle meine Daten. Und ein (Schad-)Programm das mit meinen Benutzerrechten ausgeführt wird hat diesen Zugriff natürlich auch.
D.h. auch eine Rechteverwaltung kann mich nur in den gesetzten Grenzen schützen. Vielleicht verhindert sie, daß mein komplettes System nicht kompromittiert wird - aber wenn dafür meine persönlichen Daten ausgelesen werden beruhigt mich das wenig.

Jetzt könnte man auf die Idee kommen kritische Anwendungen in einer Art Sandbox auszuführen - ohne Zugriff auf persönliche Daten und nur mit den nötigsten Rechten.
Allerdings gehören zu den kritischen Anwendungen eigentlich all die Programme welche zu irgendeinem Zeitpunkt externe Daten verarbeiten - und das tun so ziemlich alle Programme die ich nutze.
Und einem Email-Programm kann man schlecht den Zugriff auf persönliche Daten verweigern.

Im Endeffekt macht es am meisten Sinn die Anwendungsprogramme so zu schreiben das sie beim Verarbeiten externer Daten keinen Fehler machen. Allerdings sind viele (die meisten) Anwendungsfälle so komplex das man Fehler einfach nicht zu 100% ausschließen kann.

Es gibt aber Möglichkeiten - sowohl für Entwickler als auch für Benutzer - mit denen man die Risiken dieser Verarbeitungsfehler eingrenzen kann:

Für den Benutzer ist die einfachste Möglichkeit für mehr Sicherheitsgewinn die Komplexität einzugrenzen.
Beim Verarbeiten von HTML oder XML machen moderne Browser z.B. sicherheitstechnisch gesehen kaum mehr Fehler. Die meisten Browser-bezogenen Sicherheitslücken beziehen sich dagegen auf das Verarbeiten aktiver Inhalte - JavaScript, Flash, etc.
Deaktiviere ich diese Inhalte global und erlaube ich sie nur selektiv (Whitelisting statt Blacklisting!) habe ich schon mal einen deutlichen Sicherheitsgewinn - deswegen ist NoScript auch so empfehlenswert.

Besonders wichtig ist es natürlich auch alle Anwendungen - zumindest alle, die externe Daten verarbeiten - aktuell zu halten.
Das ist mit einem Paketmanagement wie es viele GNU/Linux-Distributionen bieten natürlich einfacher, als jede Anwendung einzeln zu aktualisieren.

Weiter ist es meist sicherer nicht alles automatisch ablaufen zu lassen. Das Firefox immer noch die gespeicherten Passwörter automatisch einträgt halte ich für ein unnötiges Sicherheitsrisiko (was einer der Gründe war, warum ich mit Secure Login angefangen hatte Firefox Erweiterungen zu entwickeln).
Die Nutzung des Firefox Password Managers an sich halte ich jedoch für sinnvoll (siehe Why using a Password Manager increases the security of your passwords).

Zitat von liracon

"FF unter Win = weitaus sicherer als IE, FF unter Linux = sicher".

Obwohl ich seit Jahren GNU/Linux nutze ist FF unter Linux meines Erachtens nicht sicherer als FF unter Windows. Und IE7 unter Windows Vista mit "Protected Mode" und der Nutzung des Zonen-Modells ist wohl auch nicht ganz schlecht, wobei ich mich damit allerdings nicht näher beschäftigt habe.
Vielleicht nutzen Windows-Firefox-Nutzer unsicherere Plugins und vielleicht lässt sich ein Windows-System durch eine Firefox-Lücke einfacher kompromittieren, aber ansonsten sehe ich dahingehend keinen Vorteil der GNU/Linux-Plattform.

Meistens sind es die Anwendungen und nicht das Betriebssystem selbst über die Schadsoftware überhaupt in das System gelangen kann.

Zitat von madblueimp

D.h. auch eine Rechteverwaltung kann mich nur in den gesetzten Grenzen schützen. Vielleicht verhindert sie, daß mein komplettes System nicht kompromittiert wird - aber wenn dafür meine persönlichen Daten ausgelesen werden beruhigt mich das wenig.

Leg einen zweiten Benutzer Internet an und starte über diesen deine Internetprogramme.

Zitat

Jetzt könnte man auf die Idee kommen kritische Anwendungen in einer Art Sandbox auszuführen - ohne Zugriff auf persönliche Daten und nur mit den nötigsten Rechten.

Siehe oben lässt sich umgehen.

Zitat

Allerdings gehören zu den kritischen Anwendungen eigentlich all die Programme welche zu irgendeinem Zeitpunkt externe Daten verarbeiten - und das tun so ziemlich alle Programme die ich nutze.
Und einem Email-Programm kann man schlecht den Zugriff auf persönliche Daten verweigern.

Wieso? Was glaubst du was AppArmor, SELinux usw. alle tun?

Zitat

Im Endeffekt macht es am meisten Sinn die Anwendungsprogramme so zu schreiben das sie beim Verarbeiten externer Daten keinen Fehler machen.

Unmöglich.
Die Entwicklung des Menschen basiert auf Experimenten der Natur, bei der man "Fehler" absterben lässt.

Zitat

Die meisten Browser-bezogenen Sicherheitslücken beziehen sich dagegen auf das Verarbeiten aktiver Inhalte - JavaScript, Flash, etc.
Deaktiviere ich diese Inhalte global und erlaube ich sie nur selektiv (Blacklisting!) habe ich schon mal einen deutlichen Sicherheitsgewinn - deswegen ist.

Aufwand und (mögliches) Ergebniss stehen in keinem Zusammenhang auch die potentielle Gefahr die nur durch SIcherheitslücken in JS Interpreter, Flash Player, JRe etc. gegeben ist halte ich für zu gering als dass dies sinnvoll ist.

Zitat

Obwohl ich seit Jahren GNU/Linux nutze ist FF unter Linux meines Erachtens nicht sicherer als FF unter Windows.

Nur sind unixoide Systeme Windows deutlich weiter voraus wenn es darum geht, was darf eine Anwendung und wie verhindert man dass sie irgendwas tut was der Anwender so nicht geplant hat. Angefangen beim Rechtesystem und inzwischen bei Schutzmechanismen auf Kernel Ebene, wie die oben genannten AppArmor und SELinux. Dazu gibt es auf Windows übrigens keine Alternativen. Durchaus ein Grund wieso in sicherheitskritischen Bereichen kein Windows verwendet wird, jetzt mal abgesehen davon das Windows Closed Source ist.

Zitat

Meistens sind es die Anwendungen und nicht das Betriebssystem selbst über die Schadsoftware überhaupt in das System gelangen kann.

Wie definierst du Betriebssystem? Es ist schwer da eine klare Grenze zu ziehen von daher könnte man genauso gut sagen dass nur Anwendungen dafür verantwortlich sind.

Zitat von DasIch

Leg einen zweiten Benutzer Internet an und starte über diesen deine Internetprogramme.

Das passt zum Thema "Kompromiss zwischen Sicherheit und Komfort". Ich hab auf meinem System einen solchen Account (ohne Zugriff auf meine Daten), den ich lange Zeit exakt zu diesem Zweck verwendet habe. Damit habe ich z.B. manchmal Warcraft III (über Wine) gezockt. Mit Hilfe von sux oder einem eigenen Shell-Script lässt sich sowas auch relativ komfortabel realisieren. Aber dadurch gibt man (während der Ausführung) dem Account wiederum Rechte am eigenen X-Server-Display. Oder man nimmt den unkomfortablen Weg über die Benutzerumschaltung.
Solche Szenarien (extra, noch eingeschränkterer Account) schließe ich eigentlich unter dem Begriff "Sandbox" mit ein. Es geht um das gleiche Prinzip - Einschränken der Möglichkeiten für einen Sicherheitsgewinn, aber mit Abzügen im Komfort.
Und wie ich schon sagte - mit den meisten Anwendungen macht das einfach keinen Sinn - ein E-mail-Programm muss Zugriff auf meine E-mails haben - und die gehören nun mal zu meinen persönlichen Daten.

Zitat von madblueimp

Allerdings gehören zu den kritischen Anwendungen eigentlich all die Programme welche zu irgendeinem Zeitpunkt externe Daten verarbeiten - und das tun so ziemlich alle Programme die ich nutze.
Und einem Email-Programm kann man schlecht den Zugriff auf persönliche Daten verweigern.

Zitat von DasIch

Wieso? Was glaubst du was AppArmor, SELinux usw. alle tun?

AppArmor und SELinux beschränken vor allem Systemdienste. Sie gehen über die Zugriffsrechte von Benutzern und Gruppenzugehörigkeitein hinaus und definieren Regeln und Eigenschaften von Anwendungen - Policies (SELinux) und Profile (AppArmor) - um den Einsatzzweck einer Software genau festzulegen und die Rechte auf genau diesen Einsatzzweck zu beschränken. Der Hauptvorteil ist bisher der, das die Allmacht von root eingeschränkt wird. D.h. ein Systemdienst, der mit root-Rechten läuft und kompromittiert wird ist trotzdem so eingeschränkt das damit nicht das komplette System kompromittiert wird.
Theoretisch wären auch Profile für Benutzeranwendungen möglich, allerdings ist mir nicht bekannt das so etwas bisher umgesetzt wurde.
Und auch dann ist es nicht möglich einem E-mail-Programm die Rechte auf all meine persönlichen Daten zu entziehen - denn meine Emails gehören zu meinen persönlichen Daten.

Zitat von madblueimp

Im Endeffekt macht es am meisten Sinn die Anwendungsprogramme so zu schreiben das sie beim Verarbeiten externer Daten keinen Fehler machen.

Zitat von DasIch

Unmöglich.
Die Entwicklung des Menschen basiert auf Experimenten der Natur, bei der man "Fehler" absterben lässt.

Die Entwicklung des Menschen auf "Experimente der Natur" einzugrenzen wird der Komplexität des Themas meiner Meinung nach nicht gerecht. Und die Evolutionstheorie - ich nehme an du sprichst darauf an - hat eine etwas andere Definition.
Das geht aber jetzt schon Off Topic und eigentlich hättest du nur einen Satz weiterlesen müssen:

Zitat von madblueimp

Allerdings sind viele Anwendungsfälle so komplex das man Fehler einfach nicht zu 100% ausschließen kann.

Vielleicht hätte ich statt "viele" "fast alle" schreiben sollen - ich denke dann hättest du mir zugestimmt.

Zitat von DasIch

Aufwand und (mögliches) Ergebniss stehen in keinem Zusammenhang auch die potentielle Gefahr die nur durch SIcherheitslücken in JS Interpreter, Flash Player, JRe etc. gegeben ist halte ich für zu gering als dass dies sinnvoll ist.

Da bin ich komplett anderer Meinung. Der Browser hat sich neben E-mail zum Haupteinfallstor für Schädlinge entwickelt - und fast alle Attacken nutzen Exploits in Plugins (Flash, Video-Plugins, etc.), im Fall von MSIE auch ActiveX oder Lücken in der JavaScript-Engine aus. Ich weiß nicht ob du Sicherheitsnachrichten liest - aber die gängige Empfehlung zu Browsersicherheitslücken bis zur Auslieferung von Fixes lautet fast immer "Deaktivieren sie JavaScript", oder "Deaktivieren sie Plugin XY".
Und das Pflegen einer Whitelist mittels NoScript ist meiner Meinung nach ein geringer Komfortverlust im Vergleich zum Sicherheitsgewinn.

Zitat von DasIch

Nur sind unixoide Systeme Windows deutlich weiter voraus wenn es darum geht, was darf eine Anwendung und wie verhindert man dass sie irgendwas tut was der Anwender so nicht geplant hat. Angefangen beim Rechtesystem und inzwischen bei Schutzmechanismen auf Kernel Ebene, wie die oben genannten AppArmor und SELinux. Dazu gibt es auf Windows übrigens keine Alternativen. Durchaus ein Grund wieso in sicherheitskritischen Bereichen kein Windows verwendet wird, jetzt mal abgesehen davon das Windows Closed Source ist.

Zu AppArmor und SELInux siehe meine Antwort weiter oben. Diese Erweiterungen sind sicherlich sinnvoll, aber noch nicht bei Benutzeranwendungen angekommen. Sie schützen das System, aber nicht meine persönlichen Daten.
Versteh mich nicht falsch - ich behaupte nicht das Windows genauso sicher oder gar sicherer als eine GNU/Linux Distribution ist. Aber auch zwischen unixoiden Systemen gibt es Sicherheitsunterschiede. Mit OpenBSD ist man sicherheitstechnisch bestimmt ganz vorne dabei - aber ich habe noch nicht davon gehört das jemand OpenBSD auf dem Desktop nutzt.
Ubuntu dagegen hat GNU/Linux in punkte Benutzerfreundlichkeit ganz nach vorne gebracht. Allerdings ist der Hauptbenutzer automatisch Mitglied der Admin-Gruppe und kann sich mittels sudo und seinem eigenen Passwort root-Rechte verschaffen.
Schaffe ich es als Angreifer gegen ein Ubuntu-System ein Programm mit Nutzerrechten auszuführen kann ich einfach unter ~/bin/sudo ein eigenes Shell-Script anlegen. Das nächste mal wenn der Anwender sudo [irgendwas] im Terminal eingibt kann das Passwort ausgelesen werden.
Ich nutze selbst Ubuntu (siehe https://blueimp.net/linux/ ) und boote Windows eigentlich nur auf LAN-Parties um native Windows Spiele zu zocken. Zumindest Windows Vista ist aber sicherheitstechnisch nicht so schlecht wie sein Ruf. Und mit Firefox + NoScript ist man auf allen Systemen relativ sicher unterwegs.

Zitat von DasIch

Wie definierst du Betriebssystem? Es ist schwer da eine klare Grenze zu ziehen von daher könnte man genauso gut sagen dass nur Anwendungen dafür verantwortlich sind.

Ja, da hast du Recht.

Zitat von madblueimp

Schaffe ich es als Angreifer gegen ein Ubuntu-System ein Programm mit Nutzerrechten auszuführen kann ich einfach unter ~/bin/sudo ein eigenes Shell-Script anlegen. Das nächste mal wenn der Anwender sudo [irgendwas] im Terminal eingibt kann das Passwort ausgelesen werden.

Das ginge wäre ~/bin im PATH, ist es meines wissens aber nicht, der Ordner existiert per Default sowieso nicht.

Wirf mal einen Blick in ~/.profile - dort steht das folgende:

Zitat

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
PATH="$HOME/bin:$PATH"
fi

Der Ordner lässt sich ohne weiteres anlegen.
Und auch wenn der obige Code-Schnipsel nicht in ~/.profile vorhanden wäre, ließe er sich mit einem Programm mit Benutzerrechten einfach hinzufügen - dann muss man nur den nächsten Login zusätzlich abwarten.

Der Hinweis war aber auch nur ein Beispiel und hat für das eigentliche Thema keine große Relevanz. Ich wollte nur darauf hinweisen das auch GNU/Linux Systeme sicherheitstechnisch nicht immer optimal konfiguriert sind.

Bei mir existiert die Datei nicht

bash-3.2$ file ~/.profile
/home/dasich/.profile: cannot open `/home/dasich/.profile' (No such file or directory)

Na gut, kein Ubuntu sondern Arch...

Deswegen schrieb ich ja auch

Zitat von madblueimp

Schaffe ich es als Angreifer gegen ein Ubuntu-System...

Vielleicht lässt sich ein ähnliches Angriffsszenario unter Arch aber auch mittels ~/.bashrc (oder einem anderen Terminal-Profil) realisieren.

DasIch erklärte Folgendes:

Zitat

Erstmal nicht dass stimmt. Man kann aber eine (FF)-Erweiterung (teilweise) in C(++) schreiben, in welches man auch Assembler einbinden könnte. C bzw. Assembler würden, entsprechende Lücken im Betriebssystem vorausgesetzt, sich durchaus dazu eignen.

Was für ein (theoretischer) Unsinn. Wie tief möchtest Du denn noch greifen? Wir sprechen hier bloss von FF-Erweiterungen, welche somit auch nur im Kontext der FF-Prozess-Verschachtelungen (also der Verfügungen innerhalb so eines OS) - und zwar oberhalb der API ausgeführt werden dürfen. Alles andere käme sonst - meiner Ansicht nach - eher einem Rootkit als FF-Erweiterung gleich. Es ist darüberhinaus auch ziemlich egal, ob Linux oder Windows dabei eine vorteilhaftere Basis bildet. Das Prinzip wäre dennoch das Gleiche.
Bei Deinem hier dargelegten Assembler-Beispiel (in C) als FF-Erweiterung, müssten dann ja die sog. Opcodes (also die CPU-Maschinenbefehle / bzw. Zahlenwerte) mit Namen - und zwar den sogenannten Mnemonics (also komplex einlesbaren Modulen) versehen werden müssen, welche dann in Folge, ein direktes Teil-Abbild des Befehlssatzes der CPU selber darstellen würden. Das ist definitiv nicht möglich...

Wir leben (leider) nicht mehr im Zeitalter der "Metallprogrammierung", bzw. "undefinierter Opcodes" auf so einer CPU. (Spielekonsolen, Heimcomputer, Z80 etc. waren dagegen i.d.T. anfällig). Insofern wird es einer FF-Erweiterung - nach meiner Beurteilung - somit in der heutigen Zeit auch niemals möglich sein werden, direkt auf die zugrundeliegende Hardware zugreifen zu können.

madblueimp erklärte u.A. Folgendes:

Zitat

[...]Und IE7 unter Windows Vista mit "Protected Mode" und der Nutzung des Zonen-Modells ist wohl auch nicht ganz schlecht,[...]

Dem ist nichts hinzuzufügen - Vielleicht ist der IE - im professionellen Bereich - sogar noch vorteilhafter, als Du bisher annahmst...

Oliver

Oliver222 Deswegen habe ich geschrieben "entsprechende Lücken im Betriebssystem vorrausgesetzt". Naja wenn es ein Sicherheitsproblem mit der CPU gibt dann kann man das Betriebssystem natürlich auch ignorieren. Man erinnere sich an die Blackhat.