Lucene search

K
securityvulnsSecurityvulnsSECURITYVULNS:DOC:2942
HistoryMay 16, 2002 - 12:00 a.m.

Update and comments on the MS02-023 patch, holes still remain

2002-05-1600:00:00
vulners.com
21

The latest cumulative patch from Microsoft,
http://www.microsoft.com/technet/security/bulletin/MS02-023.asp , promises
to eliminate "six newly discovered vulnerabilities", but fails to do so.

First, we find what MS calls "A cross-site scripting vulnerability in a
Local HTML Resource". This is obviously a reference to the dialogArguments
vulnerability, and as such this mislabelling name does not bode well to
begin with. In fact, MS seems to have misunderstood quite a number of issues
surrounding this vulnerability. The first such is found in their list of
mitigating factors:

"A successful attack requires that a user first click on a hyperlink. There
is no way to automate an attack using this vulnerability. "

The above is blatantly untrue, and was repeatedly demonstrated to MS both in
the initial notification phase and when we worked together to reproduce the
issue. Nothing in the world stops this vulnerability from being
automatically exploited.
Another 'mitigating' factor:

"Outlook 98 and 2000 (after installing the Outlook Email Security Update),
Outlook 2002, and Outlook Express 6 all open HTML mail in the Restricted
Sites Zone. As a result, customers using these products would not be at risk
from email-borne attacks. "

The above is merely misinformation on their parts. The Restricted Sites Zone
tries to disable scripting ( a requisite for the dialogArguments
vulnerability ), but many vulnerabilities allow you to circumvent this
setting ( one such listed on /unpatched/ ). As such, you can still script in
the Restricted Sites Zone, and as such "customers using these products" are
still at risk from email-borne attacks.

Aside from these misunderstandings it could appear as though Microsoft is
not actively keeping up with the security community and its publications.
The dialogArguments issue was originally demonstrated with a ressource file
only found in Internet Explorer 6- Shortly after being disclosed GreyMagic
Software highlighted how another ressource file was also vulnerable, which
existed from IE5 and onwards. Microsoft has fixed the vulnerability in IE6
only.

I repeat, IE5 and IE5.5 are still vulnerable.

The same severity rating (Critical) also apply to IE5 and IE5.5, with the
exception that they still remain unpatched. The demonstration was fixed
instead of the vulnerability. If you want to convince yourself about this
(and still use the appareantly unsupported IE5 or IE5.5 browser), try the
examples in GreyMagics appendix to my advisory at
http://sec.greymagic.com/adv/gm001-ax/ .

Next, we find that the cssText vulnerability should be patched. Most of my
systems behave properly and appear to have this vulnerability patched,
though some still allow local file reading. More testing needed, but likely
not a job full done. So far it appears patched.

The "Script within Cookies Reading Cookies" vulnerability also have the same
incorrect 'mitigating' factor as dialogArguments, and claims that

"An attacker would have to entice a user to first click on a hyperlink to
initiate an attempt to exploit this vulnerability. There is no way to
automate an attack that exploits this vulnerability."

Of course, this is also untrue since Internet Explorer comes equipped with a
nice click method on links that a programmer can execute, duplicating an
actual click (
http://msdn.microsoft.com/workshop/author/dhtml/reference/methods/click.asp
). As such, nothing stops anyone from exploiting this vulnerability
automatically.

The "zone spoofing" vulnerability sounds interesting, but I can find no
further details (MS is not exactly full disclosure).

And finally we have two variants of the "Content Disposition" vulnerability.
The first depends on an unknown thirdparty program (your guess is as good as
mine). The second depends on an executable being present, and has a
misinforming mitigating factor:

"Any attempt to exploit the vulnerability requires that the attacker host a
malicious executable on a server accessible to the intended victim. If the
hosting server is unreachable for any reason, such as DNS blocking or the
server being taken down, the attack would fail. "

The above seems to discuss an email-borne attack, and as such there is no
dependancy on external servers. Outlook can easily parse attached
executables through CID: (Content-ID) and as such this mitigating factor is
quite minute since the email itself would act as the hosting server.

Yesterday I hosted a list of 14 publickly known unpatched vulnerabilities,
today I host a list of 12 such. It can still be found at
http://jscript.dk/unpatched/

Just my .02 kroner of comments :)

Regards
Thor Larholm
Jubii A/S - Internet Programmer