[7950] in bugtraq
Re: Dump a mode --x--x--x binary on Linux 2.0.x
daemon@ATHENA.MIT.EDU (Casper Dik)
Tue Sep 15 14:58:03 1998
Date: Tue, 15 Sep 1998 20:20:15 +0200
Reply-To: Casper Dik <casper@HOLLAND.SUN.COM>
From: Casper Dik <casper@HOLLAND.SUN.COM>
X-To: Alan Cox <alan@LXORGUK.UKUU.ORG.UK>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: Your message of "Tue, 15 Sep 1998 14:52:30 BST."
<m0zIvWy-000aQwC@the-village.bc.nu>
>> process-dump-... files in the current directory. The executable itself
>> can be recovered by catting the first few files together and truncating
>> at the executable size. I have tested this by reconstructing a copy of
>> /bin/cat which I had protected mode 111 under Linux 2.0.x.
>
>You can only do this for non setuid applications. I would question it
>is even a bug. Execute only is an extremely vague concept anyway on
>x86 since the chip doesnt really support it physically.
Solaris has the same "problem" and I too am not sure whether it's
a bug or not. Also, filesystems like NFS make no distinction between
read-for-execute or read-for-reading.
Solaris /proc disallows access to execute only binaries, but its
LD_PRELOAD and also LD_LIBRARY_PATH have the exact same problem.
LD_LIBRARY_PATH is somewhat trickier to abuse as it requires you to
build an entire library and not just an object with a few replacement
function, although you might get very far by just using a .init section
and little substance.
>The convenience and usefulness of LD_PRELOAD seems to far outweigh this
>consideration for normal use. Its probably one for the 'secure linux'
>patch collection therefore.
Indeed, and I would think that disabling LD_LIBRARY_PATH too would have
serious usability impact.
Casper
