Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

As far as I can tell, this is not a particularly interesting finding.

Basically, if an application tries to load a library and it isn't there, you can create the library and it will load it.

On Windows, this may be a vulnerability because the program will look in the application directory and current directory for the library, which may not be secured locations.

On Linux, and I believe OSX too, the program will only look in system-specified locations (/lib, /usr/lib, etc) which should be secured at the same or higher level than the applications themselves. If you have access there, you can just overwrite the executable.

http://blogs.msdn.com/b/oldnewthing/archive/2006/05/08/59235...

The paper points out that security software may inspect the binary or its signature. However, such security software must also inspect the libraries; otherwise, one could simply modify a library (e.g. libc) to accomplish the same task with less effort. If the security software is going to inspect the libraries anyways, it can check whether any unauthorized libraries are being loaded.



While OSX will verify a bundle hasn't been tampered with, but (apparently) will scan a folder next to the bundle for shared libraries automatically.

This bypasses a number of security features (code signing, gatekeeper warning, network firewalls) and doesn't require the user click any unusual buttons or type LD_PRELOAD into a terminal.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: