it-swarm.com.de

Sind die meisten Linux-Systeme, mit denen Nicht-Root-Benutzer Code ausführen können, direkt rootbar?

kurz gesagt, wenn Sie Code auf einer Box ausführen können, ist es normalerweise einfach, root zu bekommen

( Zitatquelle )

Die unmittelbare Auswirkung dieses Zitats (wenn es korrekt ist) ist, dass das System ist, wenn Sie ein Mehrbenutzersystem ausführen und nicht versuchen, alle Benutzer daran zu hindern, Dateien mit dem Berechtigungssatz x zu erstellen so gut wie kompromittiert. Die Konsequenz ist, dass der Betrieb eines Mehrbenutzersystems, wie es normalerweise an Universitäten üblich ist und das es allen Studenten ermöglicht, Übungen in C, C++, Assembly usw. zu machen, sinnlos ist, da jeder Student dieses System direkt rooten kann.

Da das Ausführen von Computersystemen, die von mehr Personen als ihren Besitzern verwendet werden sollen, nicht als sinnlos angesehen wird und Funktionen zur Einschränkung von Berechtigungen (Verwaltung von Benutzerrechten, Sandboxing usw. usw.) nicht als nutzlos angesehen werden, bezweifle ich diese Art von Kommentaren. Aber was weiß ich?

Stimmt es, dass die meisten Linux-Systeme von jedem, der Code auf ihnen ausführen kann, direkt verwurzelt werden können?

64
gaazkam

Nein, dies ist nicht korrekt. Während man über die relative Schwierigkeit streiten kann, 0-Tage-Schwachstellen unter Linux zu finden und auszunutzen, wenn Sie lokalen Zugriff haben, die Sicherheitsarchitektur selbst eines modernen Linux-Systems (mit einem MMU ) wurde entwickelt, um verschiedene Benutzer zu isolieren und eine Eskalation von Berechtigungen zu verhindern. Ein Benutzer ohne Rootberechtigung kann ohne entsprechende Berechtigung kein Root-Verzeichnis erstellen, ohne eine vorhandene Sicherheitsanfälligkeit auszunutzen. Solche Sicherheitsanfälligkeiten bezüglich der Eskalation von Berechtigungen werden sehr schnell behoben, sobald sie entdeckt werden.* *

Es ist jedoch möglich, den Faktor human zu missbrauchen und Wurzeln zu schlagen, indem Missverständnisse ausgenutzt werden, die im Sysadmin-Beruf allgegenwärtig sind. Dies beruht natürlich darauf, dass der Systemadministrator die Sicherheitsarchitektur des von ihm verwalteten Systems falsch versteht. Eine nicht erschöpfende Liste von Beispielen:

  • Erhöhen von Berechtigungen mit Sudo oder su von einem nicht privilegierten, aber nicht vertrauenswürdigen Benutzer.1

  • Einen Systemadministrator dazu bringen, ldd auf einer böswilligen statischen ausführbaren Datei als root auszuführen.2

  • Missbrauch einer unsicher installierten Binärdatei.

  • Vom Root auf einen geringeren Benutzer fallen lassen, um einen TTY-Pushback-Angriff zu ermöglichen.45

* Obwohl dies angeblich zutrifft, aktualisieren sich viele Bereitstellungen nicht häufig genug, was dazu führt, dass Live-Produktionssysteme für bekannte Fehler anfällig sind. Ein verfügbares Update garantiert nicht, dass ein Update installiert wird.

90
forest

Um das Zitat neu zu formulieren: Es gab Sicherheitslücken bei der Eskalation von Berechtigungen, die weiterhin gefunden oder erstellt werden.

In der letzten Woche haben wir dieser kleine Trottel in SystemD ; Was werden wir nächste Woche haben, wird es rechtzeitig gepatcht und wie gut ist Ihr Patch-Regime?

Sie sollten davon ausgehen, dass es möglich ist, dass ein Angreifer, der auf einer Box ausgeführt werden kann, wahrscheinlich irgendwann Root-Zugriff auf seine Betriebssysteminstanz erhält, unabhängig davon, welches Betriebssystem im Spiel ist. Wie "einfach" eine solche Aufgabe ist, ist vielleicht umstritten, aber wenn ein Benutzer beliebigen Code ausführen kann, bietet er ihm viel Spielraum.

26
James Snell

Das Ausnutzen einer Sicherheitsanfälligkeit bezüglich der Eskalation von Berechtigungen ist bereits schwierig genug. Dabei ist es viel schwieriger, sicher zu sein, dass Sie keine Spur hinterlassen. Ein Android Benutzer, der versucht, sein Telefon zu rooten, kann weiterhin einen Exploit nach dem anderen versuchen, ohne sich Sorgen zu machen oder seine Spuren zu vertuschen. Ein Schüler versucht wiederholt, Sudo zu missbrauchen oder sich zu verbreiten Fischige ausführbare Dateien in der gesamten Dateifreigabe werden wahrscheinlich bemerkt und gerügt oder ausgewiesen.

Übrigens besteht die erste Möglichkeit, in einer Mehrbenutzereinstellung Root-Zugriff zu erhalten, darin, zu warten, bis ein privilegierter Benutzer die Workstation verlässt und vergisst, sie zu sperren. Ich habe das an zwei von drei Universitäten gesehen, die ich besucht habe. Es gilt jedoch die gleiche Bemerkung, nicht erwischt zu werden.

14

Ich denke, "unkompliziert" bedeutet "ohne menschliche Tricks und anderes Social Engineering". Die Antwort lautet also: Ja, wenn die Systeme nicht gepatchte 0-Tage enthalten, führt dies zu einer Eskalation der Berechtigungen.

Es kann sich um einen 0-Tage auf Anwendungsebene handeln. Zum Beispiel, wenn es ausführbare Dateien im Besitz von root mit setuid-Berechtigungen gibt, die sich auf beliebige Dateien auswirken können. Letzte Referenz ist Xorg . Sie können nach möglichen Vektoren wie diesen suchen: find / -user root -perm -4000 -print 2>/dev/null. Ein weiteres Beispiel - Systemdienst wie systemd oben erwähnt.

Oder es könnte ein 0-Tag auf Kernel-Ebene sein. Sie sind ziemlich seltener, aber lauter, weil ihre Abdeckung viel breiter ist. Gute Referenz ist schmutzige Kuh .

Oben ist wahr, wenn Obligatorische Zugriffskontrolle aktiviert ist, was die Ausführung einiger Exploits verhindern kann.

Oder es könnte sogar ein Boot-Level-Angriff sein. Secure Boot ist dann dein Freund.

5
odo