[Qt5-feedback] Fwd: Re: Qt major versions

[Till Oliver Knoll]

Am 08.06.11 12:33, schrieb Thiago Macieira:
> On Wednesday, 8 de June de 2011 10:55:54 Till Oliver Knoll wrote:
>> Well, let me elaborate: on Windows the equivalent of LD_LIBRARY_PATH is
>> PATH. [...]
>
> You know, this was a vector attack on Windows last year. It affected Qt-based
> applications, like VLC.

That was /exactly/ the case I had in mind when writing about "DLL 
injection" using LD_LIBRARY_PATH. ;)

And it did not just affect Qt applications: *lots* of applications where 
affected, IIRC even Microsoft ones ;)

But as you have clarified this won't work when the executable has setuid 
bit set (for privilege escalations, for example).

> The problem is that PATH isn't searched last. After it, Windows searches the
> current directory.

PATH is really searched last, refer again to 
http://msdn.microsoft.com/en-us/library/7d83bc18%28v=vs.80%29.aspx

"1. The directory where the executable module for the current process is 
located.

2. The current directory.

3. The Windows system directory. The GetSystemDirectory function 
retrieves the path of this directory.

4. The Windows directory. The GetWindowsDirectory function retrieves the 
path of this directory.

5. The directories listed in the PATH environment variable."

So it is actually *even worse* than you describe: the Current Directory 
is /normally/ searched already in the 2nd place - even before the System 
and Windows folders! And that can't be stressed enough!

Why on earth should an application search for DLLs in the Current 
Directory? Well, ask Microsoft ;) They realised this was a bad idea as 
well (but I guess due to compatibility reasons cannot undo that "design 
decision").

So there IS a compiler (or was it a registry entry? More likely...) 
switch which moves down the search order of the Current Directory (at 
least after the System and Windows folders, probably even after PATH).

> Here's the attack method:
> 1) user receives "Cool.zip" and unpacks it somewhere
>
> 2) the unpack contains two files: Cool.mp3 and wintab32.dll
>
> 3) the user double-clicks on Cool.mp3, which launches VLC from that directory
>
> Since the system doesn't have a Wacom tablet, so there's no wintab32.dll in
> the system dirs. When Qt probes for the Wacom drivers, it tells the system to
> LoadLibrary("wintab32") and that will be resolved on the current directory.

Exactly - actually this "security flaw" is known since years (but people 
tend to forget ;)

I think it gained "popularity" again last year since apparently loading 
DLLs also works from "network mapped drives" (or even WebDAV mounted 
drives - anything remotely accessible in any case, can't remember - I 
think that was a new feature or so, hence the popularity to exploit it 
again), so if an evil user could make another user click on said 
Cool.mp3 on that remote drive.... BANG!

> ...
>> That would mean there was NO way on Linux/Unix to make sure an executable is
>> picking up a lib from a well-defined location! And simply pointing
>> LD_LIBRARY_PATH to a malicious lib would open that lib instead of the
>> proper one (and maybe that lib would even inherit root access!).
>
> No, you cannot force it. Why do you want to know more than the user? If the
> user has set LD_LIBRARY_PATH, the user has a good reason to.

Well, my idea was to prevent "library injections" from evil users who 
want to become root. But as you have already clarified this is not 
possible, since LD_LIBRARY_PATH is ignored if the executable has root 
privileges.

But originally I did not even know about RUNPATH (just RPATH), and I 
simply wanted to avoid to set LD_LIBRARY_PATH in a startup script (no 
startup script at all), or even worse, have the user set it.

So I changed my application to the more user-friendly RUNPATH ;)

>
> LD_LIBRARY_PATH does *not* affect setuid and setgid executables. The loader
> skips it if geteuid() != getruid().

Right. So no danger in using LD_LIBRARY_PATH :)

Cheers, Oliver