Well, if I pull out the crystal ball, I see two possibilities: 1) Patch goes out, implementing this policy 2) 1% of customers go dark 3) That's a WHOLE BUNCH OF CUSTOMERS WHO DISABLE WINDOWS UPDATE
1) Patch goes out, off by default 2) 0% of customers turn it on 3) That's a MEANINGLESS REGISTRY ENTRY THAT COST A BUNCH OF MONEY TO WRITE Neither look exactly appetizing, and it's not like we (yet) have a clear vulnerability that needs to be addressed. On Fri, Aug 27, 2010 at 10:14 AM, Larry Seltzer <[email protected]>wrote: > #1 in the DLL search list is the directory from which the program was > loaded. How can you have a scenario where CWD is a better choice than that? > Why would it be a good choice DLL sharing? > > > > Here’s another possibility for a Microsoft action. Add a search location > 1.5 specified by the application to Windows. If all the Office apps are > sharing DLLs they can put their apps in Office/sharedDLLs and point to it. > At least we could move forward from here. Microsoft’s choice here dooms us > to this problem for the forseeable future. > > > > *From:* Dan Kaminsky [mailto:[email protected]] > *Sent:* Friday, August 27, 2010 10:08 AM > *To:* Larry Seltzer > *Cc:* [email protected]; [email protected] > > *Subject:* Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive > > > > h0h0h0. There be history, Larry. > > > Short version: Go see how many DLLs exist outside of c:\windows\system32. > Look, ye mighty, and despair when you realize all those apps would be broken > by CWD DLL blocking. > > Longer version: > > Unix has always had the tradition of a system administrator. When it went > consumer, it went straight to package management -- something it could do, > because a) there just aren't that many apps and b) they're mostly open > source, so distros can legally fix things up. > > Windows comes from a different direction: Many, many consumer facing apps, > very few of them open source, users installing for themselves, no package > manager. Among other things, this introduces the concept of: > > Which DLLs should you load? > > Suppose you have ten applications, each using foo.dll. Should they all use > foo.dll from c:\windows\system32? Maybe, maybe not. There are many > possible versions that might be in there, and they might or might not work. > > You can push your version of foo.dll into c:\windows\system32. Great, > you'll work fine, but there's nine other apps you might break. > > You can use a local foo.dll. Now you can have your lib and they can have > theirs. > > Welcome to DLL hell. > > There's been a lot of work in fixing this situation, but not from the > security perspective. I know we're masters of righteous indignation, but I > have to emphasize -- while there's probably an actual vuln somewhere using > this methodology, nothing's been found yet. Changing something with only a > tenuous link to security, with such a massive impact on whether applications > run or not? Yeah, not exactly surprised it's still there. > > On Fri, Aug 27, 2010 at 7:20 AM, Larry Seltzer <[email protected]> > wrote: > > Clearly desktops need to be able to run arbitrary code. That’s what they’re > there for. > > > > Why wouldn’t eliminating the CWD from the DLL search order fix the problem? > I asked Microsoft about this ( > http://blogs.pcmag.com/securitywatch/2010/08/list_of_dll_vulnerability_wind.php) > and they said the obvious answer, that it would break too many customer > installations. And I guess it would break a bunch of them, but there really > isn’t a good reason for anyone to load a DLL from the CWD, is there? > > > > I think they dropped the ball on this at Vista time. They made so many > other changes for security reasons then that forced users and developers to > change practice that this one wouldn’t have been such a big stink. And > they’ve known about the basic problem for 10 years (and should have known > earlier, since it was a UNIX attack beforehand). > > >
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
