On Thu, Aug 26, 2010 at 11:21 AM, Carl Houseman <[email protected]> wrote: >> You forget about all the COTS software designed to run from a network >> share. > > I didn't forget, I read the patch documentation thoroughly. With registry > value=2, if the app is run from a network share then loading DLLs from a > network share is *allowed*.
Hmmm. I just double-checked and that is indeed what it says. Thank you for the correction. My apologies to you. (I remember wondering why "Scenario 1" and "Scenario 2" were so similar. Either I misread it (by far the most likely possibility) or the article was changed (I have seem reports of significant errors in earlier revisions, so this isn't entirely speculation; I still blame myself first though).) Of course, this means CWDIllegalInDllSearch=INT_MAX is more useful than I previously estimated. There's plenty of stuff designed to run off network shares. Hmmm. > But keeping in mind that attackers will look for the vulnerable apps that > are most popular, your ERP software probably isn't at risk unless your > business is being specifically targeted by an attacker. I'm not much worried about our ERP system in particular. But as I understand it, attacks don't necessarily need to target specific applications (although that should improve penetration rates). If certain DLL names are likely to be searched for but not found (which I suspect may be the case), attackers simply have to put copies of their attack DLL with likely names in folders likely to be the CWD, and then wait for the user to run any app which is vulnerable. On Thu, Aug 26, 2010 at 11:31 AM, Carl Houseman <[email protected]> wrote: > If an attacker can get his .DLL into your local CWD, he can probably get his > .EXE to run on your computer as well, so why bother with the .DLL-based > attack. Because placing a file on the system is not the same as executing it. Simply getting an EXE on a computer is not enough; you need to trick the user into running it as well. (Not that that has proven especially difficult.) But now all we need is to place the file; we can let the DLL search path behavior do the rest. Here are some scenarios: (1) Web browser vulnerability is exploited to drop a file in a user profile folder as part of a multi-stage attack. How often do you check your user profile folders to see if an extra DLL has appeared? (2) Inside attacker places DLLs in shared network data locations that an admin might be likely to run a command from. Privilege escalation. (3) Malware puts a DLL on removable media, so that when that media is browsed on another computer and a vulnerable program is in use, the DLL might be loaded. > Point is, the MS patch and reg value=2 has a very slim chance of breaking > something and provides excellent protection against known attack vectors for > locally installed apps. I'm never said one should not deploy CWDIllegalInDllSearch=1|2 just because other options have other impacts. Certainly, it's sensible and common strategy to deploy easier mitigations first before trying harder ones. I expect that's what we'll do here at %WORK%. > ... if you spend > all your time worrying about all future possibilities and not doing something > that takes care of TODAY, well that's just foolish. But if you only worry about what's happening *today* and never worry about the future, that is equally foolish. -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
