Can you really get a trojan in an image file and if so how will it be executed?

Question

I've just digitized a couple of LPs and needed some cover art. My scanner isn't big enough to scan the album so I searched for and downloaded the images off the net.

When I did so Avast reported that one of them contained the "Win32:Hupigon-ONX" trojan and immediately quarantined it. Not wishing to take any chances I downloaded a different copy which reported as clean.

Now was this just a false positive from Avast or could there really have been a trojan in the jpg?

If there was how would it get executed?

I must admit that this aspect of trojans and viruses has always baffled me. As a software developer I've always checked length of arrays etc. so I don't see why things like buffer overruns should occur. I understand that people do cut corners and make mistakes and if the software is complex enough these errors can slip through.

Answer 1

Exploits in image files take advantage of buffer overrun flaws in the image processing code of the OS. There were several significant such flaws found in Windows' GDI layer a couple of years ago - patches were released long ago but exploit images are still out there either just because they stayed or in the hope that they hit a machine that has not yet been patched.

The usual cause of such a security hole is passing image data between functions on the call stack and not properly checking maximum length of the data. This can be exploited by cleverly constructed data that is over-sized and arrange in such a way that it ends up overwriting code next in the stack frame (overwriting it with other code) or overwriting pointers to code that will be used to call other functions or as the called function returns to is caller (overwriting such a pointer to make it point to the exploit code), or overwriting data in such a way that causes another hole to be exposed. The exact method varies depending on the security hole in question.

Modern CPUs have a protection that stops most of these exploits if the code supports it. This works by the program/library explicitly marking which of its pages are data and which are code - the CPU will then raise an exception if anything in what should be data (such as image data) tries to be executed as code. IIRC Vista and above and recent versions of .Net have had all their libraries re-jigged to support this protection, and it is supported by other OSs too, but this does not stop all such exploits and only works if explicitly turned on (otherwise a lot of old code would break).

Answer 2

I must admit that this aspect of trojans and viruses has always baffled me. As a software developer I've always checked length of arrays etc. so I don't see why things like buffer overruns should occur.

Well, welcome to the real world ;-). Buffer overflows &c. can happen in many languages (especially in those with manual memory management like C), and as developers make mistakes, they do happen.

While normally a buffer overflow will just crash the program (segmentation violation or similar), it may allow an attacker to execute code -> trojan activated.

For example:

http://www.microsoft.com/technet/security/bulletin/MS04-028.mspx

http://secunia.com/advisories/35216/

And for an explanation how this allows code execution:

https://stackoverflow.com/questions/460519/how-are-buffer-overflows-used-to-exploit-computers

Answer 3

There was an exploit that did a buffer overrun on broken JPEG library that could run arbitrary code in 2006. Microsoft released a patch to fix it faster than I'd ever seen them. Your machine almost certainly isn't vulnerable and Hupigon just now generates too many false positives.

http://www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?name=Win32/Hupigon

Answer 4

I must admit that this aspect of trojans and viruses has always baffled me. As a software developer I've always checked length of arrays etc. so I don't see why things like buffer overruns should occur. I understand that people do cut corners and make mistakes and if the software is complex enough these errors can slip through.

Maybe you are checking all of you pointers, arrays, etc. But are you sure, that all programmers of any 3rd-patry library you (might) use (someday) did so, too?

The simplest solution for this would be downloading a file like "image.jpg.exe" or something similiar instead of a real image.

The more advanced ways to infect your PC have already been described here (eg. Buffer Overflow,...)