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

[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. That is whenever an *.exe is loaded at some point in the "DLL search
> order" it will look into all the directories in PATH for the corresponding
> DLLs. In fact PATH is searched last:
> http://msdn.microsoft.com/en-us/library/7d83bc18(v=vs.80).aspx

You know, this was a vector attack on Windows last year. It affected Qt-based 
applications, like VLC.

The problem is that PATH isn't searched last. After it, Windows searches the 
current directory. So if you manage to trick the user into running the 
application from a different directory, DLLs found in that directory will be 
loaded too.

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. At 
that point, the DLL that the attacker provided can do *anything*.

> The important point is that on Windows DLLs which are located in the
> executable's directory are always taken first, or in other words: a user
> can't simply modify the PATH environment variable and have it point to a
> malicious DLL ("DLL injection").

True, you can't do that for DLLs you provide. But you can do that for DLLs 
that may be missing, like the Wacom DLL that Qt searches for.

In any case, you're trying to protect the user from an attacker that has 
already managed to modify PATH. If the attacker can do that, he can probably 
do a lot worse too.

> (But remember that setting rpath to a relative path such as "." or "./lib"
> is just as bad as having relative paths in LD_LIBRARY_PATH - from a
> security point of view. That is where $ORIGIN comes into play which is
> expanded at runtime to the absolute path of the binary's location, so
> setting $ORIGIN or $ORIGIN/lib as rpath (runpath) is fine.)

Indeed. The counterpart of the Windows attack I listed above is to have 
relative paths or . in $LD_LIBRARY_PATH or RPATH. Some versions of ld.so 
treated an empty field in LD_LIBRARY_PATH as the current dir. E.g.:
	/usr/lib:/usr/local/lib:

(note the trailing colon)

It's quite common to create those when you write in a script:
	LD_LIBRARY_PATH=/some/new/path:$LD_LIBRARY_PATH

If it was empty before, now you have an empty field. Qt Creator 1.3 is affected 
by this.

> 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.

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

However, programs that are setuid and setgid MUST clean up the variables if 
they set the RUID and then execute anything. For example:

1) /bin/setuidprog is setuid root
2) LD_LIBRARY_PATH doesn't apply to it
3) /bin/setuidprog does setuid(getuid()) and then execs /bin/sh
4) When /bin/sh is executed, EUID == RUID == 0, so LD_LIBRARY_PATH is not 
skipped
5) boom! the malicious library is loaded as root.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt.nokia.com/pipermail/qt5-feedback/attachments/20110608/e2265d6b/attachment.bin