Opening *.txt file is dangerous on Windows(technet.microsoft.com) |
Opening *.txt file is dangerous on Windows(technet.microsoft.com) |
(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.
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
The actual linux equivalent would probably involve $LD_LIBRARY_PATH ($DYLD_LIBRARY_PATH on OSX, not sure about other unices).
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...
Not sure how the network drive part would fit into that hypothesis, though.
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.
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.
"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.
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.
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...
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.
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.
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.
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).
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.
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.