From: SkyLined at edup.tudelft.nl (Berend-Jan Wever)
Subject: Remote DoS IE Memory Access Violation (forwarded from bugtraq)

Tested with IE 6.0.2800.1106, SP1 all patches on Win2k 5.00.2195 SP4, all
patches (up to 11-05-2004)
I explored this bug: it looks like a simple DoS, impact low. Further testing
might provide a way to get more out of this, like remote command execution,
but I doubt it.
Detailed technical comments inline:

----- Original Message ----- 
From: "E.Kellinis" <me@...her.org.uk>
Sent: Friday, May 07, 2004 3:23
> if we want to redirect the page to a file localy to the user/visitor
> we use the file://c:\filename . Now , Instead of using a valid
> drive name  we pass arbitary drive name using hexadecimal values.
>
> e.g. \xff:\filename or we can pass instead of a filename hex values as
well.
>
> This abnormality overwrites 3 registers ECX EDX EDI . When we use
> the  abnormal drive name we control the first 16bits of EDX and EDI.
"It's not a bug, it's a feature!"
The function where the exception occurs is USER32.CharLowerA. There is
nothing "overwriting" registers like a BoF would. The function just sets EDX
to the character used in the drive name (let's say 0xAA) with the sign
extended to 32 bits (in this case that would be 0xFFFFFFAA). Then, if EDX
has any of its higher 16 bits set (in this case it does), it will copy EDX
to EDI and sets ECX to 0xFFFFFFFF (this value is static and uncontrolable).
Next it will do a "rep scasb". This is where things go wrong since there is
no memory mapped at 0xFFFFFFAA. Used in this way, this is just a simple DoS,
causing an exception and crashing IE.

I've tried a few quick hacks to control more of EDX; using javascript's
"unescape()" and utf-8 encoding to create "unicode" drive names. None of
this gave more more control over EDX: it just take the lowest 8 bits of any
value. The function is named CharLowerA, suggesting it only works with ASCII
(8 bit) chars, so unicode encoding won't get you anywhere...
A quick look at the code suggests it's impossible to reach the "rep
scasb" unless EDX > 0x0000FFFF and the only way to make EDX > 0x0000FFFF is
to use the sign extension of 1 byte like the example in origional advisory
does. This will set 0xFFFFFFFF >= EDI > 0xFFFFFF7F when the "rep scasb" is
reached and thus cause an exception, making exploitation for remote command
execution impossible.

> When the webpage with the malicious code loads, the three registers
> are overwritten and the impact of that is to corrupt the registry
> with IE  Entries.
I have not seen this behaviour. Are you confusing "registers" with
"registry" ? If not, where can I find these registry entries and what are
they doing to "corrupt" the registry ?

> The assocation of html/htm pages with internet explorer do not work
> and every shortcut of IE is not loading. Instead there is an error
> popup saying: You cant access this file,path,drive. Permission
> Denied. Noted that you dont have access to the temp directory as well.
IE will detect most exceptions by itself and display the standard "Would you
like to send an error report ?" message. While this message is showing, you
cannot use IE. You must close the popup first. If you load the page from
explorer (eg. by clicking on it) Explorer will spawn an IE process, which
will then crash. Explorer will notice this and display an error, saying you
couldn't open the file. This is true, so nothing weird there. What version
of windows and IE are you running ?

> MSN Messenger is effected by the Memory Access Violation and it is
> crashing immediatelly after you login (sometimes the problem is fixed
> after restarting).
None of this has happened on my system and I crashed IE repeatedly while
testing various options. MSn hasn't behaved weird in any way. What version
of MSN are you using ? Are you talking about restarting your system or just
MSN ?

> Because of the nature of onload inside html tags there is a
> possibility that firewalls wont detect it as Javascript and they will
> let it load. (Mine didn't)
Putting this thing in an IMG tag as src doesn't seem to affect IE at all (no
crash). IFRAMES will crash IE in just the same way A tags will. There's
probably a zillion more ways to get IE to load something from this kind of
url, ask any of the 31337 IE XSS guru's on the list for a few.


Cheers,
SkyLined
-------------- next part --------------
An embedded message was scrubbed...
From: "E.Kellinis" <me@...her.org.uk>
Subject: Remote DoS IE Memory Access Violation
Date: Fri, 7 May 2004 02:23:58 +0100
Size: 5036
Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20040512/ea4751e8/RemoteDoSIEMemoryAccessViolation.eml

Powered by blists - more mailing lists