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
> 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
[ reply ]