Re: A 6% fix from Microsoft Security Bulletin MS03-040 - 828750

From: cquirke (MVP Win9x) (name.goes.here_at_nospam.iafrica.com)
Date: 10/07/03


Date: Tue, 07 Oct 2003 22:13:16 +0200

On Tue, 7 Oct 2003 03:27:02 -0700, "Jim Eshelman"
>"cquirke (MVP Win9x)" <name.goes.here@nospam.iafrica.com> wrote in message

>> The av's Day Zero is measured in days to weeks (i.e. a user who
>> updates whenever the 7-day nag pops up has a Day Zero of 8 days). The
>> spreading time of a pure worm - the kind of exploit that leverages
>> software coding defects - is measured in minutes.

>That's an old model. I'm not talking about that sort of reminder but,
>rather, the kind of feature that at least Norton (and I'm sure others) has
>had for at least a couple of years -- where it automatically checks for
>updates everytime you go online. No setting it for "check every 3 days."

Hm. Trouble is, seems as if the patch is always going to be larger
than the exploiter, so chances are you might lose that race - esp. in
a "worm war" situation. The more acute the need, the more besieged
the update server (just from traffic, if not direct attack) and the
more malware'd PCs there will be "pushing" to you.

The dice are wieghted against us there, and that's why I suggest
looking at ways to fix this now - while the need is not quite obvious
and before a crisis has everyone asking why we dropped the ball.

And even now, I sometimes give up trying to pull updates and try again
the next day (especially when a new engine is out)

>> You cannot disinfect the infosphere, so everyone is exposed the DoS
>> effect of other systems' Lovesan etc. infections. The broken packets
>> will crash RPC, which by duhfault will restart XP (in fact, by
>> duhfault, any system-level crash will restart XP). The malware
>> doesn't have to "infect" the PC or ever exist as a file, which means
>> the role of av never even begins.

>For DoS you are exactly correct. That wasn't the sort of worm that started
>this discussion, but it's certainly a big piece of what we all face today.

Seems it will be a common theme with raw buffer overruns, where the
difference between DoS and infection is in the quality of the coding -
and where an attack on one OS will DoS others that share the hole, but
require different offsets to infect rather than crash.

IOW I expect the Lovesan pattern to become fairly generic.

>It's a judgement call, and my judgement slants more conservatively on this
>than yours. The real pros... sure, they know where to go. But wannabe kids
>are writing some of this malcode, and they aren't always in the loop.

If it's exploitable by script, anyone who is infected has all they
need to spawn variations. Hell, it can even be semi-automated; Anna
Kournukovia was a handful of mouse clicks in a GUI "maker".

>> Because they would not be duplicating what av is doing; av is malware
>> detection, patching is risk management, and the two are complimentary,
>> with very little redundancy/overlap. In particular, the DoS effect of
>> pure worm attacks is unmanageable except via risk management.

>Agreed completely -- when a patch is ready.

Meantime I believe it's prodent to mention crude steps that will
mitigate - such as a reminder that allowing scripts to run without
prompting is in fact conferring programming rights to every web site
you visit (or get re-directed to), etc.

Those of us with good instincts would catch the hint...

>> >...serious discussions in newsgroups and elsewhere of whether MS
>> >should *ever* announce such things. The consensus is that yes,
>> >they should, and that's the path they've taken (and I agree with
>> >the path) -- but it is at least a valid question.

It's not the only source of info - the av reference sites are often
quite explicit as well. It's no good MS being coy if these sites
detail the blow-by-blow attack method.

This is all the old "security by obscurity" debate, which IMO is a
tautology. All security is by obscurity, but what you want is an
obscurity so dense that the strongest computational power cannot break
through within the time frame that the security is to work.

>> It is. But the IMO more valid question is; if you *know* code will
>> always have bugs, why does every home user have to expose these
>> functionalities to the world, on the off-chance there may be a
>> legitimate need for "remote administration"?

>We're on the same side on that one, Chris. I was writing about that one, and
>doing conjoint radio spots with Steve Gibson, and pushing Steve's point of
>view on the matter when every last one of my closest colleagues were calling
>him nuts. But he was exactly right

His mistake was to get too specific - he saw IP-spoofing as the great
satan, and dwelled too much on that (incidentally, note that malware
mail tracking pivots on IP address as From: and ReplyTo: etc. can be
assumed to be spoofed. Join the three dots...)

I've been worried about NTFS becoming a fire hazard, like that
sweatshop that incinerated a number of garment workers as the fire
escapes had been locked by management to stop them "goofing off".

My prediction was that malware would entrnch itself within core code,
or NTFS-specific nooks in the file system (a recent one does exactly
this, using NTFS streams). What is happening instead is that malware
is clobbering the interactive tools we'd used to clean it, even if it
were not embedded in core code.

The trend started with whacking av and spoofing the exefile
association, and it's broadening out to include RegEdit etc.

I'd have done a Gibson if I purely shouted about a specific risk that
doesn't seem to have arisen yet - i.e. infection within core code. So
I keep things general and dig into specifics purely as examples.

>> Software design should have the humility to know that a code flaw
>> could require any subsystem to be walled off at instant notice.
>> Meshing internal control code with networking code in a way that
>> cannot be untangled means that any leak sinks the ship.

>Agreed.

>> IOW if it's crucial to the system, don't inextricably expose it to the
>> network (any network). Bulkheads are your friend.

>Agreed.

Left quoted for emphasis :-)

>---------- ----- ---- --- -- - - - -
   A dog will give its life to save yours.
   A cat will be annoyed by all the yelling and sirens.
>---------- ----- ---- --- -- - - - -



Relevant Pages

  • Re: A 6% fix from Microsoft Security Bulletin MS03-040 - 828750
    ... the update server (just from traffic, if not direct attack) and the ... My prediction was that malware would entrnch itself within core code, ... doesn't seem to have arisen yet - i.e. infection within core code. ... >> network. ...
    (microsoft.public.security.virus)
  • Re: A 6% fix from Microsoft Security Bulletin MS03-040 - 828750
    ... the update server (just from traffic, if not direct attack) and the ... My prediction was that malware would entrnch itself within core code, ... doesn't seem to have arisen yet - i.e. infection within core code. ... >> network. ...
    (microsoft.public.security)
  • Re: A question for the list...
    ... The problems started when attackers would launch an common attack (whom ... > incident response, ... > crisis situation on a neighboring network and shutdown malware. ... > virulent proliferation to extract the costs of infection cleanup? ...
    (Incidents)
  • Re: Holes in my security - advice needed
    ... I will be blamed if there is an attack, infection or theft of corporate and ... It requires very exspensive switches with this ... If management won't support your actions with simple enough explainations ...
    (microsoft.public.windows.server.networking)
  • Re: Publishing Nimda Logs == BAD IDEA
    ... >we will NOT, however, be publishing a comprehensive list of infected ... these worm infection attempts ... by the fact that the sources for such an attack would have already been ... if you have your own lists of infected hosts, ...
    (Vuln-Dev)