2

Recently, one of my website was hacked by someone who uploaded an image (shell.gif) to my server.

I have put server side validation to check file extension + mime type of the image. However, they are still able to upload shell script using gif extension again.

Is there any better way to validate image file programmatically if they have any shell script signature beside two methods i mentioned above?

Improve this question
6
  • How do you know that these checks are even done? Maybe they are bypassing your check using some other exploit (like possible Shellshock).
    – LvB
    Commented May 22, 2015 at 9:31
  • I have custom activity logs. I checked the logs and they actually uploaded an image but this image is actually a virus.
    – William Calvin
    Commented May 22, 2015 at 9:36
  • possible duplicate of How do I deal with a compromised server?
    – Deer Hunter
    Commented May 22, 2015 at 9:44
  • does the log actually log activity, or just intend? How is the file presented to the checker? What parameters are logged?
    – LvB
    Commented May 22, 2015 at 9:48
  • 2
    @DeerHunter I don't think the OP is asking how to deal with the compromise as a whole. He's asking specifically how to better validate an image file.
    – RoraΖ
    Commented May 22, 2015 at 11:37

1 Answer 1

Reset to default
4

The mistake isn't how you validate the file. You should never execute any file that is uploaded. Full stop. If an uploaded file is supposed to be an image, then the only thing you should do with it is present it to an image processing program to be opened.

In a sense, the entire desktop paradigm of guessing the correct program to open a file by looking at its name and/or contents is a terrible idea, and absolutely must not be used by servers, with untrusted data.

Improve this answer
8
  • 3
    Some Image hacks use Overflow exploits in Image libraries. (Exactly what you suggest to do) and than run code.
    – LvB
    Commented May 22, 2015 at 9:49
  • Those are by definition buggy image readers, and should not be used. There was one famously widespread instance of such a buggy reader, but it ought to be long extinct. There are always new exploits discovered, but trusting you image reader is not unreasonable.
    – ddyer
    Commented May 22, 2015 at 10:23
  • I know few image readers that implement there own parser, Most I have seen depend on libraries to do that (like the libnsgif0, libjpeg8 and libgd3 Libraries) Classifying them as 'buggy' is unfounded and shows lack of knowledge of how exploits work and where there a risk.
    – LvB
    Commented May 22, 2015 at 10:28
  • any image reader that can be tricked into running a shell script is buggy.
    – ddyer
    Commented May 22, 2015 at 10:44
  • by that definition all software is buggy ergo no software is buggy (of all are ... none are). It is to 'easy' to just blame the reader. it can be but without a specific version and program its nonsense to say all are. (I remember a bug in the Jpeg libraries included with microsoft products that allowed a overflow injection making all viewers on that platform 'buggy' as you call it.)
    – LvB
    Commented May 22, 2015 at 10:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .