Perché checksec.sh evidenzia rpath e runpath come problemi di sicurezza?

TL; DR: R*PATH ha una sfortunata storia di introduzione di nuovi modi di esecuzione di librerie non fidate (controllate dagli attacchi). RPATH / RUNPATH è solitamente evitabile e dovrebbe essere evitato.

In primo luogo, potrebbe valere la pena di esaminare i motivi per cui non è necessario fornire sicurezza vogliamo questi binari contrassegnati: distro (ad es. Wiki Debian su RPATH ) non piace che abbia la precedenza sul locale LD_LIBRARY_PATH e /etc/ld.so.conf settings / configs e convegni. Rende più difficile ragionare sulle librerie attraverso più visibile significa che correre readelf per ogni binario che vogliamo pensare circa, e complica la vita per i manutentori che si destreggiano molto di dipendenze intrecciate attraverso questi altri meccanismi che sono facilmente rotto da RPATH / RUNPATH . Ma ci sono delle eccezioni - ecco La politica di Debian:

The only time a binary or shared library in a Debian package should set RPATH or RUNPATH is if it is linked to private shared libraries in the same package.

In secondo luogo, RPATH relativo (cioè foo.so piuttosto che /usr/lib/foo.so ) può andare abbastanza male: il tuo utente potrebbe essere in esecuzione da una directory di lavoro (ad esempio /tmp ) che è soggetta al controllo dell'attaccante chi potrebbe piantare una versione dannosa di /tmp/foo.so . Questo era un osservazione fatta in bug Debian # 754278 contro openjdk .

Questo potrebbe sembrare benigno, ma può portare a privesc in particolare programmi setuid / setgid come IBM DBV privesc CVE-2014-0907 : basta eseguire il binario suid da una directory avviata per abusare di qualsiasi cosa RPATH è impostato e il codice verrà eseguito nel contesto di programma privilegiato. Altri esempi includono confezione di Slackware di llvm CVE-2013-7171 , La confezione di Gentoo di Imagemagick CVE-2005-3582 , Confezione SuSE di CVSup CVE-2004-2133 , ..). È stato un flusso così costante che equivalente di Apple evita il relativo RPATH in " con restrizioni "(suid / sgid) binari.

In terzo luogo, la variabile speciale $ORIGIN (chiamata percorso eseguibile) ha è stato un modo per evitare un percorso assoluto, mentre ancorava la ricerca qualche parte . Ma ha avuto problemi: glibc CVE-2011-0536 non è riuscito a espanderlo correttamente che ha dato agli attaccanti un equivalente del relativo caso RPATH in cui l'autore di un eseguibile che utilizza $ORIGIN pensava di ottenere qualcosa di leggermente più robusto.

Tenendo presente questo, probabilmente vorrai davvero checksec.sh da contrassegnare RPATH / RUNPATH - non è sempre male, ma checksec.sh no avere l'immagine più grande disponibile per rendere quella chiamata per te come il i ltri di distro possono, quindi è necessario un controllo manuale.

Addendum: Rottura dei link: Sfruttare il linker di Tim Brown è stato menzionato nelle risposte per la tua conversazione su Twitter, questo è un ottimo articolo sulla superficie di attacco più in generale per i linkers in stile POSIX e i lettori astuti dovrebbero assolutamente dare un'occhiata. La cosa più pertinente non è già presente:

On GNU/Linux at least, when the DT_RPATH or DT_RUNPATH exists within the ELF headers of a binary then these will be honoured first when looking for shared libraries. Additionally, the keyword $ORIGIN within this header is expanded to be the path of the directory where the object is found, while both . and the empty directory specification are honoured, even for binaries with the setUID bit set. From an attackers pespective, setUID binaries with DT_RPATH are particularly nice, since we can make use of hard links to manipulate the runtime linker into using an $ORIGIN which we can control.

... come osservato altrove nel documento, la maggior parte dei sistemi ignora le variabili d'ambiente fornite dall'utente come LD_LIBRARY_PATH sui binari setuid la maggior parte delle volte, ma come puoi vedere un% di trascuratezza di% equivale a dare all'attore un regalo equivalente .

2nd addendum: ContextIS ha un ottima scrittura che copre gli attacchi RPATH .