Re: Re: Breaking the links: Exploiting the linker

[Tim Brown <tmb () 65535 com>]

On Wednesday 22 December 2010 11:46:41 Jamie Nguyen wrote:
> Tim Brown <timb@...> writes:
> > In the interests of a thorough peer review I'd be curious what people
> > think of the following paper I've been working on Linux and POSIX
> > linkers:
> >
> > http://www.nth-dimension.org.uk/downloads.php?id=77
> >
> > A previous revision has already been reviewed but constructive criticism
> > is always useful.  There are some sections that I have removed whilst I
> > wait on vendors but I'm particularly interested in feedback on pertinent
> > references or threats that I may have missed.  As per the abstract, the
> > aim of the paper wasn't to claim everything as my own but rather to
> > document as much about the current state of art as possible.
> >
> > Tim
>
> Hi,
>
> I am somewhat unknowledgeable about the whole linking process, but I was
> testing out the execution of a file using ld on a filesystem mounted with
> noexec. I followed the example you gave of copying the '/usr/bin/id'
> executable to a user writeable directory and removing the executable bit.
>
> After removing the executable bit, I was still able to execute this on a
> normal filesystem using /lib/ld-linux-x86_64.so.2 but on a filesystem
> mounted with noexec this method did not work.
>
> You suggest in the article:
>
> "...if you're mounting devices with noexec the you should probably ensure
> that they [sic] the runtime linker can't be executed either."
>
> Forgive me if I am being dim, because from what I can see, mounting with
> noexec seems to solve the issue of using ld-linux-x86-64.so.2 to execute
> non-executable files.

You're not being dim.  On Linux, mounting the file system with noexec prevents 
the kernel mmap()ing the pages with execute permissions.  Removing the execute 
bit on a binary doesn't cause the same behaviour.  In the paper I was 
describing the general case.  This is something taviso or stealth mentioned to 
me too so I will update the paper to make this distinction clear.  Thanks for 
the feedback.

Tim
-- 
Tim Brown
<mailto:tmb () 65535 com>

Attachment: signature.asc
Description: This is a digitally signed message part.