[php] CMS en Jpeg virus

[Verwijderd]

Ik gebruik een cms voor mijn klanten, hierbij kunnen ze afbeeldingen toevoegen.
Maar hoe kan ik voorkomen (als dat mogelijk is), dat zij afbeeldingen met een virus toevoegen (verantwoording voor virusscannen ligt bij hunzelf, maar het kan gebeuren)?

Zo kreeg ik een melding van de provider dat 1 bestand besmet was met het
Exploit.JPEG.Comment.FE virus

Iemand enig idee?!

[TeeDee]

de image met GD oid checken? Als je een error krijgt, image deleten.

[GlowMouse]

omzetten naar PNG, daar kunnen voor zover bekend geen virussen inzitten.

[--MeAngry--]

GlowMouse schreef op 22 oktober 2004 @ 12:24:
omzetten naar PNG, daar kunnen voor zover bekend geen virussen inzitten.

Hmm, das wel een goede inderdaad, bestanden die worden gestuurd omzetten naar PNG. Probleem is alleen dat PNG niet echt geschikt is voor foto's, meer voor graphics, en dat het denk ik wat meer processorkracht kost...
Checken met GD zal idd nog het beste zijn, maar doet een besmette JPEG niet ook gewoon Image/JPEG als MIME-type teruggeven?

[Marijn_S]

