RE: Mailslot bug (MS06-035) vs non-Mailslot bug (CVE-2006-3942)
> -----Original Message-----
> From: Gerardo Richarte [mailto:lists@xxxxxxxxxxxx]
>
> non-Mailslot bug(MS0?-???/CVE-2006-3942)
<snip>
> "Vulnerability details" section to find what I expected:
> NOTHING. Just a general description, as in most advisories
> lately, which can't, in any way, be used to prove or disprove
> the existence of the bug, nor to decide how high in the
> priority list this patch should be put:
<snip>
> . Advisories with almost no technical details are bad: They do not
> provide enough information to let users decide how serious the
> condition is in their specific situation, quite often lead to the
> accidental discovery of new bugs (this is not the first
> time I've seen
<snip>
> pretty much your only choice... Unless somebody comes out
> with a home
> made patch for SRV.SYS. I haven't checked, but I wouldn't
> be surprised
Bravo sir. It is always nice to see another company, or even
researcher[s] for that matter, releasing *useful* details on bugs. How
many more binary diffing videos (ours included) do
vendors/researchers/securitycompanies have to see before everyone can
simply agree that by virtue of having the patch you will find the
vulnerabilities that everyone is so afraid to talk about.
When vendors do not give the correct level of details they leave
everyone in the dark and everyone guessing. So you have things like this
unpatched DoS being discovered, and nothing but confusion for
customers/researchers trying to determine the true risk related to these
flaws. That is why people thought for a while that the DoS was actually
the mailslot bug, and they didn't have any technical details to turn to,
to help them realize that it really was a different bug... So then even
eventually exploits were publicly released for what was then realized to
be an unpatched flaw etc...
It makes matters worse when you find multiple silently fixed
vulnerabilities within a patch and sometimes they have different
dependencies for exploitation such as what features are enabled, service
pack levels, etc... And then your wondering which of the bugs to
correlate to the vendors description of the risk and mitigating factors
and everything else.
And we go through this pain, headache, and annoyance for what reason?
Because of some make believe fear that maybe there might be an exploit
released in 3 hours instead of the typical 4 hours it takes the guys at
places like Core, Immunity, Metasploit, to produce an exploit after a
patch Tuesday or related announcement.
It does not really make any sense... Except for when you look at who
are, "those other people", finding vulnerabilities and releasing
worthless "me too" zero detail advisories. They are the companies ran by
ignorant cowards who are afraid of thinking about security from a
scientific and academic perspective but instead from the perspective of
never wanting to risk rocking the boat for sake of corporate image
because the ignorant masses might portray them as doing the wrong thing.
It seems systemic though across most things these days that people cant
seem to find the will power to do what they know is right, even if the
masses might not yet understand.
So keep on truckin Core Security, Michal Zalewski, and even
Tippingpoint/iDefense. R.I.P. l0pht, RAZOR, @stake.
P.S. Since Gera mentioned about someone coming out with a homemade patch
for this DoS since we are all still waiting around for MS to act... You
can download such a patch from http://research.eeye.com, it is in the
current blog post, courtesy of Derek Soeder. It is obviously
experimental and we recommend checking it out from a research
perspective rather than it being something like our previous third party
patch which was fine to install wherever.
Signed,
Marc Maiffret
Chief Hacking Officer
Founder / CTO
eEye Digital Security
T.949.349.9062
F.949.900.4111
http://eEye.com/Blink - End-Point Vulnerability Prevention
http://eEye.com/Retina - Network Security Scanner
http://eEye.com/Iris - Network Traffic Analyzer
http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities