Microsoft makes errors in Microsoft Security Advisory (912840)

On Wed, 4 Jan 2006 06:30:07 -0500, "Jim" wrote:

In the most current update to Microsoft's Security Advisory about the WMF
exploit (http://www.microsoft.com/technet/sec...ry/912840.mspx), I
believe that there are several mis-statements that should addressed in the
"Mitigating Factors" section.

I agree. Let's see if pick the same bones of contention...

1) "In a Web-based attack scenario, an attacker would have to host a Web
site that contains a Web page that is used to exploit this vulnerability."

This is false. ...all you have to do is ciew an infected image onscreen to
launch the attack against your PC.

Quite. I see this failure to describe implications all the time, and
I don't know whether it's to prevent feeding the script kiddies
getting ideas, or whether it's genuine poor implication awareness.

If it's the latter, I despair of MS ever "getting it".

2) "Instead, an attacker would have to persuade users to visit the Web site,
typically by getting them to click a link in an e-mail or Instant Messenger
request that takes users to the attacker's Web site." Also not true.

You've got it. Any opportunity to drop a file on the PC is enough -
it will integrate via the exploit, if contacted by an exploitable
surface, such as the shell or possibly a background indexer.

3) "In an e-mail based attack involving the current exploit, customers would
have to click on a link in a malicious e-mail or open an attachment that
exploits the vulnerability." This is not true for any user that reads thier
email in HTML format. HTML emails automatically download and display images
in HTML emails. This means that simply reading an HTML email can infect an
unpatched machine. You don't have to click a thing.

Yup. Clickless attacks may involve remote "graphics" (allowing
real-time site-side changes to avoid av detection) or "graphics"
included within the HTML "message". As the latter are
correctly-MIME'd, even Eudora may not be safe.

4) "At this point, no attachment has been identified in which a user can be
attacked simply by reading mail." This is true and should be differentiated
from #3's mis-statement. An attachment must be clicked to be viewed.

Generally, yes, unless there's an exploit that allows escalation to
clickless attack. For example, Valentine/San from the Kak days
("message" script - .CHM - .EXE attachment, no clicks)

HTML emails (if read in HTML format) load thier images from servers

Or these can be in the message. Different risks; there's more
awareness of the first, so it's usually easier to manage.

Financial Times states "Unlike most attacks, which require victims to
download or execute a suspect file, the new vulnerability makes it possible
for users to infect their computers with spyware or a virus simply by
viewing a web page, e-mail or instant message that contains a contaminated
image." - at
http://news.ft.com/cms/s/0d644d5e-7b...0779e2340.html

The only untruth there is the implication that such clicklessattack
methods are rare; they are not. Many are "by design", too.

5) "This issue is not known to be wormable." Not true. An MSN Messenger
worm has already been reported to be spreading in the wild - see
http://www.f-secure.com/weblog/archi...ve-122005.html and
http://www.viruslist.com/en/weblog?d...92530&return=1.

Worminess just goes about code logic to transmit itself. Any
circumstance that facilitates running the code, allows worminess, and
if the worming out allows the material to arrive in a form that can
run the code, it can be a one-stage life-cycle.

If I've got anything wrong here (I'm not perfect either )....speak up.

All of this considers the exploit as a way of entering the system, in
isolation of other methods of spread. I'm more concerned about
malware that may arrive via other methods, but uses this defect to
trigger itself when attempts are made to remove it - especially if it
can exploit some dumb-ass indexer that runs in the background.

Guess what happens to the host PC if an infected HD is dropped into it
to be scanned - which (in the absence of a proper mOS, such as Bart
CDR) is likely to be a common clean-up method?

The cost of bad design / code is always higher than expected.



---------- ----- ---- --- -- - - - -
Don't pay malware vendors - boycott Sony
---------- ----- ---- --- -- - - - -

On Wed, 4 Jan 2006 17:25:09 -0000, "Mike M"
Galen,

Avoid FUD.

The biggest FUD is confusion between what is possible via this
exploit, and what is currently being done via this exploit.

The only way to assess the first is to have solid information about
this - which would also guide those wanting to exploit the defect.

At present, I suspect most inferences are made with respect to current
ITW ways in which the exploit has been used this far.

And when it comes to the advisory, anyone basing thier risk/impact
assessment on this flawed information is likely to get burned.


So... what do we really know about WMF?

Firstly, we know that BY DESIGN, WMF files can contain code and/or
code redirects. So we already have a safety failure; once again we
have a file that is supposed to be "data" that poses code risk.

Secondly, we suspect (specifically, we are told that MS suspects) that
certain indexing services may be exploitable too, when they grope WMF
files that are "malformed" to exploit the defect.

Thirdly, we know that Windows will not limit itself to the handler
specified as appropriate by the file name extension. In yet another
safety failure design decision, any (graphic, or any at all?) file
containing an WMF header hidden within it will be processed as WMF.

Fourthly, we know that WMF date from the Win3.yuk era, and so are
presumably handled by Win9x as well as NT OS families.


OK; what do we need to know?

Firstly, we need to know whether exploitation is as simple as calling
on the "by design" functionality or whether an additional, possibly
OS-specific, code defect is required.

