mod_php: PIC vs. non_PIC

[andreask2]

Hallo!

Bis vor einiger Zeit hatte ich immer gedacht, wenn ich ein DSO mod_php ohne PIC übersetze, wäre es fast genau so schnell wie ein statisch kompiliertes Modul (also bis zu 30% schneller):
http://ilia.ws/archives/28-PHPApache-Static-vs-DSO.html
http://talks.php.net/show/perf-oscom4/6
...
Ein entsprechendes Patch von Rasmus gab es irgendwo bei bugs.php.net.

Kürzlich hatte ich hier aber eine kleine Diskussion mit Joe User bzgl. PHP & Apache2 Worker MPM ;-) (evtl. interessiert folgende kürzlich erschienen Zusammenfassung der Diskussion auf php.internals bzgl. dieser Thematik: http://www.zend.com/zend/week/week216.php#Heading1). In diesem Zusammenhang machte mich Joe auf mögliche Sicherheitsprobleme durch Verwendung von mod_php ohne PIC-Unterstützung aufmerksam: http://www.rootforum.org/forum/viewtopi ... 411#208411

Allerdings fällt es mir schwer, dies nachzuvollziehen, da mir da auch noch einiges an Wissen fehlt.

Es ging vor allem um den folgenden Abschnitt:

If you are using the gentoo hardened toolchain, typically compiling your programs will create PIC ELF libraries that do not contain text relocations. However, certain libraries still contain text relocations for various reasons (often ones that contain assembly that is handled incorrectly). This can be a security vulnerability as an attacker can use non-PIC libraries to execute his shellcode. Non-PIC libraries are also bad for memory consumption as they defeat the code sharing purpose of shared libraries.

Quelle: http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml

Welche Gefahr bedeutet das konkret für mod_php unter Linux? Wenn ich jetzt non-PIC nutze - wer oder was kann mir dann wie Schaden zufügen? Doch nur mit einem lokalen Account, oder? PIC hatte doch was damit zu tun, dass Libraries oder irgendwelcher Code geteilt wird, oder?

Jedenfalls ist jetzt ein entsprechendes Patch im CVS, wodurch mod_php ab der nächsten Version per default auf Linux-Systemen ohne PIC übersetzt werden wird:

On Linux and FreeBSD systems where non-PIC is known to be safe, the default build is now non-PIC

Quelle: http://www.zend.com/zend/week/week219.php#Heading7

Was ich jetzt gerne wissen würde - haben die Jungs da jetzt alle irgendwas übersehen, oder hat dieses prinzipielle Angriffsmöglichkeit keine konkreten Auswirkungen auf mod_php?


Viele Grüße
Andreas

[captaincrunch]

Wenn ich jetzt non-PIC nutze - wer oder was kann mir dann wie Schaden zufügen? Doch nur mit einem lokalen Account, oder? PIC hatte doch was damit zu tun, dass Libraries oder irgendwelcher Code geteilt wird, oder?

PIC==Position Independent Code.
Ziemlich gute Erklärungen gibt's hier: http://www.dbforums.com/t1077340.html

Die Gefahr, die durch non-PIC-Binaries, bzw. -Libs ausgeht ist dabei allerdings nicht zwingend "lokal" zu sehen. Ohne PIC kann (nicht muss) die Position des Codesegments im Speicher erheblich einfacher für Angreifer rauszufinden und schlimmstenfalls durch eingeschleusten Code zu ersetzen.
Im Falle von mod_php führt dieser Weg aber naturgemäß erstmal über den Webserver, weshalb ein Ausnutzen dieser Gefahr hier (IMHO) relativ gering ist.
Da in deinem Fall aber wohl auch noch zusätzlich PaX (hoffentlich in der richtigen Konfiguration) zum Einsatz kommt, werden Stack, Heap und die Position von shared libraries im Speicher aber ohne randomized, was diese Gefahr zusätzlich erheblich abschwächt. Ein nettes Beispiel dazu findest du unter http://www.adamantix.org/demo.html

Was ich jetzt gerne wissen würde - haben die Jungs da jetzt alle irgendwas übersehen, oder hat dieses prinzipielle Angriffsmöglichkeit keine konkreten Auswirkungen auf mod_php?

Die grundsätzliche Frage, die dabei erst einmal zu stellen ist, ist die, warum die Devs non-Pic auf bestimmten Systemen als "safe" ansehen. Diese Frage kann ich dir allerdings leider nicht beantworten. ;)

