[HaBo]

easteregg · 27.09.07, 21:16

heyho

ein forum wo ich öftersmal unterwegs war, hatte nen uploadscript was standardmäßig allesmögliche an code-enthaltenden files rauskickte.
jetzt wurde kürzlich ne shell mit namen shell.php.1 hochgeladen - wieso wird die von der standardconfig vom apache + php5 ausgeführt?
das ist mir vollkommen rätzelhaft.

ich habe das auch mal auf meinem eigenen server getestet - und siehe da - der führt das auch aus. welchen grund gibts dafür?
ist das einfach nur nen bug oder wie muss man das verstehen?

styx-cc · 28.09.07, 14:02

Täte mich auch interessieren, da ich das hier auch nachvollziehen kann...

Code:

Apache/2.2.3 (Ubuntu) PHP/5.2.1 Server at 127.0.0.1 Port 80

MfG

Anzeige

- Anzeige -

Express · 28.09.07, 15:12

*.php.gif geht doch auch, oder?

metax. · 28.09.07, 15:36

Schwer zu sagen, wenn man eure Konfiguration nicht sieht.
ihr solltet daher mal eure /etc/apache(2?)/httpd.conf bzw. apache2.cfg pasten.

**bitmuncher** · 28.09.07, 15:36

Zitat:

Original von Express
*.php.gif geht doch auch, oder?

Nein, das geht nicht, da fuer .gif im Normalfall ein anderer MIME-Type definiert ist und auch der Browser es falsch interpretiert. Man bekommt dann die Meldung

Code:

The image ?http://www.domain.de/test.php.gif? cannot be displayed, because it contains errors.

Die Ursache kann ich mir eigentlich nur wie folgt erklaeren:

Wenn der Apache eine Datei einliest, sucht er im Dateinamen nach dem letzten Punkt im Dateinamen und schaut, ob er eine passende AddType-Direktive fuer den nach dem Punkt folgenden String findet. Ist das nicht der Fall, schaut er (den Dateinamen von hinten aufraeufelnd) nach einem weiteren Punkt. Steht dann hinter diesem ein String, den er als Typ kennt, interpretiert er die Datei entsprechend. Nur wenn keinerlei bekannte "Endung" im Dateinamen vorkommt, wird diese als plaintext ausgegeben.

Ist zwar nur eine Vermutung, aber die einzig logische, die mir gerade einfaellt.

@metax.: Ich habe gerade diverse Konfigurationen und AddType-Definitionen durchprobiert. Es bleibt immer das gleiche.

**Elderan** · 28.09.07, 17:06

Hallo,
hmm die Lücke (?) ist mir neu und unter XAMPP wird eine name.php.dat auch als PHP Datei ausgeführt.

Was lernt man daraus:
Niemals den User erlauben, eine hochgeladen Datei aufzurufen.
Diese müssen in einem geschützten Ordner (deny from all) liegen und mittel PHP-Script kann man die dem User dann zum Download anbieten.
Der direkte Aufruf (anhang/id-1.php.dat) sollte nie möglich sein.

metax. · 28.09.07, 19:49

Hm, ich habe ebenfalls etwas auf meinem Server und etwas lokal getestet und ich komme zu dem gleichen Ergebnis - auch mit anderen Dateitypen.
So wird eine leere Datei "test.jpg.1" vom Apache server mit dem Mime-Typ image/jpeg geliefert.
Im Netz habe ich auch nichts zu diesem (doch sehr komischen) Feature gefunden.
Ich vermute, es hat etwas mit Content-Negotiation zu tun - oder mit dem Feature, mehrsprachige Seiten über Endungen wie index.htm.de anzusprechen.
Jedenfalls würde ich es gerne auf meinem Server abschalten, da es doch ein erhebliches Risiko darstellt, wenn man nicht auf passt.
Falls jemand noch eine Idee hat, nur her damit.

mfg, metax.

easteregg · 28.09.07, 20:03

hm für weiterführende infos wäre ich auch sehr offen

aber ich finds verdammt gefährlich, denn alle uploadscripts die nur mit ner blacklist statt ner whitelist arbeiten sind extremst gefährdet!

28.09.07, 22:12

Huch, das gefällt mir jetzt aber auch nicht. Gerade im Hinblick auf mein Forum. Da habe ich das einbinden von externen Avataren erlaubt.

Wenn nun einer eine [shell.php.gif] da verlinkt, stellt das ganze dann eine Bedrohung dar?

Ich denke zwar nicht, da das ganze ja blos ein src= für ein image Tag ist, aber wer weis...

Gruss
IsNull

Express · 28.09.07, 22:21

Zitat:

Original von IsNull
Huch, das gefällt mir jetzt aber auch nicht. Gerade im Hinblick auf mein Forum. Da habe ich das einbinden von externen Avataren erlaubt.

