[HaBo]

moinmoin666

Anzeige

Hiho, ich wollte mal fragen wie das geht und mit welchem Programm.

Damit ihr nicht denkt ich spinne oder anderes, hier mal zwei links.

http://www.network-secure.de/content/view/4826/1755/

http://wafful.org/2007/08/04/php-cod...if-image-file/

Diese Technik würde ich nur allzu gerne Lernen*g* PHP ist für mich auch eindeutig die beste Scriptsprache im WWW!

Damit keine Panik ausbricht, erstmal alle Webseiten mit

http://www.code-authors.com/modules....ewtopic&t=3413

absichern, bzw nen bissel ausführlicher:

http://www.scanit.be/uploads/php-file-upload.pdf

Xalon

Nennt sich "HexEditor" ;D
Einfach deinen Code in die .gif, das wars.

Allerdings muss die Datei dann entweder standartmäßig an den Interpreter weitergegeben werden (ist meistens nicht so) oder von einem anderen Script included werden.


mfg,
Xalon

P.S: Falsches Forum

adrian90

wer includiert schon ein Bild?
Ich sehe hier überhaupt keine Sicherheitslücke.

Dass PHP Code so ausgeführt wird ist ja wohl jedem klar und sicher keine Sicherheitslücke.

moinmoin666

hmm stimmt ok, man könnt ja noch die variante nehmen, Dateiendung unkenntlich machen, und dann sowas hochladen wie inject.php.uodweiodiweoje aber da kann man dann gleich ne richtige php Datei nehmen.... na ok, wieso das als so große Sicherheitslücke ausgesprochen worden ist, ist mir jetzt auch nen Rätzel.

naja ich sag nur

<?php
$Bild = "Sicherheitslücke";
include ($Bild);
?>

*g* ist doch immer wieder nett.... per Formular geht es wohl auch nicht... ich bin mal wieder nen bissel am spinnen sorry.

mfg moinmoin666

achja und danke für eure schnellen kompetenten antworten!

Elderan

Hallo,
@adrian90:
Man sollte den Artikel schon lesen bevor man postet.

@moinmoin:
Eigentlich geht man nach so einer Aussage davon aus, dass man schon etwas Erfahrung hat in PHP Programmierung.

Wenn man dann nochmal den Artikel genau liest, wird man feststellen, dass es nicht um <?php include("bild.gif"); ?> geht, sondern um PHP Code der in einem Gif-Bild hinterlegt ist.
Also, lies den Artikel solange durch (und wirklich durch, nicht nur den Anfang), bis du die Problematik verstehst und warum es dort nicht um <?php include("bild.gif"); ?> geht.

moinmoin666

Mein include

<?php include("bild.gif"); ?>

war mehr als scherz gemeint, und wenn DU meinen Post richtig gelsen hättest wüsstest du das bei mir nicht

<?php include("bild.gif"); ?>

steht sonder

<?php include("Sicherheitslücke"); ?>

Mir war auch schon klar(nach dem Post von Xalon) das ich mit einem Hexeditor auch in ein jpg oder was auch immer phpcode reinbekomme, nur das er halt NIE ausgeführt wird!

Ich bitte doch mit deinen Anschuldigungen ein wenig zurücktrittst!

LX

Sicherlich ist include() nicht der einzige Weg, über den der maliziöse Inhalt des Bildes letztendlich zur Wirkung kommt... aber letztendlich muss die Datei auf welchem Wege auch immer in den PHP-Parser wandern. Dabei finde ich den unter Beispiel 8 genannten Weg noch am kritischsten, da der einem nicht sofort bewusst wird, wenn man mit Dateiuploads arbeitet. Warum in aller Welt z.B. jemand einen Webserver betreiben sollte, der Bilddateiendungen an den PHP-Parser leitet, das will mir nu nicht einleuchten

Alles in allem viel zu reißerisch aufgemacht. Von "faktisch alle PHP-Software ist betroffen" und "Uploads kann man im Grunde genommen nach Bekanntwerden dieser Lücke vergessen", wie's am Anfang ja rüber kommt, bleibt am Ende nicht viel übrig *schmunzel*

__________________
"Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better."
- Samuel Beckett

JS BB LX UP

keksinat0r

Wenn wir schon beim ungewollten Einbinden / Ausführen von PHP-Code sind,
denkt dran, dass zB der Apache datei.php.blubb als PHP-Datei parst.

( dazu gibts hier aber scho irgendwo n thema... )

MFG - Keks

metax.

PHP zu Programmieren ist, wie auf einem Drahtseil zu balancieren, während man eine Stange Dynamit mit brennender Lunte in der Hand hält.
Wenn man nicht ganz genau aufpasst, baut man sich ein Scheunentor von Sicherheitslücke ein und fliegt auf die Schnauze. Und früher und später findet jemand einen Exploit, der dich zwingt, deine ganze Anwendung neu zu designen, weil dich sonst auch früher oder später jemand auf dem Server "besuchen" kommt.
Trotzdem macht es irgendwie Spaß

Ne, mal im Ernst:
Eigentlich lebt man damit ganz gut, wenn man eine Grundlegende Regel beachtet:
Never trust user input!

Oder genauer gesagt:
Behandle alles was irgendwie von Benutzer kommen kann (Hochgeladene Dateien, Parameter, der Request an sich), als hätte es die Pest!

