Als ich dies las , fand ich den folgenden Exploit:

% cp /usr/bin/id ~
% chmod -x ~/id
% ls -al ~/id
-rw-r--r-- 1 edd edd 22020 2012-08-01 15:06 /home/edd/id
% ~/id
zsh: permission denied: /home/edd/id
% /lib/ld-linux.so.2 ~/id
uid=1001(edd) gid=1001(edd) groups=1001(edd),1002(wheel)

Dieses Snippet zeigt, dass wir als normaler, nicht privilegierter Benutzer die Ausführungsberechtigungen des Dateisystems trivial umgehen können. Ich habe dies auf einem Ubuntu 12.04 ausgeführt.

Während der Linux-Loader ein Shared Object gemäß Datei (1) ist, hat er auch einen Einstiegspunkt, über den er direkt ausgeführt werden kann. Bei dieser Ausführung fungiert der Linux-Loader als Interpreter für ELF-Binärdateien.

Auf meinem OpenBSD-Rechner ist dieser Exploit jedoch nicht effektiv, da Sie den Loader möglicherweise nicht als Programm ausführen. Die OpenBSD-Handbuchseite sagt: "ld.so ist selbst ein gemeinsames Objekt, das anfänglich vom Kernel geladen wird."

Versuchen Sie dies unter Solaris 9, und Sie erhalten einen Segfault. Ich bin nicht sicher, was woanders passiert.

Meine Fragen sind daher:

• Warum wird der Linux Loader (wenn sie direkt ausgeführt wird ) nicht die Dateisystem - Attribute überprüfen , bevor ein ELF - Binaries zu interpretieren?
• Warum einen Mechanismus implementieren, der die Ausführung von Dateien verbietet, wenn er so einfach umgangen wird? Habe ich etwas verpasst

Das Ziel der executeErlaubnis ist es nicht , die Ausführung im Allgemeinen zu verhindern . Dies ist (1) um Programmen mitzuteilen, welche Dateien ausgeführt werden sollen, und (2) um die Ausführung als privilegierter Benutzer zu verhindern , wenn das setuid-Bit (usw.) angegeben ist.

Der Linker-Hack ist weniger ein Exploit als es scheint. Sie können jede nicht ausführbare Datei ausführen, für die Sie Leseberechtigungen haben:

$ cp unexecutable_file ~/runme
$ chmod +x ~/runme
$ ~/runme

Sehen Sie diese Diskussion auf dem Arch Linux Forum .

Zusammenfassend:

Dateien markieren, die ausgeführt werden sollen

Wenn Sie ein Shell-Skript schreiben, können Sie es mit als ausführbar markieren chmod +x. Dies weist Ihre Shell darauf hin, dass Sie beabsichtigen, dass sie ausführbar ist (ansonsten ist es nach Kenntnis der Shell nur eine einfache Textdatei). Die Shell kann es dann in der Tab-Vervollständigung anzeigen, wenn Sie tippen ./Tab.

Ähnlich: something.dVerzeichnisse (zB init.d) enthalten Startup- oder Control-Shell-Skripte, die normalerweise automatisch von Daemons ausgeführt werden. Möglicherweise möchten Sie einen Kommentar oder eine README-Datei als reine Textdatei in das Verzeichnis einfügen. Oder Sie möchten eines der Skripte vorübergehend deaktivieren. Sie können dies tun, indem Sie das Ausführungsbit für diese bestimmte Datei löschen. Dadurch wird der Dämon angewiesen, diesen Vorgang zu überspringen.

Privilegierte Ausführung verhindern

Das setuidBit bedeutet, dass die Datei beim Ausführen als angegebener Benutzer (z. B. root) ausgeführt wird.

Der Forumsbeitrag erklärt es gut:

Sie möchten, dass eine ausführbare Datei für einen bestimmten Benutzer als setuid festgelegt wird, aber Sie möchten, dass nur Personen aus einer bestimmten Gruppe sie als setuid ausführen können. Sie können es weiterhin durch Kopieren ausführen, aber das setuid-Flag geht verloren, sodass sie es als sie selbst ausführen und nicht als der Benutzer, dem die ursprüngliche Datei gehörte.

Wenn Sie Lesezugriff auf eine Datei haben, können Sie immer eine Kopie davon erstellen.

Wenn Sie eine persönliche Kopie erstellen können, können Sie diese Kopie immer als ausführbar markieren.

Dies erklärt nicht das Verhalten von ld-linux, weist jedoch darauf hin, dass es sich möglicherweise nicht um eine sehr nützliche Sicherheitslücke handelt.

Wenn Sie mehr Sicherheit wünschen, sollten Sie SELinux in Betracht ziehen

Betrachten Sie die Frage etwas anders: Wie Mechanical Snail sagt, soll die Ausführungsberechtigung für eine Datei die Ausführung nicht verhindern. Die Dateisystemoption "noexec" verhindert jedoch die Ausführung und wird nicht so leicht umgangen (nicht von allen Dateisystemen unterstützt, aber mit Sicherheit von den beliebtesten Linux-Systemen). Wenn der Administrator verhindern wollte, dass Benutzer eigene Programme ausführen, konnte er die Option noexec in den Verzeichnissen home und tmp sowie in allen anderen Verzeichnissen angeben, in denen die Benutzer möglicherweise Dateien erstellen können.

$ mount -o noexec /dev/sdd1 /test
$ cd /test
$ cp /usr/bin/id .
$ ./id
-bash: ./id: Permission denied

Anscheinend war es früher möglich, die noexec-Option mit dem in der Frage erwähnten Loader-Trick zu umgehen, aber das wurde im Kernel vor einigen Versionen behoben.

Von http://linux.die.net/man/8/mount :

noexec

Lassen Sie die direkte Ausführung von Binärdateien auf dem bereitgestellten Dateisystem nicht zu. (Bis vor kurzem war es ohnehin möglich, Binärdateien mit einem Befehl wie /lib/ld*.so / mnt / binary auszuführen. Dieser Trick schlägt seit Linux 2.4.25 / 2.6.0 fehl.)