Secondly, we need to know under what circumstances the design and/or
defect can be exploited. Is it only when cancelling a print job, as
some coverage suggests may apply to the by-design defect? Is it only
when the file is displayed? Or does other handling trigger the
exploit, as is suggested by concernes about indexing services?

Thirdly, whenever we read about av detection, hardware DEP, off-center
mitigations such as unregistering code files other than the WMF
handler, etc. we need to know whether this applies to all possible
exploits of the defect, or just those that are currently in practice.

This applies to vulnerability scanners, too - do these scan for the
ability to interpret WMF files, or the specific code files that do so
in NT family OSs? The difference may matter.


If exploit is as simple as using by-design functionality within WMF
that has been implimented since Win3.yuk, then it's almost certain
that Win9x will be affectable, even if current attack methods are
dependent on something present only in XP or NT.

If a code flaw has to be exploited, then it's likely that Win9x will
not share the same risk as NT, as these are generally two different
code bases. Even if the same generic flaw is present, e.g. an
unchecked buffer, the specific offsets and attack "shape" may differ
according to the engine being attacked, so that attacks aimed at NT
may fail (though attacks crafted for Win9x would work).



---------- ----- ---- --- -- - - - -
Don't pay malware vendors - boycott Sony
---------- ----- ---- --- -- - - - -

Excellent follow-up!

Thanks for your post.

Jim

"cquirke (MVP Windows shell/user)" wrote in
message ...
On Wed, 4 Jan 2006 06:30:07 -0500, "Jim" wrote:

In the most current update to Microsoft's Security Advisory about the WMF
exploit (http://www.microsoft.com/technet/sec...ry/912840.mspx),
I
believe that there are several mis-statements that should addressed in the
"Mitigating Factors" section.

I agree. Let's see if pick the same bones of contention...

1) "In a Web-based attack scenario, an attacker would have to host a Web
site that contains a Web page that is used to exploit this vulnerability."

This is false. ...all you have to do is ciew an infected image onscreen
to
launch the attack against your PC.

Quite. I see this failure to describe implications all the time, and
I don't know whether it's to prevent feeding the script kiddies
getting ideas, or whether it's genuine poor implication awareness.

If it's the latter, I despair of MS ever "getting it".

2) "Instead, an attacker would have to persuade users to visit the Web
site,
typically by getting them to click a link in an e-mail or Instant
Messenger
request that takes users to the attacker's Web site." Also not true.

You've got it. Any opportunity to drop a file on the PC is enough -
it will integrate via the exploit, if contacted by an exploitable
surface, such as the shell or possibly a background indexer.

3) "In an e-mail based attack involving the current exploit, customers
would
have to click on a link in a malicious e-mail or open an attachment that
exploits the vulnerability." This is not true for any user that reads
thier
email in HTML format. HTML emails automatically download and display
images
in HTML emails. This means that simply reading an HTML email can infect
an
unpatched machine. You don't have to click a thing.

Yup. Clickless attacks may involve remote "graphics" (allowing
real-time site-side changes to avoid av detection) or "graphics"
included within the HTML "message". As the latter are
correctly-MIME'd, even Eudora may not be safe.

4) "At this point, no attachment has been identified in which a user can
be
attacked simply by reading mail." This is true and should be
differentiated
from #3's mis-statement. An attachment must be clicked to be viewed.

Generally, yes, unless there's an exploit that allows escalation to
clickless attack. For example, Valentine/San from the Kak days
("message" script - .CHM - .EXE attachment, no clicks)

HTML emails (if read in HTML format) load thier images from servers

Or these can be in the message. Different risks; there's more
awareness of the first, so it's usually easier to manage.

Financial Times states "Unlike most attacks, which require victims to
download or execute a suspect file, the new vulnerability makes it
possible
for users to infect their computers with spyware or a virus simply by
viewing a web page, e-mail or instant message that contains a contaminated
image." - at
http://news.ft.com/cms/s/0d644d5e-7b...0779e2340.html

The only untruth there is the implication that such clicklessattack
methods are rare; they are not. Many are "by design", too.

5) "This issue is not known to be wormable." Not true. An MSN Messenger
worm has already been reported to be spreading in the wild - see
http://www.f-secure.com/weblog/archi...ve-122005.html and
http://www.viruslist.com/en/weblog?d...92530&return=1.

Worminess just goes about code logic to transmit itself. Any
circumstance that facilitates running the code, allows worminess, and
if the worming out allows the material to arrive in a form that can
run the code, it can be a one-stage life-cycle.

If I've got anything wrong here (I'm not perfect either )....speak up.

All of this considers the exploit as a way of entering the system, in
isolation of other methods of spread. I'm more concerned about
malware that may arrive via other methods, but uses this defect to
trigger itself when attempts are made to remove it - especially if it
can exploit some dumb-ass indexer that runs in the background.

Guess what happens to the host PC if an infected HD is dropped into it
to be scanned - which (in the absence of a proper mOS, such as Bart
CDR) is likely to be a common clean-up method?

The cost of bad design / code is always higher than expected.



---------- ----- ---- --- -- - - - -
Don't pay malware vendors - boycott Sony
---------- ----- ---- --- -- - - - -