Print

[Gregg]

It's looking that way!

I'm no authority but to me this vulnerability is not a vulnerability. Windows has ALWAYS been this way and it seems to actually pull the exploit off, a person would need to do some guessing. Every security researcher wanna-be is flooding Full Disclosure and Bugtraq lists with a list of vulnerable Apps. My question becomes why are these apps either not including any required DLLs in the apps own folder? Also, DLLs like the mfc family are shared and should be installed to system32 like any other shared system file. This reduces the search path to two known folders regardless of what the current working directory is.

To me this seems to be of no greater risk than we live with day to day with one exception, network shares. I do understand the concern here, but I've only once had to deal with a networked copy of an app and the seat license BS that went with it (the company was to cheap to buy a license for every seat even though all seats used the software the entire work shift, then they complained about slow down of production).

Anyhow, to execute this attack seems the same as placing any other malware on a machine, the user is going to have to click "OK" at some point, how many will? Plenty obviously judging by the size of botnets and the computers of other people that I clean up all the time. My "worst offender" client that refuses to follow my advice is now on Windows 7 which has helped. I have not had to clean up that one yet.

I just don't see the big deal, anyone know more that can clear up the fog?

[Sob]

http://support.microsoft.com/kb/2264107/en-us:

The LoadLibrary function and the LoadLibraryEx function are used to dynamically load DLLs. The following is the DLL search order for these two functions:

   1. The directory from which the application loaded
   2. The system directory
   3. The 16-bit system directory
   4. The Windows directory
   5. The current working directory (CWD)
   6. The directories that are listed in the PATH environment variable

Lets say I have some shared dlls in some common directory which is in PATH. I do it with OpenSSL dlls (and some others too), because I hate every application to have it's own (unnecessary) copy. And I don't put them in %SystemDirectory%, because they feel "too hidden" there (it's just a personal preference). Now lets have some application, e.g. filemanager that dynamically loads these dlls, when instructed to connect to FTP site with SSL. If I'm currently in some completely random directory containing copy of these dlls and if it's application's CWD, then with the above search order, dlls will be loaded from there. And if they contain some exploit, then I'm screwed, but I did nothing wrong or stupid or anything like that.

IMHO it'd be better if steps 5 and 6 in search order were switched with each other. I'll try to enable the fix to feel a little safer. Probably it won't break anything.

[Gregg]

I'd personally like to see #5 removed. I think that is where it is headed and I think that is what is breaking things but to me,  CWD is just to "iffy" to be searching.

I understand your setup, I used to have something similar. Now a days though I have 3 different versions of OpenSSL in use so I can no longer do that. Wget uses whatever version it wants, and we have 0.9.8 in the 2.2 packages and 1.0.0a in the alpha. Dropping 0.9.8 from the 2.2s won't help me cause of wget.

These days however storage is quite cheap. I can get a 1TB HDD for less than the 20MB one I put in my old PS/2 a hundred years ago, so I am not so concerned with multiple copies of DLLs. 

[Sob]

I also wouldn't mind if #5 was removed. But for MS it's too risky. They could set the new CWDIllegalInDllSearch to 0xFFFFFFFF by default (disable searching in CWD) and everyone could simply override it for specific applications if needed. But it could mean many unhappy users, because they don't like to play with these things.

My setup is not really aimed at saving space, but more at having things under control. With many different copies of the same dll, half of them are likely to be seriously outdated, possibly even with security vulnerabilities. I'm not that paranoid to expect an army of evil hackers watching me 24/7 and looking for any weak spot. But the effort on my side is minimal and if nothing else, it feels better, so why not do it. The OpenSSL version switch will break it a little though. The same file name for all versions really wasn't the best idea.

[Gregg]

Thats a good point, but old software using the old dll shouldn't hurt anymore than running old vulnerable software period. Of course, anything using the LoadLibrary that doesn't have an included dll could go haywire badly. I may have to run a filedupe app and see what is going on in my machines.

As far as users not liking to whitelist, they better get used to it, UAC is here to stay. I just wish they would have a do not ask again choice on a per app basis with a db that stored these choices per file checksum. Obviously the administrator of multiple machines would never want to check the box in a multi-user environment, but I would like it for me so I wouldn't have to watch the screen go dark and wait for the stupid prompt to come up every single time I want to open Services say.

[Gregg]

Found this rather interesting

http://seclists.org/fulldisclosure/2010/Sep/22

Now, I won't go as far as to say this issue is false/fud, but it certainly seems harder to pull off than has been stated.
Of course, on Vista/Win7 it's going to be harder than XP

[Sob]

... the screen go dark and wait for the stupid prompt to come up every single time I want to open Services say

Current UAC is ... well, lets say it needs some more work. At first I didn't like it at all (we have different levels of user accounts, so why not just stick with that, right?). On second thought, it's not that bad, the relaxed version in Win7 is probably fine for regular user, as he rarely accesses anything that gives him UAC prompt. And when he does, it's more user friendly to just click "Yes, I really want it" rather than having to manually start it as admin.
But for me there's no way I'm dealing with unnecessary prompt every time I start Regedit. Or elevated Total Commander, because I'm often messing with the system and want/need to have unlimited access everywhere. Or navigate to the depths of netsh command tree and when I want to actually change something, to get "Oh no, you can't do this, 'cause you forgot to run elevated cmd, stupid". Just to name a few. So my UAC quickly got "No thanks" from me. I survived without this kind of protection since Win 3.11, I can easily go on without it now.
On the other hand, it's a pity, because some features are nice and I could use them. UAC Virtualization for example. I'd like to tell Windows to always use it for my web browser to minimize damage when some "just visit our page and you got it" type of exploit is found. And the choice should stay and be used any time the application is run, no matter if started from Start menu or other application running in elevated mode. So yes, give me permanent settings and I'll gladly turn UAC back on.

http://seclists.org/fulldisclosure/2010/Sep/22

IMHO the guy made mistake when he put good dll in the same directory as exe, because there it will be always found by search rule #1. If moved to some directory in PATH, then the bad dll does get loaded, when you launch the app by clicking dhpoc file (and the same directory contains bad dll).

[mario]

I survived without this kind of protection since Win 3.11, I can easily go on without it now.

Yepp you use brain.exe like me.

[Gregg]

I miss 3.11! If I could find my old disks I'd make an old unused box a DOS6/Win3.11 computer. I'd be able to play Strike Commander again and have After Dark too.

Like you I've survived all these years as well.

The reason I do not turn off the UAC is cause I do not like the glaring red shield in the tray always. I think they should have a yellow for it. This is on Vista, IIRC they got rid of that for Win7. UAC is a pain though.

[perindu]

oh my another spammer eh 

[Gregg]

yes, and not a link on the post to be found. I think this one is testing the waters, see if they get burned or not. However, this one is one of the two I pointed out in the other thread. Bye bye Lea, and whatever the other one was, I'll know it when I see it.