From: lcamtuf at coredump.cx (Michal Zalewski)
Subject: Re: January 15 is Personal Firewall Day, help
 the cause 

On Mon, 19 Jan 2004 Valdis.Kletnieks@...edu wrote:

> Well, if you consider noexec to be a feature, the /lib/ld-linux trick
> was a bug in it.

No, ld-linux functionality is not a bug in noexec. It simply is a
userspace feature of the linker. The feature is deliberate and extremely
useful in a couple of legitimate tasks.

Noexec is also a feature, but one that, with the way unix is designed, is
generally quite easy to bypass, with interpreters and various loaders,
memory corruption bugs in unprivileged applications, etc. There is simply
no way to guarantee a piece of memory that is read from a source that is
ought to be non-executable will never be executed, and since the
environment is not monolithic and consists of thousands of programs
written using different styles and skillsets, it is very difficult to
control all attack vectors at once - that is, unless you spend a
considerable amount of time creating an environment that is a very limited
subset of standard components - but then, if you just want your users to
run lynx and pine, you should reconsider the need to give shell access
with arbitrary execve() capabilities in the first place.

I said that noexec is badly broken because, with the way it is most
commonly used, it does not make the task of executing an arbitrary program
any more difficult. Quite the opposite, gives many sysadms a false sense
of security, and makes them implement more relaxed user accounting
mechanisms.

Trying to render noexec environment truly non-executable is just as
practical as spending your time to create an environment where the
attacker has no way to create an executable file to start with - you
either remove almost everything from the environment (see above: you might
be better off not providing real shell at all), or must check so many
possibilities you are almost guaranteed to overlook something - and the
efforts to audit and analyze capabilities of unprivileged userspace
applications on Linux are still not even nearing the end.

> + if ((prot & PROT_EXEC) && (file->f_vfsmnt->mnt_flags & MNT_NOEXEC)) +
> return -EPERM; + }

I (personally, and quite subjectively) think it's a silly way to address
the issue. The glibc linker happens to be working this way at the moment
(mapping input file with PROT_EXEC), but not all linkers can be reasonably
expected to do it the same way all the time [1]. On the other hand, if
some silly program passes PROT_EXEC to mmap on the input file, even though
it does not really need it, it will suddenly break on noexec partition. I
recall seeing several (admittably, less popular) apps doing this.

So, I would imagine a patch that is supposed to be a kludge to solve a
very specific case in a single piece of software ought to be put in this
software, not in kernel, and not when things may break - especially
since, should a minor change in glibc or some replacement set of
libraries alter the linking procedure, people would be exposed with no
warning. I am not saying it has to be done in libc, but if we decide to
tweak kernel, it might be more reasonable to find a better way.

On the other hand, I am just whining for no good reason - I do not think
this change is going to make my life any more difficult, nor do I have the
inclination to suggest a better solution, implement it and have it merged
with the sources, so take all this with a grain of salt ;-)

[1] One might map the file with PROT_READ to validate the executable, and
remap it with PROT_EXEC later on (sounds a more secure, actually); or read
the file into an anonymous map instead, if some environment flag is set;
and so on. I would not be shocked if some linker decides to do it at some
point.

-- 
------------------------- bash$ :(){ :|:&};: --
 Michal Zalewski * [http://lcamtuf.coredump.cx]
    Did you know that clones never use mirrors?
--------------------------- 2004-01-20 01:13 --

   http://lcamtuf.coredump.cx/photo/current/

Powered by blists - more mailing lists