Wenn nun einer eine [shell.php.gif] da verlinkt, stellt das ganze dann eine Bedrohung dar?

Ich denke zwar nicht, da das ganze ja blos ein src= für ein image Tag ist, aber wer weis...

Gruss
IsNull

Das geht zum Glück nicht, so wie Bitmuncher es erklärt hat

**Elderan** · 29.09.07, 12:57

Hallo,
@IsNull:
Das wird nix.
Entweder wird die shell auf dem fremden Server ausgeführt (_externes_ Avatar) aber höchstwahrscheinlich wird der php Code vom Browser nachgeladen, dieser wird versucht als gif zu interpretieren was in einem Fehler endet.
Dein Server hat damit nix zu tun.

keksinat0r · 29.09.07, 14:39

Dann deaktiviert doch das parsen von .php.* Dateien:

Code:

AddType application/x-httpd-php .php
AddType text/plain .php.

funktioniert wunderbar

/EDIT:
oder erzwingt im AvatarenVerzeichnis zB einen Typ:

Code:

<Location /avatar>
  ForceType image/jpeg
</Location>

MFG - Keks

29.09.07, 15:17

Zitat:

aber höchstwahrscheinlich wird der php Code vom Browser nachgeladen, dieser wird versucht als gif zu interpretieren was in einem Fehler endet.

Habe ich mir auch gedacht, dass dann einfach so ein <img src=../boese/shell.php.gif> im Html auftaucht und nicht interpretiert wird. Wollte aber trotzdem sicher gehen, und hier mal nachfragen. Jedenfalls bin ich jetzt beruhigt

Gruss
IsNull

easteregg · 01.10.07, 20:20

Zitat:

Original von keksinat0r
Dann deaktiviert doch das parsen von .php.* Dateien:

Code:

AddType application/x-httpd-php .php
AddType text/plain .php.

funktioniert wunderbar

/EDIT:
oder erzwingt im AvatarenVerzeichnis zB einen Typ:

Code:

<Location /avatar>
  ForceType image/jpeg
</Location>

MFG - Keks

das is ne gute lösung

danke!

eddy14 · 05.10.07, 00:09

Hallo,
ich kann nur der Erklärung von Bitmuncher zustimmen. Ich kenne diese "Lücke"/Feature schon seit längerer Zeit. Schaut euch diesen Abschnitt

Zitat:

----------------------------------------------------------------------------
--[< Apache - Unknown Mime Type Trouble >]----------------------------------
----------------------------------------------------------------------------
If you have a file "whatever.php" the Apache webserver treats it as a php file.
If you have a file "whatever.jpg" the Apache treats it as an image.
If you have a file "whatever.php.jpg" it is also treated as an image because the
extension is ".jpg" and the Apache knows this mime type..
The information about the extensions and mime types are saved in the ".../conf/mime.types".
What do you expect does the webserver with this file: "whatever.php.tbs".
He handles it as a php file!
The reason for that is that the Apache doesn't find the extension ".tbs" in the list
and therefore choses ".php" as extension.
I think this is wierd and unnecessary but it might help us to place our php code
somewhere at the server.
So keep it in mind!

mal an.
Der Ausschnitt ist aus diesem Tutorial:
http://bright-shadows.net/tutorials/tbs_wiwa.txt

Anzeige

- Anzeige -

27.09.07, 21:16	#1 (permalink)
easteregg Member of Honour Registriert seit: 14.09.07 Likes: 62	*[frage] wieso führt apache .php.123 aus?** Anzeige heyho ein forum wo ich öftersmal unterwegs war, hatte nen uploadscript was standardmäßig allesmögliche an code-enthaltenden files rauskickte. jetzt wurde kürzlich ne shell mit namen shell.php.1 hochgeladen - wieso wird die von der standardconfig vom apache + php5 ausgeführt? das ist mir vollkommen rätzelhaft. ich habe das auch mal auf meinem eigenen server getestet - und siehe da - der führt das auch aus. welchen grund gibts dafür? ist das einfach nur nen bug oder wie muss man das verstehen? __________________ » Flattr mich! - Wenn dir mein Beitrag geholfen hat! « <\| 2 AMD Opterons 2384@ 8x3,2ghz \| Tyan S2915 \| 10GB \| 2x 8800GT \| 8400GS \| Dell 3008WFP + 2x2007FP \|>

28.09.07, 14:02	#2 (permalink)
styx-cc Registriert seit: 29.07.07 Likes: 0	re Täte mich auch interessieren, da ich das hier auch nachvollziehen kann... Code: Apache/2.2.3 (Ubuntu) PHP/5.2.1 Server at 127.0.0.1 Port 80 MfG

