Opening *.txt file is dangerous on Windows | Hacker News Reader

Opening *.txt file is dangerous on Windows

technet.microsoft.com

372 pointsgaika46 comments

The report says this vulnerability is specific to remote network shares and WebDAV. All you have to do is send someone a link to a .txt file on a WebDAV site with a .dll in the same directory, I guess, and they'll be owned... That is pretty awesome.

(As was commented on below, this is identical to an LD_LIBRARY_PATH type exploit on Linux; here is Microsoft's fix as well as an explanation of how it works http://support.microsoft.com/kb/2264107)

Edit: I realize now literally any URL could be a WebDAV site with a text/plain mime type and an exploit DLL in the same dir. So really, every single URL you hit with IE is potentially vulnerable. Have a nice day.

Except that LD_LIBRARY_PATH is not a type of exploit and shouldn't be mentioned as such.

Not in itself, but if you can manage to change it for someone without their awareness you have basically tricked them into running arbitrary (local) code.

The thing is that someone has to execute some code to change it, and if so then malicious code has already been run. By then it is irrelevant if LD_PRELOAD_PATH will be used or not. If I trick you into running 'rm -fR *', does that count as an exploit?

You're absolutely right. Once you've managed to change the preload path, all is lost anyway. Sorry for the confusion.

"The thing is that someone has to execute some code to change it, and if so then malicious code has already been run."

Wrong. You could have at least googled "LD_PRELOAD exploit" before writing this.

Setting LD_PRELOAD does not require running your own code. A real life exploit using LD_PRELOAD took advantage of a weakness in telnet server that let the connecting client export environment variables (yup, even before logging on - no local login required). Write access to a directory visible by telnetd was enough to plant own malicious *.so and then gain root access by exporting LD_PRELOAD via telnet.

So, again, the exploit was that a telnet session was exporting environment variables. LD_PRELOAD_PATH was just a way to take advantage of the telnetd exploit, which might not be the only way. I think that naming it "The LD_PRELOAD_PATH exploit" is just misguiding.

"So, again, the exploit was that a telnet session was exporting environment variables."

No, this was a feature. It had been safe in the days of static libraries, it became a problem when the LD_something family of variables was introduced. Besides, the telnet was just a single vector of introducing the LD_. Other examples concern local privilege escalation by calling suid apps:

http://xorl.wordpress.com/2009/12/01/freebsd-ld_preload-secu...

https://www.kb.cert.org/vuls/id/686403

So there definitely exists a family of exploits that rely on bypassing the usual checks on LD_PRELOAD (and other similar variables) to inject malicious lib into protected code.

> No, this was a feature. It had been safe in the days of static libraries, it became a problem when the LD_something family of variables was introduced.

So? Still a bad design in the telnetd's part. If it wasn't LD_ variables it would have been something else eventually.

> So there definitely exists a family of exploits that rely on bypassing the usual checks on LD_PRELOAD (_and_other_similar_variables_)...

Yes, ofcourse, every issue of environment mishandling would lead the exploiter to utilize LD_PRELOAD, it's the easiest but not the only way. Even without LD_PRELOAD, those bugs would still be a liability for compromising security or normal operation of the system. And just like any part of any OS, ugly bugs will come up now or then.

But it is far too much to compare the casual use of LD_PRELOAD to the brain damaged/stupid handling of dynamically loading libraries Microsoft's Windows have. Actually, LD_PRELOAD is a needed feature (eg. for binary package distribution) that at least provides one layer of protection, it is the opposite of blindly loading any library found in non system folders.

It would be identical to an exploit wherein some distro, for some reason, included . in the default LD_LIBRARY_PATH. Fortunately, I know of none that do this.

I know of no distros that set a default LD_LIBRARY_PATH, period.

Anyone know how this works? How would a plain .txt file load a dll? In any case this looks like it would be difficult to execute since the text file has to be in the same directory as the dll.

Doesn't sound too difficult if you're sending someone an archive with both files in it.

This only works on remote file systems, so you just have to send someone a link to a text file. There would be no indication that a DLL even exists on the target FS.

This apparently works on local directories also. However, either on remote or local, you have to set the working directory before making the "open" action.

Therefore I am not sure a direct link would do the trick (can you change the working dir using an URL and then point to the file ? I m not sure)

Anyway, the DLL does not have to be visible for the trick to work.

Yeah, it has to be "an untrusted remote file system location."

I wonder if Notepad, Wordpad, and maybe Word all call some library (or all have copy/pasted code) that, for whatever reason, looks for a particular DLL in the working folder and executes it?

Not sure how the network drive part would fit into that hypothesis, though.

Windows suffers some famous dain bramage wrt to DLL loading paths: http://unhandledexpression.com/2010/08/23/fixing-the-dll-loa... Basically, even when "safe" DLL loading is turned on, the search path still includes the current directory. I'm guessing that Notepad and friends all look for some (legacy?) DLL that isn't always installed, so if an attacker puts a malicious DLL by its same name in the same path as the file being opened, it'll be loaded and executed. The part about network drives is probably just an assumption about trust boundaries: Microsoft assumes that attacker can't ordinarily put a malicious file in the same local folder that you're opening a text file in, but on a network drive anything goes.

This is all just speculation. I don't code for Windows, and I don't know anything more about this vulnerability than what's stated in the advisory.

The article doesn't mention it, but does anyone know if a requirement to reproduce the vulnerability is that the files be opened in Notepad, Wordpad, or Word? What if you used a third-party editor?

I'm guessing it's actually a bug with Explorer (that is, the actual opening action) than any particular editor, since RTF files are also affected - and doubtlessly many other file types.

It's not Explorer, it's a bug with the Win32 API that loads DLLs. Any program that uses Win32 to load libraries is affected.

Not true, see here:

http://msdn.microsoft.com/en-us/library/ms682586%28v=vs.85%2...

The vulnerability, as I understand it (I did a little research by examining one of the vulnerable applications), since we don't have any actual PoCs to examine:

notepad.exe, like many of the stock Windows apps, uses a bunch of system libraries. One of those system libraries loads shdocvw.dll (an Internet Explorer related component). shdocvw.dll has a delay-load dependency on a library called 'ieshims.dll'. On my computer, when I start notepad.exe, shdocvw.dll tries to load ieshims.dll, and fails, but continues normally.

This means that since ieshims.dll is not found in the app directory or the windows system directory, the search for it will continue all the way into the current working directory, which would make it possible for an exploit to put a payload in an 'ieshims.dll' stored in the current working directory (next to the .txt file), and it would then be loaded.

Assuming my research is correct, this looks like a security vulnerability introduced by one of the Internet Explorer developers, probably for some sort of compatibility purpose. They ignored the fact that IE is used as a component in many system applications, and basically added a vulnerability to every app using shdocvw (there are a lot of them).

It's a generic vulnerability; any program that loads DLLs while the current directory is untrusted has the same problem.

> this looks like it would be difficult to execute since the text file has to be in the same directory as the dll. Seems like a great way to compromise your boss' computer since so many businesses use Windows and networked file systems.

Unless you have an exceptionally paranoid workplace, a much easier way to compromise your boss's computer is just to walk over to it and pop in a livecd after he's gone home for the day.

While I generally agree (even though it's locked doors all the way up for me and there are even easier ways I could compromise machines), it's foolish to disregard remote code execution vulnerabilities just because physical access is not secured.

Oh, I certainly agree. But I only agree because my threat model includes adversaries other than malicious coworkers; particularly, it includes innocent coworkers with malware-infected workstations.

By the way, ten minutes I wrote the grandparent to this comment, a coworker IMed me and asked me to break into his workstation :-). He was working remotely, trying to SSH in, his system had gotten wedged due to what turned out to be disk errors, and he needed me to rescue it.

A bit of digging around suggests it's a DLL preloading attack which somehow convinces the target apps to load the local directory instance of the dll, rather than the system version.

http://www.crn.com/news/security/226900204/microsoft-warns-u...

has a bit of detail, but not specifically about this attack.

I guess it's conceptually similar to doing something like

    export PATH=.:$PATH; cat foo.txt

where 'cat' is an executable file in the current dir.

The actual linux equivalent would probably involve $LD_LIBRARY_PATH ($DYLD_LIBRARY_PATH on OSX, not sure about other unices).

It's a malicious dll, not a malicious txt. It could be any txt file, as long as the dll is in the right place. So it must be something to do with the search path the program uses to look for dlls.

This is called DLL Hijacking and it's a class of flaws that gained prominence on Windows earlier this year. Although I would say that Mandiant discussed the issue first, it was only after HDM practically described the WebDAV and other remote exploit vectors that people started taking it seriously.

https://community.rapid7.com/community/infosec/blog/2010/08/...

http://blogs.msdn.com/b/david_leblanc/archive/2008/02/20/dll...

http://www.n00bz.net/blog/2010/9/15/dll-hijacking-with-metas...

So basically send someone a zip file with a DLL + readme.txt. Most people would avoid the DLL but not think twice about opening the readme. Sounds nasty.

From the "Mitigating Factors" section of CVE-2011-1991:

"For an attack to be successful, a user must visit an untrusted remote file system location or WebDAV share and open a document from this location that is then loaded by a vulnerable application."

Since a ZIP file would extract to a local directory, nothing would happen.

If you extracted the TXT+DLL locally, then you'd be vulnerable, because the problem is that the TXT file is the current directory, and something (WordPad and Notepad, maybe, or Explorer itself) is searching for a DLL that doesn't exist elsewhere on the system, and one of the places searched is the current directory.

All the stuff about WebDav being necessary for a successful attack is because they're assuming someone can't drop a DLL onto your system. But if you unzip a package with a README.txt in the same folder as a DLL you would be vulnerable.

It depends upon the DLLs that the default application uses to show the .txt file to the user: the application has to try to install a DLL that is not in the usual places (i.e., system & windows directories and the application directories). So there is likely to be some speculative DLL lookup going on for apparently well-behaving code to be vulnerable to this.

From the description of the vulnerability, it sounds as if the culprit is some code mounting documents over the network, and so just opening a readme.txt in the local directory will not trigger this.

It remember me of an old stack overflow that I posted just running the command cat: http://seclists.org/bugtraq/1999/Sep/432

I wonder if this was in use (for legitimate uses) by anyone prior to its omg-security-breach discovery, and if their use still works. Quite a few Windows applications look in their folder first for DLLs - checking the loaded-file path could conceivably make the same kind of sense. Or just not accounting for current-directory changes when launching with a file (not entirely sure what the behavior is there).

The description of the vulnerability reminds me a lot about how Stuxnet exploited weaknesses with shortcuts unknowingly loading a malicious dll.

This reminds me of hacking ANSI.SYS escape sequences back in the day. You could create a text file which would be "executed" when someone entered "type readme.txt" at the DOS prompt, by using keyboard remappings and so on.

I remember creating a fairly unsuccessful "text file virus" that would try to copy itself around our school network and reboot people's machines. Good times...

I think this vulnerability is related to WebDAV and SMB, not the DLL/path issue mentioned.

I wonder if this is still an issue when using a 3rd party editor, such as EditPad, etc.

Has this been fixed since this was posted? Either way, the title is inaccurate now. This is only dangerous if you haven't installed the update.

details here:

http://blog.acrossecurity.com/2011/05/anatomy-of-com-server-...

It is not dangerous if you install the update. Why is the headline hyping it as if it's an unpatched zero day?

MISLEADING TITLE!

Isn't everything about Windows considered dangerous anymore? Has there ever been such problem-stricken piece of software?

Clicking "start" is even more dangerous. Once you start, can you stop?

Reply on news.ycombinator.com