Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much

Re^2: security: making sure graphics uploaded by users are safe

by afoken (Chancellor)
on Sep 30, 2009 at 05:32 UTC ( #798237=note: print w/replies, xml ) Need Help??

in reply to Re: security: making sure graphics uploaded by users are safe
in thread security: making sure graphics uploaded by users are safe

A bad guy can embed malicious code into ANY file format, even plain text. The real question is: Will it be executed? If the bad guy can make the victim use an application that does not properly check the file it reads, the malicious code will probably be executed. Microsoft has been taught this lession several times, and still there are exploits based on maliciously modified files. This problem is not limited to Microsoft, but Microsoft's software is often the largest target.

So, what can you do to prevent this happening to your code?


Validate all input. Treat it as malicious until you can mathematically prove that every single byte of input is correct and not malicious. Refuse to work with input that does not pass the validation. Do not try to auto-correct invalid input. Perl's taint mode can be helpful here, but it is only an automatic tool. It can't prevent all attacks, simply because it is limited to a few critical functions. This is better than what many other languages offer, but it is NOT FOOLPROOF.

Passing malicious, unvalidated input to another tool (Image::Magick or any other module or external application) to "make it safe" does not work unless the tool is EXPLICITLY designed to validate the input as described above.

A simple file type detection tool (like file(1)) may be a first step towards validation, but you need to be aware that those tools only test a few bytes of the input to detect the file type. They DO NOT VALIDATE the entire file. For example, the test for the GIF file format just reads the first six bytes and compares them with "GIF87a" and "GIF89a".

What can you do to prevent attacks to the computers of your users?


You can not control them. You don't even know what software they will use. And it is not your responsibility to protect them.

If we talk about a controlled corporate network, things are a little bit different, and your main job should be to educate your users -- the usual drill: Do not open unknown attachments, do not open unrequested attachments, do not open or execute files of unknown origin, and so on. You should also make sure that all software on all systems is regularely updated. You should remove software whose author repeatedly fails to fix security bugs within a short time. Even if the author is Microsoft or Apple.

Firewalls are of little use. They are great to separate the malicious internet from a protected network, and they are fine for this job. But you need to open the firewall to access servers on the other side of the firewall, and there the problem begins: If the firewall inspects the content, it needs to know the exact data format to validate it. All firewalls I've seen just scan for known attack patterns, like a virus scanner. That obviously can not work for new attacks. And it is not the job of the firewall. The application needs to validate its input, not the firewall. There are even attacks that target the content scanner of the firewall.

Virus scanners do not help, for the same reasons. They can only test for known patterns and known behaviours. So, they MUST FAIL for new attacks with new patterns or new behaviours.

I've bypassed several content filters (combined with virus scanners) simply by zipping a problematic file and sending a hex dump of the ZIP file as plain text instead of the original file. I've even prefixed the hex dump with a small perl script that automatically converted the hex dump back into the ZIP file. The last incarnation was a perl script that automatically generated the self-unpacking hex-dump-perl-script text file. I was even prepared to change the hex dump into a format that looked like plain english text.

I've seen malware coming through content filters and virus scanners while at the same time harmless and useful files were blocked. So, no, I do not trust content filters and virus scanners.


Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Replies are listed 'Best First'.
Re^3: security: making sure graphics uploaded by users are safe
by Illuminatus (Curate) on Sep 30, 2009 at 14:25 UTC
    I think you are being a little alarmist here. File formats like jpg and png have no 'executable' aspect to them. They are simply read and displayed. The only way you could make such a file malicious in-and-of-itself would be to exploit some buffer overrun bug within usual rendering software, such as a browser. Since image rendering is pretty basic, this type of situation is highly unlikely to occur.

    The only plausible way to make a jpg/png file malicious is to trick the destination system into thinking that some 'extra' processing is required for the file type. For example, if you modify the registry to change the default behavior associated with double-clicking on a jpg file, so that it is treated differently, then all bets are off. As I originally stated, this requires some other malware execute first.

    Notice I did not include gif format in here. The gif standard allows for animations, which means there is an 'executable' aspect to the file. While I believe the scope of what can be executed within a gif is very limited, I don't know enough about it to say for sure that it could not be hijacked for nefarious purposes


      While you might be right that the OP is being overly cautious, saying that images files should not be dangerous is not quite correct. In the presence of bugs in the viewing software (which the OP cannot control), maliciously crafted images can be a security issue.

      As a relatively paranoid individual, I follow the Security Now! podcast. I've been startled at the number of exploits based on errors in image processing programs reported in the past year.

      During the Aug. 13, 2009 show, we heard about a buffer overflow in the ImageIO library that could result in either application termination or remote code execution. In the Sept. 3, 2009 show, there was discussion of a similar problem in libpng. Over the last year, it seems like there were at least a dozen of these kinds of exploits on one or another OS. (I think all of the majors were represented.)

      That being said, I'm not sure that it's possible to perform a general test to find this kind of thing for an image upload site.

      G. Wade

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://798237]
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others romping around the Monastery: (4)
As of 2023-11-30 04:22 GMT
Find Nodes?
    Voting Booth?

    No recent polls found