exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

Exploiting The Linux Linker

Exploiting The Linux Linker
Posted Aug 26, 2010
Authored by Tim Brown | Site nth-dimension.org.uk

Brief write up discussing exploitation of the Linux linker.

tags | paper
systems | linux
SHA-256 | e6a4092d9c7f6bfe19a47771315ef0b1edbedff573ad3adc8783e68166ac9c97

Exploiting The Linux Linker

Change Mirror Download
2010-08-24 21:26:34

Exploiting the Linux linker

By Tim Brown

So there's been a lot of fuss over the last few days about the Microsoft Insecure Library Loading Could Allow Remote Code Execution vulnerability and quite a few folk have been making the age old point that Linux could never be affected by such a problem. I'm not sure I agree with that though. Whilst it's fair to say that the Linux dynamic linker doesn't by default include . in its path and you'll very rarely see it listed in ld.so.conf and friends, there is a corner case that could catch Linux folk out. The Linux dynamic linker makes use of a variable called LD_LIBRARY_PATH which it consults when a binary is executed and which takes precedence over the OS default as set in ld.so.conf. So where's the problem? Consider the following script:

#!/bin/sh
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/app/lib
app start

What happens if LD_LIBRARY_PATH isn't set? Well, in that case, the app binary path is executed with an LD_LIBRARY_PATH of :/path/to/app/lib. This may seem perfectly satisfactory, but here's the rub. When the Linux dynamic linker sees a path with an empty directory specification such as :/valid/path, /valid/path: or /valid::/path, it treats the empty specification as $PWD. This could lead to a library being loaded from the users current working directory but where might it be exploitable. Go back to the shell script snippet above and consider what would happen if that was the init script for a privileged process. An administrator needs to stop and start it but he works in a security aware environment and only has access to the init script via the sudo command. So off he goes:

~:$ sudo /etc/init.d/app

Sudo by default won't change your working directory when it executes a command as another user which means that LD_LIBRARY_PATH will end up pointing at the unprivileged user's own directory. What that means is that the Linux dynamic linker will attempt to load any library dependencies firstly from there. Some take homes:

* If you need to change LD_LIBRARY_PATH, check it is set first
* Your current directory won't change if you execute the script via su without the - flag either
* The PATH variable is treated in the same way
* If you're auditing a box, check any scripts run by privileged users handle LD_LIBRARY_PATH and PATH safely
* Linux (and for that matter POSIX) distros do stupid things too
* UNC paths make life more fun
* There are likely to be exploitable cases in the wild
* I need to add a check for this to unix-privesc-check

Mood: Amused

Music: Deekline & Ed Solo - Hands Up (Stanton Warriors Remix)


Login or Register to add favorites

File Archive:

February 2023

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Feb 1st
    11 Files
  • 2
    Feb 2nd
    9 Files
  • 3
    Feb 3rd
    5 Files
  • 4
    Feb 4th
    0 Files
  • 5
    Feb 5th
    0 Files
  • 6
    Feb 6th
    0 Files
  • 7
    Feb 7th
    0 Files
  • 8
    Feb 8th
    0 Files
  • 9
    Feb 9th
    0 Files
  • 10
    Feb 10th
    0 Files
  • 11
    Feb 11th
    0 Files
  • 12
    Feb 12th
    0 Files
  • 13
    Feb 13th
    0 Files
  • 14
    Feb 14th
    0 Files
  • 15
    Feb 15th
    0 Files
  • 16
    Feb 16th
    0 Files
  • 17
    Feb 17th
    0 Files
  • 18
    Feb 18th
    0 Files
  • 19
    Feb 19th
    0 Files
  • 20
    Feb 20th
    0 Files
  • 21
    Feb 21st
    0 Files
  • 22
    Feb 22nd
    0 Files
  • 23
    Feb 23rd
    0 Files
  • 24
    Feb 24th
    0 Files
  • 25
    Feb 25th
    0 Files
  • 26
    Feb 26th
    0 Files
  • 27
    Feb 27th
    0 Files
  • 28
    Feb 28th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Hosting By
Rokasec
close