Je zou met een commandline scanner het bestand handmatig kunnen checken. Omzetten naar een ander bestandsformaat lijkt me in ieder geval niet echt nuttig. PNG is ook geen goed alternatief voor JPG (zeker niet voor foto's).

[.oisyn]

Er bestaat vast wel een tooltje die die jpeg files weer goed maakt, dan hoef je 'm alleen nog maar daar doorheen laten gaan.

--MeAngry-- schreef op 22 oktober 2004 @ 12:26:
maar doet een besmette JPEG niet ook gewoon Image/JPEG als MIME-type teruggeven?

Wat heeft dat ermee te maken

[ Voor 48% gewijzigd door .oisyn op 22-10-2004 12:28 ]

[TRON]

Als je het plaatje weergeeft dmv de gd-lib zit het virus er niet meer in, als ik het goed begrepen heb.

Test het eens uit.

[Verwijderd]

plaatje laten converteren naar png (origineel bewaren), aan de uploader laten zien met de vraag 'is dit juist?', en dan pas bij confermatie de jpg goedkeuren (png verwijderen)..

alleen weet ik niet of de code in de jpeg word genegeerd, en als het wel converteert naar png maar gewoon een verkeerd plaatje returned kan iemand met kwaad in zn zin nog altijd goedkeuren

[Gerco]

Je zou kunnen overwegen om het plaatje met GD gewoon van jpeg naar jpeg te "converteren". Op die manier gaat GD als het goed is het plaatje opnieuw opbouwen met de gegeven data. Als er een virus in je jpeg zou zitten, gaat het die slag niet overleven.

[RM-rf]

ik dacht dat het jpeg-virus gebruikt maakt van de mogelijkheid om in exif-headers comments op te slaan, dat is overigens in de meeste bestandssoorten mogelijk, enkel in windows zat er in een jpeg-leeslibrary een vulnerability, die getrggered kon worden bij het openen van een jpeg-file

PHP kan exif data uitlezen http://de3.php.net/manual/en/ref.exif.php
enkel weet ik niet of het erg eenvoudig is om de exifdata in upgeloadde bestanden te deleten, darvoor moet ik eventjes verder kijken.

edit:
kijk hier eens naar:
http://pel.sourceforge.net/

PEL PHP Exif Library, is wel php5 en gebruik een C libexif library om bekende exif-tags aan te passen, misschien is het daarmee mogelijk.

[ Voor 17% gewijzigd door RM-rf op 22-10-2004 13:55 ]

[Postman]

Tot nu toe lijkt de oplossing van Cerberus de beste oplossing.

Ga maar eens een foto converteren met een 5 mega pixel resolutie. Dit gaat je processorkracht vreten. Niet dat een virusscanner dat ook niet doet, maar toch minder.

En je kunt het ook voor lief nemen. Als je veel gebruikers hebt met grote foto's dan moet je een goede server hebben wil je dat allemaal kunnen uitvoeren. En zoals je al zegt, het risico is voor de gebruikers.

[Postman]

RM-rf schreef op 22 oktober 2004 @ 13:53:
PHP kan exif data uitlezen http://de3.php.net/manual/en/ref.exif.php
enkel weet ik niet of het erg eenvoudig is om de exifdata in upgeloadde bestanden te deleten, darvoor moet ik eventjes verder kijken.

Je kunt ook hiermee controleren of de header ok is. Zo ja, plaats bestand. Zo nee, verwijder de upload en geef een foutmelding.

[RM-rf]

hmm, naar wat ik kan teruglezen zit de exploit niet zozeer binnen de Exif-data, maar is het direkt aan het begin van het COM-field (een comment-veld, dat normaal dan bv. Exifdata kan bevatten)

JPEG Comment sections (COM) allow for the embedding of comment data into a JPEG image. COM sections are marked beginning with 0xFFFE followed by a 16 bit unsigned integer in network byte order, giving the total comment length plus the 2 bytes for the length field. A single JPEG COM section could therefore contain 65533 bytes of invisible data (invisible in the sense that it's not rendered as part of the image.)

Because the JPEG COM field length variable is 2 bytes wide and is itself included in the length value, the minimum value for this field is 2, this implies an empty comment. If the comment length value is set to 1 or 0, a buffer overflow occurs overwriting heap management structures.

The problem is that GDIPlus normalizes the COM length prior to checking it's value. a starting length of 0 becomes -2 after normalization (0xFFFE unsigned). This value is converted to the 32 bit value 0xFFFFFFFE and is eventually passed on to memcpy which attempts to copy ~4G bytes into heap memory.

eEye Digital Security analyzed the bug and found that heap management structures are left in an inconsistent state with execution eventually reaching heap unlink instructions within RTLFreeHeap with EAX pointing to a pointer to data we control and we have direct control of EDX.

In order to test whether a JPEG image is malicious, the following bytes can be searched for in the image:
0xFF 0xFE 0x00 0x00
or
0xFF 0xFE 0x00 0x01

[MisterData]

Gewoon openen met GD en dan weer opslaan? Als het een virus is neem ik aan dat dan de informatie niet wordt meegekopieerd... en anders opslaan als een PNG inderdaad

[Marijn_S]

MisterData schreef op 22 oktober 2004 @ 15:13:
Gewoon openen met GD en dan weer opslaan? Als het een virus is neem ik aan dat dan de informatie niet wordt meegekopieerd... en anders opslaan als een PNG inderdaad

Dat hebben een paar mensen al gezegd...

Wat RM-rf zegt is wel interessant. Ik weet alleen niet hoeveel tijd het kost om de plaatjes te scannen op die paar bytes. Als het niet zulke grote plaatjes zijn over het algemeen moet dat vrij snel kunnen denk ik. Een tooltje zal er vast wel al voor zijn, verwacht alleen niet dat die veel anders doet dan scannen op die paar bytes eigenlijk.

Misschien kan de TS nog even reageren op de voorstellen in dit topic, ben wel benieuwd wat hij kiest.

Edit:
Ik heb het even getest en de manier van RM-rf werkt op een paar probeersels in ieder geval.

Ik heb van de volgende url een Proof-of-concept plaatje (inclusief virus dus) gehaald:
http://www.securityfocus.com/bid/11173/exploit/

PHP:

$img = 'image.jpg';

if ($contents = @file_get_contents($img)) {
    if (strpos($contents, "\xFF\xFE\x00\x00") || 
        strpos($contents, "\xFF\xFE\x00\x01")) {
        echo 'Oh no, a virus!';
    } else {
        echo 'Clean!';
    }
} else {
    echo 'Error reading file...';
}

Ik heb geen idee of het echt waterdicht is maar het is het proberen waard

[ Voor 38% gewijzigd door Marijn_S op 22-10-2004 17:34 ]

[Kuhlie]

Nadeel is dat deze 4 bytes in principe ook in het normale data-deel kunnen voorkomen. Op een bestand van 200 kb is de kans dat dat gebeurt maar 0,0095 %, maar het kan...

[Harm]

Kuhlie schreef op 22 oktober 2004 @ 20:03:
Nadeel is dat deze 4 bytes in principe ook in het normale data-deel kunnen voorkomen. Op een bestand van 200 kb is de kans dat dat gebeurt maar 0,0095 %, maar het kan...

Dan moet je niet het hele plaatje openen, maar alleen de benodigde bytes om je check te doen . Ervan uitgaande dat de check voldoende is, that is.

[Marijn_S]

Kuhlie schreef op 22 oktober 2004 @ 20:03:
Nadeel is dat deze 4 bytes in principe ook in het normale data-deel kunnen voorkomen. Op een bestand van 200 kb is de kans dat dat gebeurt maar 0,0095 %, maar het kan...

Ik heb geen idee of dit uberhaupt in een normaal plaatje voor kan komen. Er staat dat een COM section altijd begint met 0xFFFE. Mij lijkt het dan onwaarschijnlijk dat in normale plaatjes dat voorkomt. Al lijkt het op het eerste gezicht wel goed mogelijk.

Eigenlijk zou de check even getest moeten worden op een hele berg met plaatjes en dan kijken of hij valse meldingen geeft.

[Verwijderd]

Ik heb nog geen actie genomen of een besluit genomen.
Ik wil me eerst wat meer deze materie verdiepen.
Voorlopig scanned de provider de directory met afbeeldingen en repareert beschadigde foto's.

[Verwijderd]

Tja, als de PHP gewoon op een niet-windows server wordt uitgevoerd dan is
er toch niets aan de hand. En anders via Windows update een nieuwe versie van
GDIPLUS.DLL binnenhalen. Eventueel de lengte van het COMMENT veld controleren en patchen. Het is nobel om de verantwoordelijkheid van eindgebruikers over te willen nemen, maar zij dienen zelf voor de security van hun (windows) bakken te zorgen...

[Savantas]

PNG is ook geen goed alternatief voor JPG (zeker niet voor foto's)

Da's dus mooi niet waar, er zijn namelijk 2 varianten van PNG, een 8-bits (sort of GIF) met een kleur transparantie, en een 24-bits, welke weliswaar niet zo goed inpakt als jpeg, maar aan de andere kant wel losless is.
Daarnaast heeft 24bits de mogelijkheid om een alpha-layer als masker te gebruiken, zodat je mooie verlopen kan krijgen met diverse achtergronden. Alleen heb je voor IE een javascriptje nodig om dit zonder grijze achterkant weer te geven.
Maar als je via GD jpegs omzet heb je zoiezo geen transparantie!

Even test gedaan:
JPEG (compressie 8[Pshop]:67%): 79.481 bytes
PNG (max compressie): 370.620 bytes
Origineel (Tiff, no compression): 969.514 bytes

Stukkie groter dan de JPEG dus, maar werkt verder prima!
Ok, als je veel afbeeldingen host gaat het natuurlijk wel in de bitjes lopen