Discussion on:

Weekly malware round-up

.
Take away: This "exploit" claim is completely bogus nonsense.



SANS ISC handler Lorna Hutcheson says (1)(2):

"...its interesting and scary to find a file that acts like a regular gif file, but contains a script exploit..."

-and-

"...The second idea, but completely untested at this point, is that PHP will ignore everything else and just look for its delimiters. Which means, it would be a great method for a RFI attack..."

It's only "interesting and scary" if you DON'T KNOW WHAT YOUR FRIGGIN' TALKING ABOUT.

1. There is no "exploit". It is simply a malformed GIF file that is completely ignored by PHP on the web server.

2. The "second idea" requires that the GIF file be present on the web server AND the web server must be mis-configured to attempt to parse, compile, and execute GIF files.

This is so stupid. My opinion of SANS has dropped a notch.

Nothing to see here. Move along. Move along...



-----------------------------------------------------

(1) Malicious GIF conceals PHP attack (NOT!)
http://www.techworld.com/security/news/index.cfm?RSS&NewsID=9240

(2) PHP Exploit Code in a GIF (NOT!)
http://isc2.sans.org/diary.html?storyid=2997

The article mentions the PHP code as an exploit and not that the GIF image is an exploit. Embedding the PHP code in an image file is a cheeky way to bypass filters and place code on a WebServer. Now, what happens if I do the same for a period of time over a legitimate site and then write a little script that one day renames the files. And suppose I am talking about a major image hosting site... Does not that classify as a threat ?

.
Ok. Let's assume that a tainted GIF file gets uploaded to a web server on a special-purpose image hosting site and it contains some PHP code after the valid GIF data. How exactly is the PHP code going to be executed?

So it takes a little bit of defacing to the main site to get the code executed and thus run the exploit.

Also, with help from Wikipedia , its mentioned that for servers with the PHP configuration flag register_global ON, it is indeed possible to insert location of the malicious file in the URL and execute on the target server. So the exploit : First load the code on the servers via harmless pictures. Then write a little code that changes file names. Execute code. Now does that not qualify as an exploit ?

.
"...Now does that not qualify as an exploit ?..."

No.



If you have register_globals = ON, and you have insecure PHP code already on your website such that your website can be compromised, you have much bigger problems than some embedded PHP code in a GIF file. With that problem on your website, who needs to fool around with embedding PHP code in a GIF file?

The notion that merely embedding PHP code in a GIF file constitutes an exploit or a vulnerability is hogwash. Without a REAL exploit, like the one you describe, the embedded PHP code in a GIF file is completely worthless.

.
Summary

** Apparently it is true that it is possible to hide PHP script (or anything else) at the end of a GIF image file (the tainted GIF).

** By themselves, tainted GIFs are completely benign and not a threat.

** In order for a tainted GIF to be of any use to a hacker, TWO things must occur:

Event #1: The hacker must install the tainted GIF file on the web server.

Event #2: The hacker must break into the web server and install code that accesses the tainted GIF file.

** "Event #1" is not permitted except on certain websites like photobucket.com.

** "Event #2" is impossible on a secure web server.

** If the hacker can perform "Event #2", he really doesn't need the tainted GIF from "Event #1". He can already take over your web server. The real threat is, and has always been, "Event #2".

Thank you for summarizing the scenario. The tainted GIF was found on a major unnamed photo-sharing site. In the present scenario, where the concept of web-APIs is fast catching on, where sufficient programming capabilities are being made available to end-users to access web based features (mash-ups for example), especially when companies are vying to host third party code for greater public penetration, would not the malicious code repositories pose a serious concern. It is the combination of the code in GIF files with the added programming features possible today that in my opinion may pose a threat.

.
"...would not the malicious code repositories pose a serious concern..."

Any code installed and run on the web server is the webmaster's responsibility. If code from a "code repository" contains bugs or security weaknesses, it is his responsibility to find and fix the problems.

As for web APIs: Tainted GIFs don't constitute a problem for the caller or provider of a web API. The protocol between the web servers is typically an XML stream (text) over HTTP. It is the responsibility of each web server to validate the contents of that XML stream before using it. Once again, the webmaster has complete control over this vis-a-vis malware.

If a web server contains a page that displays a tainted GIF hosted on photobucket.com, there is no problem. The web server never touches the tainted GIF. The page is sent to the browser and the browser requests the tainted GIF directly from photobucket.com. The embedded script is ignored by the browser.

I don't LIKE the idea that a GIF file can be made to silently carry something other than just the image. But, it does not concern me either. The webmaster still has complete control over this by controlling the code that he installs on the web server and ensuring the server is secure. If he does that well, there is no problem. If he does not do that well, the web site has a serious problem regardless of tainted GIFs.

Thanks for the explanation, though I would like to permutate on the possibilities of any threat that could take place.