> -----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
