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

[Thiago Macieira]

On Wednesday, 8 de June de 2011 13:43:01 Konstantin Tokarev wrote:
> 08.06.2011, 12:55, "Till Oliver Knoll" <till.oliver.knoll at gmail.com>:
> > 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!).
> > 
> > Setting LD_LIBRARY_PATH in your own start script would not help: I would
> > simply ignore your script and call the executable directly (or via my
> > own malicious script).
> 
> Right - but Unix systems don't assume that user himself is a potential
> malefactor. So user certainly has a right to set LD_LIBRARY_PATH to desired
> value or call application directly (but no one knows what will happen than
> ;)

Right. If a malicious process has the ability to set LD_LIBRARY_PATH, it also 
has the ability to ptrace() existing processes and read off their memory 
contents, it can possibly run eavesdropping D-Bus queries and get any 
passwords sent there. It can also read all of your files.

> On the other hand, malicious code may insert LD_LIBRARY_PATH into
> ~/.bash_profile, download some evil libs somewhere into deep hole of
> ~/.config (that's why I hate these newfangled "black holes" inside $HOME),
> and they can be accidentally used after the next shell login.

Right. But LD_LIBRARY_PATH does not apply for setuid / setgid programs. So the 
invasion does not spread if the user runs a setuid program.

However, if an attacker manages to run non-privileged code, the next vector of 
attack will be a local privilege escalation: exploit a bug in code that runs 
privileged but doesn't secure its inputs correctly.

For example, ssh-agent might be running and one of the keys loaded there may 
permit ssh root at localhost without a password. In other words, you have to 
secure against malicious code running as your own user. Once that has 
happened, the attack was already successful.

> > I am sure I am missing something here, so Captain Obvious please speak
> > up :)
> 
> There is a way to ensure that application loads libraries from certain
> locations: load them with dlopen.

dlopen(3) without paths obeys the search rules. QLibrary without paths does 
the same.

And note that the problem here isn't loading the right plugin with dlopen. 
It's that the plugin has dependencies and those are loaded automatically.

-- 
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/a9dcc8d1/attachment.bin