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.
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.
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?
"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:
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.
(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.