> Topic > LoadLibrary / LoadLibraryEx Weakness While the 'attack' described in this vuln is quite feasible, it's not confined to windows, nor does it require the use of LoadLibrary(Ex)?. There are in fact two issues here: 1) runtime dynamic linking mechanisms generally make use of a search path. If you have full control of a machine, or the system uses sufficiently lax filesystem priviledged, it's quite easy to place your own dynamic library (a DLL on windows or a .so on *nix) earlier in the search path than a system library. Windows does unfortunately include a process' working directory as the first directory in this search path, which is a weakness somewhat particular to that platform. 2) Process boundaries are not security boundaries. All the processes a user is running have essentially unrestricted access to each other on both Windows and *nix variants. Even without dynamic linking tricks, there are functions on both Windows and *nix platforms that can be used to modify any process a user is running, to achieve essentially any end an attacker desires. On windows, code injection techniques that do not require DLLs are well known and there's plenty of example code in the aether. It's very debatable whether or not this is a bad thing. I feel that there should be some way to enforce security across process boundaries, and doing so could make a lot of security schemes that are trivial to bypass actually be somewhat effective ( DRM being one example ). In a thread on Bugtraq a year ago, a lot of people disagreed for some pretty good reasons. Regardless of where you stand on the issue, this vuln is nothing new, it's just a weakness in how most OSs are designed right now. >I. Malicious DLL can be delivered using the following typical ‘delivery >techniques’: >1. Any un-patched remotely exploitable BOF vulnerability; >2. Any new program users download and run from the Internet; and >3. Any un-patched web-browser vulnerability allowing targeted file saving >within scripts. If any of these are true, you can achieve exactly what OSSec is describing, without having to bother with the complexity of a proxy DLL... OS Security has taken the red pill, but has yet to realize how deep the rabbit hole goes. Cheers, ~x --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.577 / Virus Database: 366 - Release Date: 03/02/2004
