Die besten Beweise für die Gefährlichkeit/Wirkungsfähigkeit
von Sicherheitslücken und Exploits finden sich sicherlich
bei diversen Newstickern (z.B. http://www.heise.de), wenn über
Eindbrüche in Systeme berichtet wird. Aber dann ist es bereits
zu spät.
Weitere (indirekte) Beweise führen divers Seiten im Internet, die
für Möchte-Gern-Hacker fertige Scripte bereithalten, die bestimmte
Schwachstellen in Implementierungen von Software ausnutzen.
Ich persönlich würde nicht auf einen Beweis warten wollen… ;O)
Lieber gleich das Loch stopfen, auch wenn man dann vielleicht
eine eher akademisch anmutende Schwachstelle zuklebt.
Hier finden sich erweiterte Erklärungen für den Mechnismus des
Exploits:
http://bugs.gentoo.org/show_bug.cgi?id=89946
http://bugs.gentoo.org/show_bug.cgi?id=90626
Gruß, mcc
Der Trick ist bei solchen Angriffen immer der selbe:
Man versucht Daten zu finden (hier wohl für die Variable filename), die das sed-Kommando abschließt, ein Kommando absetzt und dann den Rest des “offiziellen” Kommandos ignoriert.
Hier würden also Dateinamen in etwa folgender Form Schaden anrichten (hab’s nicht ausprobiert, sollte aber irgendwas in dieser Form sein): \|\” ; echo Exploited! ; echo \” (hoffentlich verliert das Forum nichts).
Ähnliche Probleme treten eigentlich überall auf… Benutzereingaben müssen immer mit äußerster Vorsicht behandelt werden (dazu zählen auch bestehende Dateinamen, Einträge in Datenbanken, Eingaben auf Webformularen, etc., einfach alles was ein Benutzer selber irgendwie beeinflussen kann). Dateinamen, URLs, SQL-Statements etc. sollten immer “gequotet” werden, dann hat so ein Angriff keine Chance.
Danke Meino für Deine Hinweise. Da habe ich gleich noch was gelernt, was ich gar nicht wissen wollte! Ich habe die Site in meine URL Sammlung aufgenommen.
Ich bin mir schon darüber im Klaren, wie ein Angriff in grob geht. Den Beweis brauchte ich nur, weil ich mir partout nichts selber basteln konnte, was auch nur den Anschein machte, als würde da was schieflaufen. Und wenn man als Otto Normalo einen Bug-Report irgendwohin sendet, wird zu Recht auch erwartet, daß man ein “Repeat-By” einschließt; nicht etwa, weil Otto Bug und Feature nicht auseinanderhalten kann oder ohne RTFM drauflostippt, bis die Tasten explodieren, sondern um zu sehen, was da genau passiert.
Ich habe also weiter experimentiert. Bei Deinem Beispiel, Tobias, wird alles angezeigt, aber nichts ausgeführt, auch Abwandlungen (falls was verlorenging) verhielten sich so: # in ”, damit alle Zeichen wörtlich genommen werden touch ‘\|\” ; echo Exploited! ; echo \”‘ # Zeile ist mit \ umbrochen echo -e ‘echo “Testdatei”\nexit 2’ \ >\\\|\\\”\ \;\ echo\ Exploited\!\ \;\ echo\ \\\” # die Kommata bei sed, weil Dateiname jetzt | enthält f=’\|\” ; echo Exploited! ; echo \”‘ sed “s,^,$f:,” “$f” # Ergebnis, das angzeigt wird, Kommentarzeichen wegdenken #|” ; echo Exploited! ; echo “:echo “Testdatei” #|” ; echo Exploited! ; echo “:exit 2 # Aufräumen nicht vergessen ;-) rm -f “$f” ; unset f
Aber hier läuft nun etwas wirklich nicht wie erwartet: 8
Hi Aina,
sorry für die verspätete Antwort auf Dein Posting, aber
eine Erkältung hat mich ein paar Tage fester im Griff als
ich die Tastatur :O)
Es freut mich, dass sich mal jemand in eine Sache so verbeißt,
wie Du es gerade tust. Leider grassiert die “Click’n’Install”-
Mentalität zu sehr. Die Komplexität der Welt scheint immer
mehr auf Antworten der [OK][CANCEL]-Kategorie heruntergebrochen
zu werden.
Aber das sind nur politische Statements….
Nun zu Deinen Überlegungen:
Bei den ASCII-Zeichen sind einige dabei, die so “aussehen”,
als würden sie etwas tun.
Beispiel:
echo “\0101” # octal for “A”
erzeugt
A
echo “\0007” # octal for “[BEL]”
erzeugt
(nichts)
aber man hört ein “PING” (wenn xterm/die Shell so eingestellt sind).
“Ausgeführt” in dem Sinne von “Ausführung eines Binaries” wird hier aber
nichts. Sieh’ Dir mal die Ascii-Tabelle (“man ascii” — nein, kein
verd…. “RTFM”-Aufruf, sondern nur, weil man da die Tabelle schön
sehen kann…!) an: Die ersten ASCII-Definitionen enthalten Steuercodes,
wie auch zum Beispiel “carriage return” und “line feed”.
Diese “drucken” nichts, sie veranlassen die Terminal-Emulation/Shell nur,
den Cursor zu “verschieben”. Oder auch “PING” zu machen. Dabei wird aber
kein weiteres Binary geladen und ausgeführt, sondern lediglich eine
Unterfunktion der Terminal-Emulation/Shell ausgeführt.
Oder noch etwas weiter ausgeholt: Wenn Du ein Deinen Environment-Variablen
LS_COLORS definiert hast, werden bei einem “ls -l” bestimmte Dateitypen
(zum Beispiel) rot anstatt schwarz ausgegeben. Dies bewirken auch Steuercodes,
die diesmal aber in den Terminfo/Termcap-Dateien definiert sind.
Wenn Du eine farbige Ausgabe hast, kansst DU mal folgendes porbieren:
#> script log
#> ls -l
#> (^D) # hier Control-D drücken!
#> less log # die darauf folgende Frage mit “y” beantworten
Sieht fürchterlich aus, nicht! Alles voll mit Steuerzeichen. Wenn Du nun
“-r” drückst…TADA…alles farbig! :O) (wieder zurück gehet es auch
mit “-r”.
Mit “-r” wird less angewiesen, die Steuercodes (Escape-Sequenzen) zu
interpretieren. Auch hier wird im eigentlichen Sinne nichts ausgeführt,
was nicht ohnehin schon gestartet wurde…less nämlich.
Also nicht wirklich eine Chance für Hacker.
Ich muss nochmal etwas weiter ausholen…sorry.
“Hacker sein” hat in gewisser Weise etwas Reizvolles: Man lernt Dinge völlig
anders zu benutzen, als in der Weise, für die sie konzpiert worden sind.
Wohlgemerkt: Einbruch in Systeme ist — egal welche intellektuelle Glanztat
dahinter steht — illegal und falsch.
Wenn man seine eigene Software (und dazu zähle ich alles “was etwas bewirkt”)
sicher machen will, denke ich, ist es aber gar nicht verkehrt, in dem Sinne
“Hacker zu werden”, als das man alles tut, um es zu sein…mit dem einen
Unterschied, das Wissen verantwortungsvoll einzusetzen.
Gute Sysadministratorinenn und Sysadministraten auf der einen Seite und
Hacker auf der anderen Seite unterscheiden sich eigentlich nur hauchdünn.
Und das was uns fast “allabendlich” via TV als Hacker serviert wird, wenn es mal
wieder um einen DoS-Angriff, einen Virus oder ähnliches Gesocks geht, ist
nur Presse-Gewäsch. Das sind alles nur Script-Kiddies, die nicht wissen,
was sie tun/anrichten.
Aber ich schweife ab.
Zu stdin/stdout/stderr:
Dieses sind lediglich Filedescriptoren, die beim Starten der Shell (und allen
anderen Programmen) automatisch geöffnet werden.
Sie “tun” nichts. Man kann sie sich als “Verlängerungskabel” vorstellen oder
als “Pipeline-Stücke”.
Beipiel Kommandozeile:
#> ls -l | grep exploit
“Füsikalisch” sieht das so aus:
ls—>(stdout von ls)—->(stdin von grep)—>grep
Das “|” ist quasi nur ein Zeichen für die Shell, alles “aneinanderzureihen”.
Darum führt ein
#> ls -l grep exploit
auch allermeistens zu der Meldung der Shell:
ls: grep: No such file or directory
ls: exploit: No such file or directory
Die Problematik für dieses spezielle Exploit resultiert aus dem “e”-Kommando
von sed. Aus der Info-page von sed:
“`e [COMMAND]’
This command allows one to pipe input from a shell command into
pattern space. Without parameters, the `e’ command executes the
command that is found in pattern space and replaces the pattern
space with the output; a trailing newline is suppressed.
If a parameter is specified, instead, the `e’ command interprets
it as a command and sends its output to the output stream (like
`r’ does). The command can run across multiple lines, all but the
last ending with a back-slash.
In both cases, the results are undefined if the command to be
executed contains a NUL character.”
Der Übeltäter ist hier vielmehr sed als die Shell oder gar
stdout/stdin/stderr.
Noch genereller: Alle Kommandos, die von einem Otto-Normalulser-User
ausgeführt werden und ihm root-Rechte verleihen, damit er Zugriff auf
bestimmte Dateien erhält, müssen SEHR genau angesehen werden.
“passwd” ist so ein Kommando. Es verleiht dem User für die Zeit der
Passwortänderung root-Rechte, damit /etc/passed geändert werden kann.
Wenn jemand einen Weg fände, aus diesem passwd-Käfig auszubrechen…
nicht auszudenken. Aber das Programm ist zu alt und zu klein, um noch
Lücken zu haben.
Aber sieh Dir mal die Geschichte/Changelog-History von “sendmail” an……
Ich hoffe, ich bin nicht zu weit abgeschweift…..
Vielleicht geben Dir diese Links weitere Anregungen:
http://www.happyhacker.org/
(http://www.techbroker.com/)
http://en.wikipedia.org/wiki/Carolyn_Meinel
http://verbosity.wiw.org/issue6/meinel.html
Viel Erfolg!
Meino
Danke für Deine Antwort, Meino!
Mein Vater pflegte zu sagen: nur weil alle in dieselbe Richtung laufen, heißt das noch lange nicht, daß die Richtung stimmt. Aber die Gefahr ist groß abzuschweifen, darum halte ich mich jetzt strikt an den Beispielfall.
8
Hi Aina,
ich werde mich mit Deiner Frage nach meinem Urlaub
an einen Kollegen wenden. Bis dahin bitte ich Dich
um etwas Geduld.
Gruß,
Meino
Hi Aina,
die Arbeit hat mich wieder :-(
Ich habe meinen Kollegen gefragt und er hat Folgendes
erwähnt:
Der Schritt, um mit der Ausführung von Strings herumzu-
tricksen ist das Kommando “eval”:
#> xxx=”|less”
#> echo xxx
|less
#> eval echo `date` $xxx
Nach der letzten Zeile wird “less” ausgeführt.
Dies steht jedoch nicht in direktem Zusammenhang mit der
von Dir beschriebenen Sicherheitslücke. Leider habe ich von
meinem Kollegen auch nich mehr erfahren.
Aber vielleicht kann es Dir als Ansatzpunkt für weitere eigene
Forschungen diesen ?!
Tut mir leid für die etwas mageren Ergebnisse…
Keep hacking!
mcc
PS: Solltest Du etwas Direktes finden, wäre ich Dir für eine Mail
dankbar.