28.09.07, 15:36	#4 (permalink)
metax. Registriert seit: 22.01.07 Likes: 10	Schwer zu sagen, wenn man eure Konfiguration nicht sieht. ihr solltet daher mal eure /etc/apache(2?)/httpd.conf bzw. apache2.cfg pasten. __________________ Wenn keiner zuschaut, teile ich heimlich durch Null! Meine Homepage: Planet Metax \| meine Bilder: DeviantArt \| Twitter

28.09.07, 19:49	#7 (permalink)
metax. Registriert seit: 22.01.07 Likes: 10	Hm, ich habe ebenfalls etwas auf meinem Server und etwas lokal getestet und ich komme zu dem gleichen Ergebnis - auch mit anderen Dateitypen. So wird eine leere Datei "test.jpg.1" vom Apache server mit dem Mime-Typ image/jpeg geliefert. Im Netz habe ich auch nichts zu diesem (doch sehr komischen) Feature gefunden. Ich vermute, es hat etwas mit Content-Negotiation zu tun - oder mit dem Feature, mehrsprachige Seiten über Endungen wie index.htm.de anzusprechen. Jedenfalls würde ich es gerne auf meinem Server abschalten, da es doch ein erhebliches Risiko darstellt, wenn man nicht auf passt. Falls jemand noch eine Idee hat, nur her damit. mfg, metax. __________________ Wenn keiner zuschaut, teile ich heimlich durch Null! Meine Homepage: Planet Metax \| meine Bilder: DeviantArt \| Twitter

28.09.07, 20:03	#8 (permalink)
easteregg Member of Honour Themenstarter Registriert seit: 14.09.07 Likes: 62	hm für weiterführende infos wäre ich auch sehr offen aber ich finds verdammt gefährlich, denn alle uploadscripts die nur mit ner blacklist statt ner whitelist arbeiten sind extremst gefährdet! __________________ » Flattr mich! - Wenn dir mein Beitrag geholfen hat! « <\| 2 AMD Opterons 2384@ 8x3,2ghz \| Tyan S2915 \| 10GB \| 2x 8800GT \| 8400GS \| Dell 3008WFP + 2x2007FP \|>

28.09.07, 15:12	#3 (permalink)
Express Registriert seit: 20.04.07 Likes: 0	*.php.gif geht doch auch, oder?

28.09.07, 17:06	#6 (permalink)
Elderan Moderator Registriert seit: 30.03.04 Likes: 14	Hallo, hmm die Lücke (?) ist mir neu und unter XAMPP wird eine name.php.dat auch als PHP Datei ausgeführt. Was lernt man daraus: Niemals den User erlauben, eine hochgeladen Datei aufzurufen. Diese müssen in einem geschützten Ordner (deny from all) liegen und mittel PHP-Script kann man die dem User dann zum Download anbieten. Der direkte Aufruf (anhang/id-1.php.dat) sollte nie möglich sein.

28.09.07, 22:12	#9 (permalink)
IsNull Guest Likes:	Huch, das gefällt mir jetzt aber auch nicht. Gerade im Hinblick auf mein Forum. Da habe ich das einbinden von externen Avataren erlaubt. Wenn nun einer eine [shell.php.gif] da verlinkt, stellt das ganze dann eine Bedrohung dar? Ich denke zwar nicht, da das ganze ja blos ein src= für ein image Tag ist, aber wer weis... Gruss IsNull

29.09.07, 12:57	#11 (permalink)
Elderan Moderator Registriert seit: 30.03.04 Likes: 14	Hallo, @IsNull: Das wird nix. Entweder wird die shell auf dem fremden Server ausgeführt (_externes_ Avatar) aber höchstwahrscheinlich wird der php Code vom Browser nachgeladen, dieser wird versucht als gif zu interpretieren was in einem Fehler endet. Dein Server hat damit nix zu tun.

29.09.07, 14:39	#12 (permalink)
keksinat0r Registriert seit: 06.01.07 Likes: 0	Dann deaktiviert doch das parsen von .php.* Dateien: Code: AddType application/x-httpd-php .php AddType text/plain .php. funktioniert wunderbar /EDIT: oder erzwingt im AvatarenVerzeichnis zB einen Typ: Code: <Location /avatar> ForceType image/jpeg </Location> MFG - Keks

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Ansicht
Linear-Darstellung Zur Hybrid-Darstellung wechseln Zur Baum-Darstellung wechseln

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
Dev C++ führt erstellte .exe datei nicht aus	bad_alloc	Applikationen	2	11.01.08 16:11
USB-Stick Formatierung führt zum Systemabsturz	GuteFrage	Die Problemzone	2	20.09.06 23:35
Klingelton-Anbieter führt "Kindersicherung" ein	shano	News & Ankündigungen	3	21.12.05 16:24
Excel XP führt unbemerkt Code aus	STeFaN	News & Ankündigungen	0	27.05.02 17:51

[HaBo]

[frage] wieso führt apache *.php.123 aus?