[andreask2]

Hallo!

PIC==Position Independent Code.
Ziemlich gute Erklärungen gibt's hier: http://www.dbforums.com/t1077340.html
[Erklärung]

Danke für den Link und die Erklärung!

Im Falle von mod_php führt dieser Weg aber naturgemäß erstmal über den Webserver, weshalb ein Ausnutzen dieser Gefahr hier (IMHO) relativ gering ist.

warum? Weil solche Attacken über den Webserver prinzipiell schwieriger sind?

Da in deinem Fall aber wohl auch noch zusätzlich PaX (hoffentlich in der richtigen Konfiguration) zum Einsatz kommt, werden Stack, Heap und die Position von shared libraries im Speicher aber ohne randomized, was diese Gefahr zusätzlich erheblich abschwächt.

Nun ja, ich verwende folgende config:

Code: Select all

$ cat /usr/src/linux/.config | grep PAX
# CONFIG_GRKERNSEC_PAX_SOFTMODE is not set
CONFIG_GRKERNSEC_PAX_EI_PAX=y
# CONFIG_GRKERNSEC_PAX_PT_PAX_FLAGS is not set
CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS=y
# CONFIG_GRKERNSEC_PAX_HAVE_ACL_FLAGS is not set
# CONFIG_GRKERNSEC_PAX_HOOK_ACL_FLAGS is not set
CONFIG_GRKERNSEC_PAX_NOEXEC=y
# CONFIG_GRKERNSEC_PAX_PAGEEXEC is not set
CONFIG_GRKERNSEC_PAX_SEGMEXEC=y
# CONFIG_GRKERNSEC_PAX_EMUTRAMP is not set
CONFIG_GRKERNSEC_PAX_MPROTECT=y
# CONFIG_GRKERNSEC_PAX_NOELFRELOCS is not set
CONFIG_GRKERNSEC_PAX_ASLR=y
CONFIG_GRKERNSEC_PAX_RANDKSTACK=y
CONFIG_GRKERNSEC_PAX_RANDUSTACK=y
CONFIG_GRKERNSEC_PAX_RANDMMAP=y
CONFIG_GRKERNSEC_PAX_RANDEXEC=y

Allerdings bringt das den anderen die PAX nicht verwenden ja herzlich wenig, denn non-PIC würde ja per default ab der nächsten PHP-Version überall so angewendet!

Die grundsätzliche Frage, die dabei erst einmal zu stellen ist, ist die, warum die Devs non-Pic auf bestimmten Systemen als "safe" ansehen. Diese Frage kann ich dir allerdings leider nicht beantworten. ;)

Ich habe die Frage mal dem Autor des Textes gestellt...

Grüße
Andreas

[andreask2]

Ich habe folgende Antwort von Rasmus erhalten:

The code-sharing savings is a non-issue here since libphp is not your
traditional shared library that can be loaded by many different binaries
on a system. It is typically loaded by just one which then forks. The
statement that it is safe on Linux and FreeBSD had nothing to do with
security, it had to do with whether the runtime linker could actually
handle it on those systems. Whether you feel your system is secure
enough to run a non-pic library is completely up to you and why we have
a configure override for you to set this.

Das klärt auf jedenfall, dass ich "safe" falsch interpretiert hatte ;-)

Allerdings kann ich die Gefahr die dann tatsächlich von mod_php mit non-PIC (ohne PAX) ausgeht, noch immer nicht einschätzen.

[Joe User]

Um es mal primitiv auszudrücken: Für viele Windows-Programme gibt es Cracks in Form von Patchern/Loadern. Diese Loader funktionieren nur bei non-PIC, bei PIC würden sie schlichtweg versagen. Genaueres findest in den von CC und mir genannten Referenzen.

[captaincrunch]

Ich persönlich halte das Risiko, das jemand einen erfolgreichen Angriff über das non-PIC mod_php startet trotz allem für recht gering. Da gibt's nun wirklich erheblich bessere (und vor allem einfachere) Mittel und Wege. ;)