Domain: milw0rm.org
Stories and comments across the archive that link to milw0rm.org.
Comments · 8
-
Re:::yawn:: nothing to see here, as usual.
The big deal, is Vista, Windows XP SP3 and Server 2003 ARE vulnerable. There's even exploits out in the wild for them.
http://milw0rm.org/exploits/7410
http://milw0rm.org/exploits/7403 -
Re:::yawn:: nothing to see here, as usual.
The big deal, is Vista, Windows XP SP3 and Server 2003 ARE vulnerable. There's even exploits out in the wild for them.
http://milw0rm.org/exploits/7410
http://milw0rm.org/exploits/7403 -
It does NOT need the user to open a file
TY for the random speculation
/.It can be exploited via simple HTML, as detailed at http://milw0rm.org/exploits/7410
-
Re:What about other DNS servers ?
No, you are mistaken; djbdns, MaraDNS (and all other conformant DNS servers, including the patched BIND) are vulnerable to the "ten hour attack", ie., the same attack run for ten hours rather than ten seconds. It just takes a bit longer to work because it has to hit the right port number out of the 65K range.
-
Re:Better security for ActiveX controls
Well, half right. If you want Firefox to use a plugin, you install it in Firefox, not the OS. The *real* reason is that IE has full access to *Any* ActiveX contorl on your machine... realplayer, some demo software you installed 3 years ago, some UI enhancement tool, any and everything regardless if its a browser component or not.
It was another complete moron at m$ that never thought of or ignored this attack vector. Just look at this, encoded for a remote IE hack... Any ActiveX is accessible in IE, the biggest security fuck up of all time.
http://www.milw0rm.org/exploits/5793
muvee Technologies Text-Effect DXT Filter for autoProducer (TextOut.dll v6.0.18.1)
Fontsetting property remote buffer overflow exploit -
Re:LOLI can't imagine he would risk his clients' security by releasing all these bugs
...It may surprise you to learn that some of us pay security consultancies to find bugs in software we use. I don't really care if they then spray them all over milw0rm or keep them quiet for use in their next pen-test; I can make an informed decision on whether to use it, and if so, what sort of controls to include to cover the risk.
-
September 13, not September 15Since this was dated September 17, make that four days ago, not two.
Check the date on the xsec.org page referred to, daxctle2.c. milw0rm 2358 was a re-publication of this, also posted up on 09/13/2006. Republication happened at other exploit advisory sites as well, such as the SecuriTeam(TM) site, where, for some strange reason, the exploit was published twice, redundantly.
The formal vulnerability advisories SA21910 and FrSIRT/ADV-2006-3593, from Secunia and FrSIRT respectively, posted on 09/14/2006, confirmed and extended this, since both groups developed internal versions of daxctle2.c which were reliably effective in compromising fully patched instances of IE6.0 on WXPSP2.
However, both these advisories made it clear that the root cause flaw was in the ActiveX component that was so successfully and famously attacked by HD Moore in July.
Friday's MS advisory, Microsoft Security Advisory (925444), both clarified matters and proposed two workarounds that might be of more use than shutting down ActiveX or fervent prayer, namely:- Disable just the DirectAnimation Path ActiveX Control in the Registry, or
- Modify the ACL of the actual file Daxctle.ocx to be more restrictive.
-
Firefox 1.5.0.3 Loop DoS Exploit