
Opening *.txt file is dangerous on Windows - gaika
http://technet.microsoft.com/en-us/security/bulletin/ms11-071
======
peterwwillis
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.

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

~~~
Kliment
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.

~~~
forcefsck
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?

~~~
praptak
_"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.

~~~
forcefsck
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.

~~~
praptak
_"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...](http://xorl.wordpress.com/2009/12/01/freebsd-ld_preload-security-
bypass/)

<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.

~~~
forcefsck
> 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.

------
jnorthrop
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.

~~~
nollidge
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.

~~~
baddox
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?

~~~
Vivtek
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.

~~~
LeafStorm
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.

~~~
kevingadd
Not true, see here:

[http://msdn.microsoft.com/en-
us/library/ms682586%28v=vs.85%2...](http://msdn.microsoft.com/en-
us/library/ms682586%28v=vs.85%29.aspx#search_order_for_desktop_applications)

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).

------
jmvoodoo
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.

~~~
martey
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.

~~~
SomeCallMeTim
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.

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

------
Groxx
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).

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

------
brs
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...

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

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

------
j_baker
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.

------
ecyrb
details here:

[http://blog.acrossecurity.com/2011/05/anatomy-of-com-
server-...](http://blog.acrossecurity.com/2011/05/anatomy-of-com-server-based-
binary.html)

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

------
lolabloladd32
MISLEADING TITLE!

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

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

