Bug 114160 – ld-linux.so allows bypassing of the eXecute permission bit on readable ELF programs

• Product: Gentoo Linux
• Status: RESOLVED CANTFIX

[Description Joseph Pingenot 2005-12-01 09:24:56 UTC]

ld-linux.so allows readable ELF programs on the filesystem to be executed
regardless of their eXecute permission status.

Reproducible: Always
Steps to Reproduce:
1.Make an [ELF] program (or copy one)
2.chmod ugo-x program
3./lib/ld-linux.so.2 ./program
4.Amaze your friends!
Actual Results:  
ld-linux executes the [ELF] program, despite lack of execute permission (and
probably also mount -o noexec!)

Expected Results:  
Not executed the program.  :)

This appears to be a problem in general: getting around the x bit by
constructing a program/exploiting a program to do it for you, and is likely only
truly combatable on a case-by-case basis.  In this case, ld-linux should be
fixed to check for x permission.  There are likely similar problems with bash
and other shells.

It'd be nice if there were a magic wand to make the kernel enforce the x bit,
but it's hard to do without checking to see if a file is a "program" (for some
definition of "program") [though this could potentially be done by using the
general idea behind part of exec(), i.e. letting each registered program type
vet the file ["is my type"at open() w/read.  For files recognized , maybe Linux
kernel should make the permission check at open() succeed if ((not_an_executable
&& read_set) || (an_executable && exec_set && read_set))]

But then you might inconvenience other programs, and you will still leave behind
unknown-to-the-kernel program types (e.g. certain scripts/VMs).

[Comment 1 Henrik Brix Andersen 2005-12-01 09:38:10 UTC]

I can confirm the behavior here.

[Comment 2 Harald van Dijk (RETIRED) 2005-12-01 10:59:56 UTC]

> ld-linux executes the [ELF] program, despite lack of execute permission (and
> probably also mount -o noexec!)

Actually, with noexec it will refuse to load.

[Comment 3 Henrik Brix Andersen 2005-12-01 11:01:19 UTC]

(In reply to comment #2)
> > ld-linux executes the [ELF] program, despite lack of execute permission (and
> > probably also mount -o noexec!)
> 
> Actually, with noexec it will refuse to load.

How does this fix the initial problem? Being able to execute -x binaries?

[Comment 4 Joseph Pingenot 2005-12-01 11:10:34 UTC]

Quite right about the noexec, btw:

$ls
-r--r--r--   1 someuser someuser 8700 Dec  1 12:57 small-read
$pwd
/mnt/foo
$/lib/ld-linux.so.2 ./small-read
./small-read: error while loading shared libraries: ./small-read: failed to map
segment from shared object: Operation not permitted

that said, the eXecute issue still remains.

I don't agree that this is RESOLVED at all, however.  The security of the
eXectue bit is dubious atm.

[Comment 5 Harald van Dijk (RETIRED) 2005-12-01 11:18:08 UTC]

> How does this fix the initial problem? Being able to execute -x binaries?

You're the one who closed this bug :) From your comment I assume this was a
mistake, so consider it reopened.

[Comment 6 Joseph Pingenot 2005-12-01 11:25:26 UTC]

Brix: as I stated, the problem goes beyond binaries and is going to be a Hard
problem to solve well.  For now, simply making ld-linux check is sufficient to
stop this <i>particular</i> hole, but one can still execute, for example, a perl
script in /usr/local/bin despite the script being -x:

$ dir /usr/local/bin/foo.pl 
-r--r--r--  1 solarion solarion 51 Dec  1 13:13 /usr/local/bin/foo.pl
$ file /usr/local/bin/foo.pl 
/usr/local/bin/foo.pl: perl script text executable
$ /usr/local/bin/foo.pl
bash: /usr/local/bin/foo.pl: Permission denied
$ perl /usr/local/bin/foo.pl
I ran!

It's also interesting to note that bash is a good citizen: it checks permissions:
$ dir /usr/local/bin/a.out 
-rw-r--r--  1 solarion solarion 49 Oct  3  2000 /usr/local/bin/a.out
$ file /usr/local/bin/a.out 
/usr/local/bin/a.out: Bourne shell script text executable      
$ bash /usr/local/bin/a.out 
Use ./a.out instead.
/usr/local/bin/a.out: line 4: ./a.out: Permission denied

[as an aside, /usr/local/bin/a.out in every user's path is an evil thing to do
in a multiuser environment, but helpful on your own machine ;]

[Comment 7 Henrik Brix Andersen 2005-12-01 11:34:01 UTC]

(In reply to comment #5)
> You're the one who closed this bug :) From your comment I assume this was a
> mistake, so consider it reopened.

Errr... oops. :)

[Comment 8 Jakub Moc (RETIRED) 2005-12-01 11:39:49 UTC]

1/ First of all, I've missed why it this filed to Gentoo bugzilla. This is
*absolutely not* a Gentoo-specific problem.

2/ This has been known for a long time, and used to work even with noexec
mounted partitions, later on this has been fixed in kernel (about two years ago)
and you cannot bypass noexec mount in this way any more.

3/ If you don't like the current behaviour, then use PaX/SELinux/whatever else
to get the desired behaviour...

UPSTREAM.

[Comment 9 Diego Elio Pettenò (RETIRED) 2005-12-08 06:50:09 UTC]

Why not remove perl, python and ruby interpreters then?  
Because you can always pass them the scripts as stdin  
  
perl < /path/to/a/perl/script (-x)  
python < /path/to/a/python/script (-x)  
ruby < /path/to/a/ruby/script (-x)  
  
... 
It's an unsolvable problem from that pov. 
I agree with jakub on this. 

[Comment 10 Jakub Moc (RETIRED) 2005-12-09 13:56:15 UTC]

Closing CANTFIX/UPSTREAM.