41–50 of 52 posts
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...
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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 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://suppor…
Except that LD_LIBRARY_PATH is not a type of exploit and shouldn't be mentioned as such.
Earlier quoted context omitted.
Except that LD_LIBRARY_PATH is not a type of exploit and shouldn't be mentioned as such.
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.
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
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?
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.
Earlier quoted context omitted.
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…