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:

March 2024

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

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close