利用Linux链接器.

释放双眼,带上耳机,听听看~!

Exploiting The Linux Linker,利用Linux链接器,

简要介绍如何利用Linux链接器。

,2010-08-24 21:26:34利用Tim Brown开发的Linux链接器,因此过去几天一直有很多关于Microsoft不安全的库加载可能会允许远程代码执行漏洞的争论,很多人一直在说Linux永远不会受到此类问题的影响。但我不确定我是否同意。虽然可以说Linux动态链接器默认不包括。在它的路径中,您将很少看到它在ld.so.conf和friends中列出,有一个角落的案例可能会捕获Linux用户。Linux动态链接器使用一个名为LD_LIBRARY_PATH的变量,它在执行二进制文件时会参考该变量,该变量的优先级高于LD.so.conf中设置的操作系统默认值。那么问题在哪里?考虑下面的脚本:#!/bin/sh export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/PATH/to/app/lib app start如果未设置LD_LIBRARY_PATH会发生什么?那么,在这种情况下,应用程序二进制路径是用一个LD_LIBRARY_path:/path/to/app/lib执行的。这看起来完全令人满意,但问题是。当Linux动态链接器看到一个具有空目录规范的路径,例如:/valid/path,/valid/path:或/valid::/path时,它将空规范视为$PWD。这可能会导致从用户当前工作目录加载库,但在哪里可能会被利用。回到上面的shell脚本片段,考虑如果这是特权进程的init脚本,会发生什么。管理员需要停止并启动它,但他在安全感知环境中工作,只能通过sudo命令访问in it脚本。所以他说:~:$sudo/etc/init.d/app sudo在作为另一个用户执行命令时,默认情况下不会更改您的工作目录,这意味着LD_LIBRARY_PATH最终将指向未授权用户自己的目录。这意味着Linux动态链接器将首先尝试从那里加载任何库依赖项。有些是返回的:*如果需要更改LD_LIBRARY_PATH,请先检查它是否已设置*如果通过su执行脚本时不带-flag,则当前目录不会更改*PATH变量的处理方式与此相同*如果要审核一个框,请检查特权用户运行的任何脚本,以安全地处理LD_LIBRARY_PATH和PATH*Linux(以及这很重要POSIX)发行版也会做一些愚蠢的事情*UNC路径让生活更有趣*在野外可能会有可利用的案例*我需要在unix privesc check Mood:Amused Music:Deekline&Ed Solo-Hands Up(斯坦顿勇士混音),网络安全教程Exploiting The Linux Linker,

Brief write up discussing exploitation of the Linux linker.

,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)

人已赞赏
安全工具

<p>面向返回的编程攻击的安全缓解.</p>

2020-2-6 3:45:44

安全工具

Distributed Denial Of Service Attacks Whitepaper

2020-2-6 3:45:46

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索