<HTML>
<HEAD>
<TITLE>Re: [Dailydave] Useless fact of the day!</TITLE>
</HEAD>
<BODY>
<FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'>We’ve had a patch for UNMIDL that marked them in the output since the very first one was patched – it might actually be attached to our paper ;)<BR>
<BR>
<BR>
On 1/6/07 12:48 PM, "Dave Aitel" <dave.aitel@gmail.com> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'>I think it's hard to find an MSRPC interface that doesn't have a memory exhaustion bug. Maybe I'll make ImmDBG automatically point them out next week. I guess theoretically we can have ImmDBG shuttle that information off to VisualSploit to automatically write a CANVAS exploit too. Or even better, a SILICA module for it such that you walk into a room and everyone's Windows machines stop working. Good for when you want all the bandwidth at a security convention. :> We don't have the NetrWkstaUserEnum DoS in CANVAS right now - we do use the function though to remotely get logged on users against XP SP2. <BR>
<BR>
It's not an easy bug for Microsoft to fix, but the hilarious thing is that they didn't even bother. I wonder if Vista is vulnerable too - I'm betting yes. :><BR>
<BR>
The other thing I want to try some day is using the LSA Open Handle stuff remotely to just open an infinite number of handles. Every one's so picky in MSDN about always closing the handles to avoid handle leaks, but I'm betting Win32 will be ok even if you don't. And if it's not, hey, no more handles for anyone, anonymously and remotely, which is also fun. :> Maybe someone's already done this and can save us all the trouble? <BR>
<BR>
I dunno. These are all half-day projects, and there are always more interesting bugs to play with in your half-day allotment. Yesterday I spent the half-day of technical work I get a week inside a debugger looking at a strncpy() stack overflow. They still exist! It's like finding a cod off the Massachusetts coast. <BR>
-dave<BR>
<BR>
<BR>
P.S. Why are all of these different CVE numbers. Is CVE about the vulnerability, or the endpoint you can touch it through? There's some sort of rainbow going from a particular class of vulnerabilities through a particular vulnerability through an exploit through a single instance of someone exploiting a machine with an exploit and I sense everyone's naming schemes are just like someone pointing to a color frequency and calling it blue.<BR>
<BR>
<BR>
<BR>
On 1/6/07, <B>Rhys Kidd</B> <rhyskidd@gmail.com> wrote:<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'>RPC memory exhaustion bugs are all the rage atm it would seem,<BR>
hopefully this will provide the traction for MSRC to give it<BR>
priority....<BR>
<BR>
It's also interesting that ISC believe for servers that the current <BR>
UPnP and SPOOLSS bugs are 'Important', whereas the more recent<BR>
NetrWkstaUserEnum() bug is only 'Less Urgent'.<BR>
<BR>
They are pretty much the same, due to unvalidated client input, and in<BR>
fact the NetrWkstaUserEnum() opnum ( through the wkssvc named pipe ) <BR>
is usually bindable over an anonymous NULL session.<BR>
<BR>
- Rhys<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'><BR>
<HR ALIGN=CENTER SIZE="3" WIDTH="95%"></SPAN></FONT><FONT SIZE="2"><FONT FACE="Monaco, Courier New"><SPAN STYLE='font-size:10.0px'>_______________________________________________<BR>
Dailydave mailing list<BR>
Dailydave@lists.immunitysec.com<BR>
<a href="http://lists.immunitysec.com/mailman/listinfo/dailydave">http://lists.immunitysec.com/mailman/listinfo/dailydave</a><BR>
</SPAN></FONT></FONT></BLOCKQUOTE><FONT SIZE="2"><FONT FACE="Monaco, Courier New"><SPAN STYLE='font-size:10.0px'><BR>
<BR>
</SPAN></FONT></FONT><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'>~ Puss<BR>
</SPAN></FONT>
</BODY>
</HTML>