bugtraq - RE: what we REALLY learned from WMF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 5 Jan 2006 21:05:30 -0500
From: "Donald N Kenepp" <don@...eon-central.com>
To: "'Gadi Evron'" <ge@...uxbox.org>, <bugtraq@...urityfocus.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: RE: what we REALLY learned from WMF


Hi Gadi,

  Anyone who releases software to a demanding customer who is in a hurry
knows that quick fixes can sometimes make more problems.  While some
customers are more understanding than others, many customers are already
somewhat disgruntled about there being a problem in the first place.  If you
don't release a fix immediately, the customer is unhappy.  If you rush and
miss something, the customer is unhappy.

  I haven't personally seen any of the problems reported with the unofficial
patch from Ilfak Guilfanov, however, if that patch broke anything people
should be pretty accepting.  He made a great effort to help with the
problem, and he did well in his sacrifice of QA for speed.  The same goes
for any of the other official and unofficial work-arounds that were
published.  The Guilfanov patch was reported as working and pushed by
several top security specialists - some other quick work-arounds didn't do
as well.

  When Microsoft puts out a patch that breaks their OS, people get upset.
They are in a damned if we do and damned if we don't on the subject of
spending time in QA for this; they are the ones with two options neither of
which are pretty.  I personally don't want to see a huge push for them to
rush rather than trying to do it properly.  After a certain point, faster
doesn't get you better.

  Microsoft's security process has improved by leaps and bounds ever since
the XPSP2 push.  I think we all did demand that they push it up a notch, and
we got XPSP2 work and much more default security rather than Longhorn
feature work.  I would rather see them spend time on security and delay
feature releases, so I am glad they decided to change their approach.

  It is possible that they just threw more resources toward getting this
patch out soon in lieu of other deadlines.  It is possible they caved to
public pressure and just released it half-way through QA.  It is possible
that they were trying to fix all their end-of-life and old service-pack
platforms as well for January 10th and we got a patch for the latest
versions five days early instead.  It may simply be that they gave
themselves some headroom on solving the problem.  What if they had promised
a fix by the 1st?  They may have even truly felt the patch could wait until
the 10th.  I wouldn't rush to any conclusion yet.
 
  We will have to wait to see if this is a good fix.  In the meantime, I'd
rather think that this is in line with all the effort Microsoft has been
putting toward security and security process lately.  Give everyone who
worked on this and those still working to get the patch tested and installed
in their own environment, a pat on the back first.

  Sincerely,
    Donald


-----Original Message-----
From: Gadi Evron [mailto:ge@...uxbox.org] 
Sent: Thursday, January 05, 2006 4:54 PM
To: bugtraq@...urityfocus.com
Cc: full-disclosure@...ts.grok.org.uk
Subject: what we REALLY learned from WMF

What we really learn from this all WMF "thingie", is that when Microsoft 
wants to, it can.

Microsoft released the WMF patch ahead of schedule
( http://blogs.securiteam.com/index.php/archives/181 )

Yep, THEY released the PATCH ahead of schedule.

What does that teach us?

There are a few options:
1. When Microsoft wants to, it can.

There was obviously pressure with this 0day, still - most damage out 
there from vulnerabilities is done AFTER Microsoft releases the patch 
and the vulnerability becomes public.

2. Microsoft decided to jump through a few QA tests this time, and 
release a patch.

Why should they be releasing BETA patches?
If they do, maybe they should release BETA patches more often, let those 
who want to - use them. It can probably also shorten the testing period 
considerably.
If this patch is not BETA, but things did just /happen/ to progress more 
swiftly.. than maybe we should re-visit option #1 above.

...

Maybe it's just that we are used to sluggishness. Perhaps it is time we, 
as users and clients, started DEMANDING of Microsoft to push things up a 
notch.

...

Put in the necessary resources, and release patches within days of first 
discovery. I'm willing to live with weeks and months in comparison to 
the year+ that we have seen sometimes. Naturally some problems take 
longer to fix, but you get my drift.

It's just like with false positives. as an industry we are now used to 
them. We don't treat them as bugs, we treat them as an "acceptable level 
of", as I heard Aviram mention a few times.

...

The rest is in my blog entry on the subject:
http://blogs.securiteam.com/index.php/archives/182

	Gadi.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/