Hallo Welt!
Ich hab nicht viel Ahnung von der Materie. Hier nur eine generelle Frage. Ich habe hier 2 Programme, die beide zur Compiletime gegen dieselbe statische Library gelinkt werden. Dabei werden AFAIK nur die benötigten Object-Files aus der Library herauskopiert und an das Binary rangeklatscht. Da beide Programme sehr viele Objecte benötigen, ist das nicht sehr effektiv. Meine Idee bestand nun darin, eine dyn. Lib zu bauen und die Programme dagegen zu linken. Also werden die einzelnen Objecte mit gcc -fPIC -DPIC $(RESTOPTS) compiliert und mit gcc -shared -Wl,-soname -Wl,liblib.so.0 -o liblib.so $(OBJ) die Dynlib gebaut. Frage: Ist das prinzipiell immer so möglich oder kann es Probleme geben? (Wenn die Begründung zu ausschweifend wird, bitte weglassen).
H.
Hallo Hilmar,
Am Sonntag, dem 24. September 2000 um 20:27:27, schrieb Hilmar Preusse:
gcc -fPIC -DPIC $(RESTOPTS) compiliert und mit gcc -shared -Wl,-soname -Wl,liblib.so.0 -o liblib.so $(OBJ) die Dynlib gebaut. Frage: Ist das prinzipiell immer so moeglich oder kann es Probleme geben? (Wenn die Begruendung zu ausschweifend wird, bitte weglassen).
Wahrscheinlich ja, wahrscheinlich nein.
Tschuess Torsten
On Sun, Sep 24, 2000 at 08:27:27PM +0200, Hilmar Preusse wrote:
gcc -fPIC -DPIC $(RESTOPTS)
"-DPIC" benötigt man mMn nicht
compiliert und mit gcc -shared -Wl,-soname -Wl,liblib.so.0 -o liblib.so $(OBJ)
Wenn du ueber den gcc an den ld mehrere Optionen weiterreichen willst, kannst du das mit Komma getrennt in einer Liste machen, also -Wl,-soname,liblib.so.0
Bei soname=liblib.so.0 heisst das file der lib ueblicherweise liblib.0.unter.version. Der Link nach liblib.so.0 ist fuer den ld.so noetig der link nach liblib.so ist ueblich, um beim Compilieren einfach -llib sagen zu koennen.
die Dynlib gebaut. Frage: Ist das prinzipiell immer so möglich oder kann es Probleme geben? (Wenn die Begründung zu ausschweifend wird, bitte weglassen).
Warum nicht? Welche Zweifel hast du?
Reinhard
On 24.09.00 Reinhard Foerster (rf11@inf.tu-dresden.de) wrote:
Moin,
On Sun, Sep 24, 2000 at 08:27:27PM +0200, Hilmar Preusse wrote:
gcc -fPIC -DPIC $(RESTOPTS)
"-DPIC" benötigt man mMn nicht
Ist ein Makro. Was kann man damit anfangen?
Wenn du ueber den gcc an den ld mehrere Optionen weiterreichen willst, kannst du das mit Komma getrennt in einer Liste machen, also -Wl,-soname,liblib.so.0
Gut, sieht besser aus...
Bei soname=liblib.so.0 heisst das file der lib ueblicherweise liblib.0.unter.version. Der Link nach liblib.so.0 ist fuer den ld.so noetig der link nach liblib.so ist ueblich, um beim Compilieren einfach -llib sagen zu koennen.
Bei mir heißt das Originalfile jetzt .so und die anderen beiden sind Symlinks. Ich könnte doch sicher einen weglassen, indem ich die Lib mit -Wl,-soname als liblib.so deklariere, oder?
Frage: Ist das prinzipiell immer so möglich oder kann es Probleme geben? (Wenn die Begründung zu ausschweifend wird, bitte weglassen).
Warum nicht? Welche Zweifel hast du?
Kein Ahnung, deswegen frage ich ja. Warum wird die Lib der OpenSSL als statische Lib gebaut und nicht als dynamische, was IMHO vorteilhafter sein sollte? Weil man nach erfolgreichem Bau eines Progs, was dagegen "gelinkt" wurde, die Libs wieder deinstallieren kann und ein spezielles Programm eh nur ein paar Funktionen benötigt? Um Bugs im ld.so aus dem Weg zu gehen?
Hilmar
On Mon, Sep 25, 2000 at 04:32:59PM +0200, Hilmar Preusse wrote:
"-DPIC" benötigt man mMn nicht
Ist ein Makro. Was kann man damit anfangen?
Wenn du es nicht selbst per #ifdef abfragst ist es wahrscheinlich sinnnlos.
Bei soname=liblib.so.0 heisst das file der lib ueblicherweise liblib.0.unter.version. Der Link nach liblib.so.0 ist fuer den ld.so noetig der link nach liblib.so ist ueblich, um beim Compilieren einfach -llib sagen zu koennen.
Bei mir heißt das Originalfile jetzt .so und die anderen beiden sind Symlinks. Ich könnte doch sicher einen weglassen, indem ich die Lib mit -Wl,-soname als liblib.so deklariere, oder?
Du kanns auch völlig ohne Symlinks auskommen.
Frage: Ist das prinzipiell immer so möglich oder kann es Probleme geben? (Wenn die Begründung zu ausschweifend wird, bitte weglassen).
Warum nicht? Welche Zweifel hast du?
Kein Ahnung, deswegen frage ich ja. Warum wird die Lib der OpenSSL als statische Lib gebaut und nicht als dynamische, was IMHO vorteilhafter sein sollte? Weil man nach erfolgreichem Bau eines Progs, was dagegen "gelinkt" wurde, die Libs wieder deinstallieren kann und ein spezielles Programm eh nur ein paar Funktionen benötigt? Um Bugs im ld.so aus dem Weg zu gehen?
Vielleicht nur Faulheit der Distributoren. Bei Debian ist sie shared: rf11@rncmm14:~> ssh -V SSH Version OpenSSH-1.2.3, protocol version 1.5. Compiled with SSL. rf11@rncmm14:~> ldd `which ssh` libdl.so.2 => /lib/libdl.so.2 (0x40016000) libnsl.so.1 => /lib/libnsl.so.1 (0x4001a000) libz.so.1 => /usr/lib/libz.so.1 (0x40030000) libutil.so.1 => /lib/libutil.so.1 (0x4003f000) libpam.so.0 => /lib/libpam.so.0 (0x40043000) libcrypto.so.0 => /usr/lib/libcrypto.so.0 (0x4004b000) libwrap.so.0 => /lib/libwrap.so.0 (0x400f5000) libc.so.6 => /lib/libc.so.6 (0x400fc000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x401d9000) rf11@rncmm14:~> dpkg -S /usr/lib/libcrypto.so.0 libssl09: /usr/lib/libcrypto.so.0 rf11@rncmm14:~> dpkg -l libssl09 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-==============-==============-============================================ ii libssl09 0.9.4-5 SSL shared libraries rf11@rncmm14:~>
Reinhard
Kein Ahnung, deswegen frage ich ja. Warum wird die Lib der OpenSSL als statische Lib gebaut und nicht als dynamische, was IMHO vorteilhafter sein sollte? Weil man nach erfolgreichem Bau eines Progs, was dagegen "gelinkt" wurde, die Libs wieder deinstallieren kann und ein spezielles Programm eh nur ein paar Funktionen benötigt? Um Bugs im ld.so aus dem Weg zu gehen?
nein, das ist mehr eine sicherheitsfrage. ich habe zumindest mal auf einer einschlägigen seite gelesen, daß es relativ easy ist, die verweise auf dynam. libs zu tauschen. d.h. die orginale würden funktionen aus den gefakte dynam. libs verwenden und so das sicherheitskonzept aufhebeln. insbesondere bei openssl sollte das vielleicht nicht unbedingt passieren. es gibt wohl auch keine andere abwehr gegen solche angriffe als statisches linken. wie gesagt, ich habe das noch nicht probiert, aber es klang da sehr logisch. für nähere infos kannst du ja mal die linkseite auf www.outpost9.net (oder .com?) studieren.
cu ronny
On Tue, Sep 26, 2000 at 06:58:05PM +0200, Ronny Roeller wrote:
nein, das ist mehr eine sicherheitsfrage. ich habe zumindest mal auf einer einschlägigen seite gelesen, daß es relativ easy ist, die verweise auf dynam. libs zu tauschen. d.h. die orginale würden funktionen aus den gefakte dynam. libs verwenden und so das sicherheitskonzept aufhebeln. insbesondere bei openssl sollte das vielleicht nicht unbedingt passieren. es gibt wohl auch keine andere abwehr gegen solche angriffe als statisches linken. wie gesagt, ich habe das noch nicht probiert, aber es klang da sehr logisch. für nähere infos kannst du ja mal die linkseite auf www.outpost9.net (oder .com?) studieren.
Könntest du das bitte nochmal genau heraussuchen. Ich kann auf der angebenen Seite dazu nichts finden und zweifle sehr stark am Inhalt der obigen Analyse. Wenn der Content von outpost9.com qualitativ so ist, wie der auf der Seite verwendete und entfernt an HTML erinnernde Kode, kannst du das dort Gelesene getrost vergessen.
Reinhard
Am Dienstag, dem 26. September 2000 um 19:09:10, schrieb Reinhard Foerster:
On Tue, Sep 26, 2000 at 06:58:05PM +0200, Ronny Roeller wrote:
nein, das ist mehr eine sicherheitsfrage. ich habe zumindest mal auf einer einschlaegigen seite gelesen, dass es relativ easy ist, die verweise auf dynam. libs zu tauschen. d.h. die orginale wuerden funktionen aus den gefakte dynam. libs verwenden und so das sicherheitskonzept aufhebeln.
fuer naehere infos kannst du ja mal die linkseite auf www.outpost9.net (oder .com?) studieren.
Koenntest du das bitte nochmal genau heraussuchen. Ich kann auf der angebenen Seite dazu nichts finden und zweifle sehr stark am Inhalt der obigen Analyse. Wenn der Content von outpost9.com qualitativ so ist, wie der auf der Seite verwendete und entfernt an HTML erinnernde Kode, kannst du das dort Gelesene getrost vergessen.
Jemand, der in der Lage ist den dyn. Libs im System irgendwas anderes unterzujubeln, der kann auch ein statisch gelinktes Binary tauschen. Ich sehe keinen Vorteil fuer statische Binaries und wuerde mich Reinhards Einschaetzung anschliessen.
Torsten
Jemand, der in der Lage ist den dyn. Libs im System irgendwas anderes unterzujubeln, der kann auch ein statisch gelinktes Binary tauschen.
nein, eben nicht. man manipuliert ja eben nicht das probgramm oder die originale dynam. lib, sondern den linkprozeß. kann sein, daß mein geschribsel nicht besonders logisch war: also, daß funktioniert auch nur, wenn du selbst das programm ausführst. um fremde rechte zu erlangen, muß es deswegen auch ein suid-programm sein.
cu ronny
On Fri, Sep 29, 2000 at 10:44:10AM +0200, Ronny Roeller wrote:
Jemand, der in der Lage ist den dyn. Libs im System irgendwas anderes unterzujubeln, der kann auch ein statisch gelinktes Binary tauschen.
nein, eben nicht. man manipuliert ja eben nicht das probgramm oder die originale dynam. lib, sondern den linkprozeß. kann sein, daß mein geschribsel nicht besonders logisch war: also, daß funktioniert auch nur, wenn du selbst das programm ausführst.
Ja, mit den von Heiko beschriebenen Variablen. Das man sich selbst ins Knie schiessen kann ist allerdings schwer zu verhindern :)
erlangen, muß es deswegen auch ein suid-programm sein.
Bei suid-Programmen werden vom deshalb ld.so die LD_XXX-Variablen ignoriert. Ich kann das Problem noch immer nicht sehen.
Reinhard
On Thu, Sep 28, 2000 at 10:49:43PM +0200, Torsten Werner wrote:
Jemand, der in der Lage ist den dyn. Libs im System irgendwas anderes unterzujubeln, der kann auch ein statisch gelinktes Binary tauschen. Ich sehe keinen Vorteil fuer statische Binaries und wuerde mich Reinhards Einschaetzung anschliessen.
Es muessen nicht Bibliotheken getauscht werden. Ich denke, selbst Dinge wie LD_LIBRARY_PATH oder LD_PRELOAD reichen da doch schon aus. (-> fakeroot bei Debian). [[[ aber das ist nur so ein Gedanke ]]] ... jedenfalls wuerde ich mich dem Sicherheitsaspekt anschliessen.
Heiko
On Fri, Sep 29, 2000 at 11:47:24AM +0200, Heiko Schlittermann wrote:
Jemand, der in der Lage ist den dyn. Libs im System irgendwas anderes unterzujubeln, der kann auch ein statisch gelinktes Binary tauschen. Ich sehe keinen Vorteil fuer statische Binaries und wuerde mich Reinhards Einschaetzung anschliessen.
Es muessen nicht Bibliotheken getauscht werden. Ich denke, selbst Dinge wie LD_LIBRARY_PATH oder LD_PRELOAD reichen da doch schon aus. (->
Schon klar. Nur 1.) wie schiebst du mir eine dieser Variablen unter? Und 2.) wenn du 1. schaffst kannst du durch Manipulation anderer Variablen sowieso mit mir machen was du willst. Ich sehe also nach wie vor keinen Sicherheitsgewinn durch statisch gelinkte binaries.
Reinhard
On Fri, Sep 29, 2000 at 05:15:39PM +0200, Reinhard Foerster wrote:
On Fri, Sep 29, 2000 at 11:47:24AM +0200, Heiko Schlittermann wrote:
Es muessen nicht Bibliotheken getauscht werden. Ich denke, selbst Dinge wie LD_LIBRARY_PATH oder LD_PRELOAD reichen da doch schon aus. (->
Schon klar. Nur 1.) wie schiebst du mir eine dieser Variablen unter? Und 2.) wenn du 1. schaffst kannst du durch Manipulation anderer Variablen sowieso mit mir machen was du willst. Ich sehe also nach wie vor keinen Sicherheitsgewinn durch statisch gelinkte binaries.
Wenn /home und /tmp mit der Option noexec gemountet wird, koennte man mit den LD_-Variablen doch wieder eigenen Binaercode ausfuehren. Um das zu verhindern, muesste root aber alles statisch linken. Einen Sinn im statischen Linken eines einzelnen Binaries sehe ich auch nicht.
Torsten
On Fri, Sep 29, 2000 at 05:27:37PM +0200, twerner@intercomm.de wrote:
Wenn /home und /tmp mit der Option noexec gemountet wird, koennte man mit den LD_-Variablen doch wieder eigenen Binaercode ausfuehren. Um das
Stimmt. Sobald man irgendein Binary unter eigener UID ausfueheren kann, kann man damit auch eigene Dinge laufen lassen.
zu verhindern, muesste root aber alles statisch linken.
Oder alle mit suid-Flag versehen. Das ist allerdings ein recht ungewöhnliches Szenario. Ich kann mir vorstellen, dass man bald viele Programme ohne Verlust von Funktionalitaet gar nicht mehr komplett statisch bauen kann. Je nach Rechner koennen z.B. andere PAM- oder NSS-Module nötig sein, von denen man zur Compilezeit gar nix weiss. Bei Solaris ist das jedenfalls schon so und das NSS-System in Linux (genauer: in der glibc-2) ist völlig von Sun abgekupfert.
Reinhard
Schon klar. Nur 1.) wie schiebst du mir eine dieser Variablen unter? Und
das ding funktioniert natürlich nur mit suid-programm, die der angreifer selbst ausführen kann. aber da ist es eine relativ interessante sache, um rootrechte zu erhalten. d.h. es wird nicht dein (also des angegriffen) envirment geändert, sondern meins (sprich des angreifers).
cu ronny
On Fri, Sep 29, 2000 at 06:40:39PM +0200, Ronny Roeller wrote:
Schon klar. Nur 1.) wie schiebst du mir eine dieser Variablen unter? Und
das ding funktioniert natürlich nur mit suid-programm, die der angreifer selbst ausführen kann. aber da ist es eine relativ interessante sache, um rootrechte zu erhalten. d.h. es wird nicht dein (also des angegriffen) envirment geändert, sondern meins (sprich des angreifers).
Sorry, ich muss heute einen schlechten Tag haben - ich kapiere es leider nicht :) Kannst du mal genau sagen, wem was gehoeren soll, wer was ausfuehren soll und wesen environment dann geandert ist bzw. wie da jemand root wird? Am besten so in der Art: - Angreifer A legt file mit Permissions x und uid/gid=y/z an - Opfer B startet das ganze - usw.
Reinhard
hallo,
Sorry, ich muss heute einen schlechten Tag haben - ich kapiere es leider nicht :)
hmm, es kann auch am autor liegen. ;)
Kannst du mal genau sagen, wem was gehoeren soll, wer was ausfuehren soll und wesen environment dann geandert ist bzw. wie da jemand root wird? Am besten so in der Art:
- es gibt ein programm P, das eine funktion F aus der dynam. library L ausführt. zumindest wärend der ausführung von F läuft es mit erweiterten rechten (z.b. suid auf root). die dynamische lib L liegt bsp.weise in /usr/lib. - Angreifer A nimmt sich den source-code von L und ändert die betreffede Funktion F. [wie gehen mal davon aus, daß das programm open-source ist, ansonsten ist es halt *etwas* streßiger.] die neue lib trage den namen FL (fakelib) mit der funktion FF (fake function) - der pfad zu FL sollte vor dem nach L liegen in LD_* - /home und /tmp mit der Option noexec mounten - jetzt startet angreifer A das programm P - der linker findet nun die lib FL vor L - folglich wird FF statt F ausgeführt
für meine begriffe sollte das funktionieren und wenn man in FF nicht nur "hello world" ausgibt, auch die übernahme des rechners möglich sein.
cu ronny
On Sat, Sep 30, 2000 at 12:42:34PM +0200, Ronny Roeller wrote:
Kannst du mal genau sagen, wem was gehoeren soll, wer was ausfuehren soll und wesen environment dann geandert ist bzw. wie da jemand root wird? Am besten so in der Art:
- es gibt ein programm P, das eine funktion F aus der dynam. library L
ausführt. zumindest wärend der ausführung von F läuft es mit erweiterten rechten (z.b. suid auf root). die dynamische lib L liegt bsp.weise in /usr/lib.
- Angreifer A nimmt sich den source-code von L und ändert die betreffede
Funktion F. [wie gehen mal davon aus, daß das programm open-source ist, ansonsten ist es halt *etwas* streßiger.] die neue lib trage den namen FL (fakelib) mit der funktion FF (fake function)
- der pfad zu FL sollte vor dem nach L liegen in LD_*
- /home und /tmp mit der Option noexec mounten
- jetzt startet angreifer A das programm P
- der linker findet nun die lib FL vor L
- folglich wird FF statt F ausgeführt
*verstanden* :)
Deine Idee klappt allerding nicht, da bei binaries mit suid und/oder sgid-Bit, die LD-Variablen gar nicht ausgewerten werden. Aus "man ld.so":
The necessary shared libraries needed by the program are searched for in the following order
o Using the environment variable LD_LIBRARY_PATH (LD_AOUT_LIBRARY_PATH for a.out programs). Except if the executable is a setuid/setgid binary, in which case it is ignored.
[und weiter unten]
LD_PRELOAD A whitespace-separated list of additional, user- specified, ELF shared libraries to be loaded before all others. This can be used to selectively over ride functions in other shared libraries. For setuid/setgid ELF binaries, only libraries in the standard search directories that are also setgid
für meine begriffe sollte das funktionieren und wenn man in FF nicht nur "hello world" ausgibt, auch die übernahme des rechners möglich sein.
Nein. Das haben sich natuerlich auch schon andere Leute ueberlegt. Dein Angriff klappt wie oben beschrieben nicht.
Reinhard
Deine Idee klappt allerding nicht, da bei binaries mit suid und/oder sgid-Bit, die LD-Variablen gar nicht ausgewerten werden. Aus "man ld.so":
hmmm, is' wahr. allerdings glaube ich immer noch, daß es dafür einen workaround gibt. ok, sobald ich wieder etwas mehr zeit habe, werde ich das nachforschen (->[add to todo]). wenn ich ein ergebnis habe, poste ich es.
cu ronny
lug-dd@mailman.schlittermann.de
-
Heiko Schlittermann -
Hilmar Preusse -
Reinhard Foerster -
Ronny Roeller -
Torsten Werner -
twerner＠intercomm.de