4. system() exploit auf Linux/UNIX

system() exploit auf Linux/UNIX

  • M

    Hi
    da jeder sagt, dass man diese funktion nicht benutzen sollte, dann könnt ihr doch auch mal zeigen, wie man sowas denn ausnutzt.
    Ich meine ein exploit, dass ein programm mit der funktion system() ausnutzt
    (für die, die noch nicht verstanden haben, was ich meine 🙂 )
    Könnt ihr mir paar beispiele zeigen?

    programmbeispiel:

    #include <stdio.h>
#include <stdlib.h>
int main() {
system ("ls -lsa");
return 0;  }

    vielen dank im voraus

    ps "Dafür habe ich keine code 😉 "

    0
  • A

    Probier einfach mal aus im gleichen Verzeichnis, in dem du das Programm startest, eine Batch-Datei anzulegen, die "ls" heißt, aber etwas ganz anderes macht, z. B. ein cd oder so. (Ich habs übrigens nicht ausprobiert, was passiert - vielleicht wird auch ganz normal das ls ausgeführt.)

    Übrigens:
    Nur weil man system() nicht für Systembefehle mißbrauchen sollte, heißt das nicht, dass man es überhaupt nicht benutzen sollte :).

    0
  • ?

    AJ schrieb:

    Probier einfach mal aus im gleichen Verzeichnis, in dem du das Programm startest, eine Batch-Datei anzulegen, die "ls" heißt, aber etwas ganz anderes macht, z. B. ein cd oder so. (Ich habs übrigens nicht ausprobiert, was passiert - vielleicht wird auch ganz normal das ls ausgeführt.)

    Es wird nur das "normale" ls ausgeführt. Eine Datei im selben Verzeichnis müsste man wenn dann mit ./ls ausführen.

    Man könnte sich aber über einen anderen Exploit root-Rechte verschaffen und das echte ls ersetzen 😃

    0
  • M

    Der hauptsächliche Grund dafür ist doch nicht, dass man Programme, die system nutzen, leichter exploiten kann. Es geht einfach nur darum, dass die meisten system-Aufrufe nicht plattformübergreifend lauffähig sind. Für solche Befehle nutzt man unter Linux nämlich Shellskripte und unter Windows Batchdateien. Außerdem gibt es auf beiden Systemen Bibliotheksfunktionen, die die gleiche Funktion in "nativer" Form bieten.

    @AJ:

    Das Verhalten der system-Befehle ist genau das gleiche wie in der Shell selbst. Daher bringt ein system("ls") auch wirklich nur ein harmloses ls. Für das Ausführen eines lokalen ls-Skriptes müsste das demnach auch system("./ls") heißen.

    0
  • M

    das ist mir ja alles klar, deswegen habe ich euch nicht gebeten.
    Ich wollte nur ein beispiel für einen exploit sehen 🙂
    Wenn jemand sagt, dass die funktion ausnutzbar ist, der sollte es auch beweisen können.

    0
  • P

    Wenn du Schreibrechte auf die ausführbare Datei hast, kannst du den String
    "ls -lsa"
    durch einen beliebigen anderen String ersetzen (zb. "rm -r /"),du musst nur darauf achten, dass die beiden Strings gleich lang sind.

    0
  • A

    @TactX + masterfx32
    Wenn der Commandozeileninterpreter zuerst die Systembefehle verwendet und dann erst die ausführbaren Dateien im Verzeichnis sich anschaut (Ich weiß es leider nicht :().
    Ich bin übrigens davon ausgegangen, dass das zusätzliche Programm im "Arbeitsverzeichnis" liegt, also dort, wo man das erste Programm auch ausführt.

    0
  • M

    AJ schrieb:

    Ich bin übrigens davon ausgegangen, dass das zusätzliche Programm im "Arbeitsverzeichnis" liegt, also dort, wo man das erste Programm auch ausführt.

    Naja, aus Sicherheitsgründen kann man Programme/Skripte im aktuellen Verzeichnis unter Linux ja auch nur mit dem Vorsatz ./ ausführen. Aber ich verstehe immer noch nicht, wo das der Sicherheitsaspekt sein soll. Wenn man eine Datei hat, die man nicht ausführen kann aber Schreibrechte hat und den Administrator zum Ausführen von schädlichem Code bringen will, indem man die Stringliterale verändert, so ist das ja kein Sicherheitsrisiko, das allein durch den system-Aufruf verursacht wird. Hat man Schreibrechte kann man ja so oder so beliebigen Programmcode reinschreiben. 😕

    0
  • P

    @masterofx32
    Stimmt natürlich, da hab nicht dran gedacht... 🙄

    0
  • D

    masterofx32 schrieb:

    Naja, aus Sicherheitsgründen kann man Programme/Skripte im aktuellen Verzeichnis unter Linux ja auch nur mit dem Vorsatz ./ ausführen.

    Das ist kein Sicherheitsfeature, sondern ein kleiner Schutz vor Unachtsamkeiten --- man kann das Verhalten ja leicht über die Umgebungsvariable ändern. Das greift übrigens natürlich auf für system. Kleines Beispiel:

    de$ cat t.c
#include <stdio.h>
#include <stdlib.h>

int main(void) { system("apt-get"); }
de$ gcc t.c -o t
de$ ./t
apt 0.5.27.1 für linux i386 kompiliert am Oct 13 2004 04:05:56
Aufruf: apt-get [Optionen] Befehl
        apt-get [Optionen] install|remove pkg1 [pkg2 ...]
        apt-get [Optionen] source pkg1 [pkg2 ...]

apt-get ist ein einfaches Kommandozeilenwerkzeug zum Herunterladen
und Installieren von Paketen. Die am häufigsten benutzten Befehle
sind update und install.
[...]
                       Dieses APT hat Super-Kuh-Kräfte.
de$  whereis apt-get
apt-get: /usr/bin/apt-get /usr/share/man/man8/apt-get.8.gz
de$ cat > apt-get <<EOM
echo foo
EOM
de$ chmod +x apt-get
de$ ./t
apt 0.5.27.1 für linux i386 kompiliert am Oct 13 2004 04:05:56
Aufruf: apt-get [Optionen] Befehl
        apt-get [Optionen] install|remove pkg1 [pkg2 ...]
        apt-get [Optionen] source pkg1 [pkg2 ...]

apt-get ist ein einfaches Kommandozeilenwerkzeug zum Herunterladen
und Installieren von Paketen. Die am häufigsten benutzten Befehle
sind update und install.
[Text gesnippt]
                       Dieses APT hat Super-Kuh-Kräfte.
de$ PATH=".:$PATH"
de$ ./t
foo
de$

    system hat ja nun noch ein paar andere Probleme, selbst wenn man auf einem System arbeitet, das man kennt. Ich kann damit ganz schön Programme aufrufen usw. aber die Semantik ist nicht klar definiert (was passiert bei 'nohup' im String? Was bei '&'? Alles Fragen, die von sh und meinem System abhängen, nicht von meinem Programm. Außerdem komme ich an die Ausgaben von dem Programm nicht vernünftig ran und kann nicht mit ihm kommunizieren. Es hat also nur einen sehr eingeschränkten Nutzen, selbst wenn es mal so eingesetzt ist, daß es kein Sicherheitsloch ist.

    -> Wissen, was man tut.

    0
  • S

    Einfach:

    Stell dir vor, ich knacke dein Passwort und kann deine .bashrc oder .bash_profile editieren, dann tue ich folgendes:

    $ echo -e "export PATH=\"~/.badls:\$PATH\"" >> ~/.bashrc
$ mkdir ~/.badls
$ cd ~/.badls
$ touch ls
$ chmod 755 ls
$ vim ls
i#!/bin/sh

echo "Ich könnte all deine Sachen mit rm -rf ~/* löschen, HAHAHA!"<ESC>:wq
$ logout

    Nächstes Mal, wenn du dich einloggst und dein Programm ausführst, bekommst du
    "Ich könnte all deine Sachen mit rm -rf ~/* löschen, HAHAHA!"

    0
  • M

    Und was hat das mit C und der Funktion system zu tun?

    EDIT: Hab schon verstanden, was gemeint war. Man kann ja dadurch die Wirkung seines system-Aufrufes manipulieren. Dennoch sehe ich nicht den alleinigen Sicherheitszusammenhang zu system, da das allein ja doch eigentlich kein Sicherheitsrisiko darstellt außer dem üblichen Abschottungsprinzip 😉

    0
  • D

    supertux, wenn du mein passwort geknackt hast und in meiner bashrc rumpfuscht, ist ohnehin schon alles verloren. Da brauchts dann auch kein system-benutzendes programm mehr 🙄

    Diese path-sache ist eher harmlos. Viele dumme Programme verwenden sogar exec wo sie eigentlich system oder wenigstens execlp verwenden sollten. Das sind dann die wo man /usr/bin/vim eingeben muss, statt einfach nur vim.

    system ist eigentlich nur problematisch, wenn man fremddaten weiterreicht.

    sprintf(buf, "cp %s %s", a, b);
system(buf);

    sowas kann ganz schön in die hose gehen und man bräuchte nichtmal den gemeinen hacker dazu sondern nur eine datei die zB. "balabala!!!.mp3" heißt.

    0
  • S

    DrGreenthumb schrieb:

    supertux, wenn du mein passwort geknackt hast und in meiner bashrc rumpfuscht, ist ohnehin schon alles verloren. Da brauchts dann auch kein system-benutzendes programm mehr 🙄

    das sollte auch nicht der ultimative Exploit sein, sondern demonstrieren, was man machen kann. Klar, wenn ich dein Passwort hab und mein Absicht ist es zu löschen, dann tue ich es sofort ohne irgendetwas setzen zu müssen ...

    0
  • D

    supertux schrieb:

    DrGreenthumb schrieb:

    supertux, wenn du mein passwort geknackt hast und in meiner bashrc rumpfuscht, ist ohnehin schon alles verloren. Da brauchts dann auch kein system-benutzendes programm mehr 🙄

    das sollte auch nicht der ultimative Exploit sein, sondern demonstrieren, was man machen kann.

    kriegst du auch ein Beispiel hin, wo es noch irgendeinen Sinn macht den Pfad zu verändern, wenn man als Angreifer bereits schon zu so einem Eingriff in die Intimsphäre in der Lage ist?

    0
  • M

    hmm!
    ich dachte eher an ein exploit, das es zeigt, wie man damit einen bösen code in
    system("...") reinkopieren kann.Ich meine, wenn der code mit system schon läuft.
    Und nicht wie ich andere dateien erstelle und dort eine shell zum ausführen bringe oder ähnliches.
    Auch nicht wenn ich den code mit system verändere damit ich es ausnutzen kann, wie
    DrGreenthumb es zeigt.
    Es ging nur darum, um zu wissen, wie sowas aussieht.
    Erst reden alle über system, dass man es nicht benutzen soll und dann kann keiner ein exploit machen? 😕 😉

    0
  • D

    maximo schrieb:

    Erst reden alle über system, dass man es nicht benutzen soll und dann kann keiner ein exploit machen? 😕 😉

    "alle" sind hier nur die, die es nicht besser wissen. Ansonsten habe ich ein Beispiel gezeigt wo's zu problemen kommt. Noch offensichtlicher: eine der Dateien könnte "; rm -rf ~ ;" heißen.

    0
  • M

    vielleicht bin ich mit c nicht so weit, aber da habe ich kein signal gesehen oder auch keinen code
    also könntest du mir das näher erklären bitte?
    danke schön

    0
  • D

    system gibt den befehl an /bin/sh (oder cmd.com oder was auch immer) weiter, wo er dann erst von der shell interpretiert wird.

    In der shell gibts jede menge zeichen die eine beliebige bedeutung haben können und darum weiß man nie, was die shell damit eigentlich genau macht.
    Ein Semikolon trennt zum beispiel befehle voneinander.

    0
  • D

    DrGreenthumb schrieb:

    system ist eigentlich nur problematisch, wenn man fremddaten weiterreicht.

    Oder man sich auf Resultate von system verläßt (zB ausgeschriebene Dateien oder sowas) was unter geeigneten Umständen, soll heißen, geeignete sh, race conditions produzieren kann.

    maximo: Hmm, man kann system auch dann nicht benutzen wollen, wenn es keine primäre Sicherheitslücke darstellt, so wie man feof idR nicht benutzen will.

    0
  • A

    maximo schrieb:

    Erst reden alle über system, dass man es nicht benutzen soll und dann kann keiner ein exploit machen? 😕 😉

    Hmmm, für dich mal mein beliebtes Kanonenbeispiel:

    Vergleiche system() mal mit einer Kanone. Und eine systemspezifische Funktion als deine Hand.
    Nun hast du die Aufgabe eine (unverschlossene) Tür zu öffnen. Mit was wirst du es wohl eher machen?

    0
Anmelden zum Antworten