Cquirke,
Hi!
What I meant by "post" was to the Microsoft security pages.
OK
I know that Microsoft is not an AV vendor (yet) and that AV vendors list an
outrageous number of new viruses/Trojans/worms a day, but it would be nice
if a Trojan/virus/worm is effecting many machines (don't know what that
number is) and the news media already has articles on the top of the Yahoo
or Google News lists describing the Trojan/virus/worm if Microsoft would at
least acknowledge that such a critter exists (with at least post on the M$
security pages). Seems to be simple courtesy to their customers.
Yes, I see your point - there's a difference between "this flaw could
potentially allow a malicious user to... would have to use a
specially-crafted HTML message that..." and "this flaw is already
exploited by several fast-spreading malware that routinely
boiler-plate the required specially-crafted HTML..."
There are precedents too; MS has referred to specific malware in the
past, e.g. the Concept "prank macro", Lovesan/Blaster etc.
MS needs to be careful not to create the impression that because it
does refer to some new malware threats, that it is a suitable and
exclusionary reference for all new malware threats.
I'm not sure if MS should go there, given that there's already an
industry that covers that territory pretty well - setting a high bar
for MS to reach, and all the while everyone would be screaming that MS
is unfairly invading another 3rd-party turf.
The other reason to avoid listing all the malware that are relevant to
a particular hole, is that it begins an ongoing maintenance commitment
for that article (much as adding 3rd-party links to a web page does).
Imagine if MS had name-checked BubbleBoy in the write-up of the EyeDog
that allowed various malware to break through the tissue-paper that
keeps HTML "messages" safe.
The article would be(come) misleading if left unchanged after Kak
raised the ante from curiosity to wide-spread ITW risk. If the
revision claimed the risk was reasonably safe because Kak doesn't
carry a destructive payload, then an urget revision is required when
BleBla.B (or was it San and Valentine?) start doing the rounds, as
AFAICR that one carries a data-destructive hunter-killer payload.
Also, this sort of name-check is just the sort of ego-stroking
exposure that motivates some malware coders. Show them a page
claiming that a hole is safe because current exploiters don't cause
significant damage, and you'll get a Thus, BleBla.B or variant with a
CIH warhead within weeks to months.
As a general observation, the damage factor tends to go up the more
inexperienced and reputation-hungry the malware coder. So it's not so
much the ground-breakers (Concept, Lovesan, BubbleBoy) that you may
have to worry about, it's the me-toos that follow (Thus, Lovesan+RAT,
BleBla.B). Noting for example that Lovesan offered a few day's grace
before it started whacking the Windows Update server, etc.
It's also a reason to take particularly strong riak-management
strategies against malware that travel in easily-editable source form
(aside from the more obvious mutateability). That's why I prefer to
wall out HTML email, WSH etc. completely where possible.
The high-level scripting languages pose heuristic challenges too,
because what they do is less easy to differentiate from normal
activities. A code file that writes to the MBR is easier to spot and
block heuristically than a script that merely enumerates and writes to
files, which is why the overwriting hunter-killer is so dangerous...
and that hunter-killer logic has been ported from raw code
(Zipped_Files) to MS Office VBA to scripting (LoveLetter etc.)
------------ ----- ---- --- -- - - - -
Our senses are our UI to reality
