Opened by BlackExe at 2007-08-05 00:48
User since
2006-03-29
1520 Artikel
BenutzerIn
2006-03-29
1520 Artikel
BenutzerIn
Fortsetzung vom vorherigen Beitrag... Teil 2 of 4
Folgende Angriffsmöglichkeit existiert z.B. bei den oberen Code. Stell dir vor du hast ein Programm geschrieben das als 'root' läuft. Jetzt möchtest du gerne eine PID Datei schreiben lassen. Und jetzt stell dir vor jemand würde genau zwischen deiner exist überprüfung und deinem open einen symbolischen Link auf /boot/vmlinuz-xxx erstellen. Dein Programm würde also den Kernel überschreiben. Beim nächsten Bott des Rechner würde der Server nicht mehr starten. Hört sich unwahrscheinlich an?
Ein Angreifer kann ein kleines Shellskript schreiben. Dieses Shellskript legt dauern einen symbolischen Link auf die Zieldatei an, und löscht ihn wieder. Die Erfolgschancen steht bei ca 50% das dieser Angriff klappt.
Im Vergleich zu sysopen() ist das allerdiengs etwas anders. Und jetzt kommen wir zu O_EXCL. O_EXCL öffnet eine Datei exclusiv. Das hat nichts mit Locking zu tun. Es bedeutet das eine Datei nur dann erzeugt wird wenn sie nicht existiert. Dieser Schritt ist atomar. Daher hier kann es nicht passieren das in der zwischenzeit ein anderer Prozess dazwischen funkt. Es kann also keine Race Condition auftreten. In diesem Sinne also sicherer.
Ansonsten kannst du mit sysopen() auch Optionen angeben ob die Datei ein symbolischer Link sein darf etc. Ebenfalls alles Atomar. Allerdiengs ist das weniger wichtig, den selben effekt kannst du auch mit open() erreichen, du musst nur eine kleinigkeit beachten.
In diesem Fall hast du auch wieder eine Race Condition, allerdiengs wenn du es so umschreibst dann nicht mehr.
Weiterführung im nächsten Beitrag...
Folgende Angriffsmöglichkeit existiert z.B. bei den oberen Code. Stell dir vor du hast ein Programm geschrieben das als 'root' läuft. Jetzt möchtest du gerne eine PID Datei schreiben lassen. Und jetzt stell dir vor jemand würde genau zwischen deiner exist überprüfung und deinem open einen symbolischen Link auf /boot/vmlinuz-xxx erstellen. Dein Programm würde also den Kernel überschreiben. Beim nächsten Bott des Rechner würde der Server nicht mehr starten. Hört sich unwahrscheinlich an?
Ein Angreifer kann ein kleines Shellskript schreiben. Dieses Shellskript legt dauern einen symbolischen Link auf die Zieldatei an, und löscht ihn wieder. Die Erfolgschancen steht bei ca 50% das dieser Angriff klappt.
Im Vergleich zu sysopen() ist das allerdiengs etwas anders. Und jetzt kommen wir zu O_EXCL. O_EXCL öffnet eine Datei exclusiv. Das hat nichts mit Locking zu tun. Es bedeutet das eine Datei nur dann erzeugt wird wenn sie nicht existiert. Dieser Schritt ist atomar. Daher hier kann es nicht passieren das in der zwischenzeit ein anderer Prozess dazwischen funkt. Es kann also keine Race Condition auftreten. In diesem Sinne also sicherer.
Ansonsten kannst du mit sysopen() auch Optionen angeben ob die Datei ein symbolischer Link sein darf etc. Ebenfalls alles Atomar. Allerdiengs ist das weniger wichtig, den selben effekt kannst du auch mit open() erreichen, du musst nur eine kleinigkeit beachten.
Code (perl): (dl
)
1 2 3 4
if ( -l $filename ) { die "Ich will kein symbolischen link\n"; } open my $fh, '<', $filename or die $!;
In diesem Fall hast du auch wieder eine Race Condition, allerdiengs wenn du es so umschreibst dann nicht mehr.
Code (perl): (dl
)
1 2 3 4
open my $fh, '<', $filename or die $!; if ( -l $fh ) { die "Ich will kein symbolischen link\n"; }
Weiterführung im nächsten Beitrag...
Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de