Wenn man damit im Hinterkopf programmiert, achtet man eher auf solche Dinge.

mfg, metax.

__________________
Wenn keiner zuschaut, teile ich heimlich durch Null!
Meine Homepage: Planet Metax | meine Bilder: DeviantArt | Twitter

Xalon

Schon mal was von Local-File Inclusion gehört?

Elderan

Halllo,

In dem Artikel geht es nicht im Entferntesten um Include und irgendwelche Sicherheitslücken die man dadurch aufreißt.

Wenn man sich die Beispiele anguckt, wird einem das auch bald klar (setzt natürlich vorraus, dass man den Artikel auch wirklich komplett liest).


Es geht um folgendes:

Man kann in einem Gif-Bild, d.h.keine Datei nur mit .gif-Endung, sondern wirklich ein Bild im Gif-Format, PHP Code einfügen.

Viele Upload-Scripts haben folgende Überprüfung, um zu gucken ob das hochgeladene Bild auch ein Bild ist:
So nun erstell ich ein Gif-Bild und schleuse in dieses PHP Code ein und speicher dieses unter den Dateinamen: gifbild.php ab.

getimagesize() intressiert sich nicht für die Dateiendung, sondern für den MIME-Type des Bildes.
Wenn gifbild.php also ein Gif-Bild ist, wird als MIME-Type 'image/gif' zurückgegeben.

Lade ich diese Datei also hoch, gibt getimagesize als Type 'image/gif' zurück und die Datei gifbild.php wird im Ordner uploads abgespeichert.
Wenn ich direkten Zugriff auf den Upload Ordner habe, was oft der Fall ist, kann ich upload/gifbild.php aufrufen.
Da dies eine .php-Endung besitzt, wird der Inhalt der Datei an den PHP Interpreter gesendet.
Dieser führt den enthalten PHP Code aus und der Angreifer hat alle Möglichkeiten der Welt.

@LX:
Die Datei hat ja die Endung .php, aber den MIME-Type image/gif.
Deswegen passiert dieses die if-Anweisung, wird aber als .gif abgespeichert.

Leider ist es oft so, dass eine Überprüfung aufgrund des MIME-Types durchgeführt wird und nicht aufgrund der Dateiendung.

Allerdings, eine Überprüfung auf Dateiende ist auch nicht sicher. Die einzige Lösung ist, keinen direkten Zugriff auf das Upload-Verzeichnis zu erlauben sondern diesen über einen PHP Script zu steuern, der die Datei dann zum Download anbietet

easteregg

hier wäre es aber vlt. noch eleganter den uploadir zugriff schon zu erlauben, aber dort sämmtliche interpreter zu deaktivieren!

__________________

Harry Boeck

Jeder, der einen Server betreibt, ist selbst verantwortlich, diesen SO zu konfigurieren, daß sich ein geschlossenes, sicheres System ergibt.

Wobei ich hier mit "geschlossen" meine, daß unter keinen Umständen Code von außerhalb dessen, was der Serveradmin als zulässig definiert, ausgeführt werden kann. UND, daß er nur nur das als zulässig definiert, was den Server nicht gefährdet.

Nicht nachvollziehen kann ich das Argument, daß Dateien mit beliebiger Endung, aber "php" irgendwo im Namen zwischen zwei Punkten, als PHP interpretiert werden. In diesem Fall ist die Apache-Konfiguration falsch:

http://harryboeck.dyndns.org/verschiedenes/test.php.txt

Interessant wäre es vielleicht noch, wenn jemand hier WEISS, wie die Konfiguration fehlerhaft aussehen würde (ich wüßte es nicht), so daß man Admins noch einen Hinweis zum gezielten Suchen dieser Lücke geben könnte.

Solange weder diese Fehlkonfiguration noch gravierende Mängel wie includes von beliebigen Fremddateien gegeben sind, ist der angesprochene Fall gegenstandslos.

LX

Das Problem tritt allgemein bei Dateiendungen auf, nicht nur bei *.php.irgendwas. Solange die Endungen beim Apache mit einem MIME-Type assoziiert sind, wird jede folgende Endung die vorherige überschreiben. In HBs Beispiel gehe ich mal davon aus, dass *.txt dem Apache als Endung bekannt und mit dem MIME-Type text/plain assoziiert ist. Würde er die Datei aber test.php.blahblubb nennen (und *.blahblubb nicht mit einem MIME-Type verknüpft sein), dann würde da wieder PHP ausgewertet werden.

Das ganze wurde im Apache-Bugtracker auch behandelt, IMHO mit sehr unbefriedigendem Ausgang (nämlich keinem).

Umgehen kann man das also nur, indem man explizit dem Apache alle Endungen, die geservt werden dürfen, auch bekannt macht und neben dem obligatorischen MIME-Check auch einen Dateiendungs-Check in seine Upload-Formulare einbaut. Alternativ bleibt nur, die Inhalte der Uploadverzeichnisse selbst mit einem Wrapper-Skript zu serven oder PHP-Auswertung für dieses Verzeichnis ganz zu unterbinden.

__________________
"Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better."
- Samuel Beckett

JS BB LX UP

stone.dr

Genau dieses Sicherheitsprinzip nutzte Webspell - das witzige, genau diese "Sicherheitseinstellung" öffnete eine neue Sicherheitslücke.

Man möchte doch nicht, dass plötzlich PHP-Code sichtbar wird