Full Disclosure mailing list archives
Re: Re: January 15 is Personal Firewall Day, help the cause
From: Michal Zalewski <lcamtuf () coredump cx>
Date: Tue, 20 Jan 2004 01:54:07 +0100 (CET)
On Mon, 19 Jan 2004 Valdis.Kletnieks () vt 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/ _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- RE: Religion... was RE: Re: January 15 is Personal Firewall Day, help the cause, (continued)
- RE: Religion... was RE: Re: January 15 is Personal Firewall Day, help the cause Wes Noonan (Jan 18)
- Re: Religion... was RE: Re: January 15 is Personal Firewall Day, help the cause Jim Race (Jan 18)
- Re: Religion... was RE: Re: January 15 is Personal Firewall Day, help the cause David F. Skoll (Jan 18)
- RE: Religion... was RE: Re: January 15 is Personal Firewall Day, help the cause Bill Royds (Jan 18)
- RE: Religion... was RE: Re: January 15 is Personal Firewall Day, help the cause Mike Marshall (Jan 18)
- Re: Symantec AntiVirus and AOL Joshua Levitsky (Jan 18)
- Re: Re: January 15 is Personal Firewall Day, help the cause Martin Mačok (Jan 19)
- Re: Re: January 15 is Personal Firewall Day, help the cause Valdis . Kletnieks (Jan 19)
- Re: Re: January 15 is Personal Firewall Day, help the cause Michal Zalewski (Jan 19)
- Re: Re: January 15 is Personal Firewall Day, help the cause Valdis . Kletnieks (Jan 19)
- Re: Re: January 15 is Personal Firewall Day, help the cause Michal Zalewski (Jan 19)
- Re: linux noexec (Re: January 15 is Personal Firewall Day) Martin Mačok (Jan 20)
- Re: Re: January 15 is Personal Firewall Day, help the cause Mary Landesman (Jan 16)
- Re: Re: January 15 is Personal Firewall Day, help the cause David F. Skoll (Jan 16)
- Re: Re: January 15 is Personal Firewall Day, help the cause jan . muenther (Jan 16)
- Re: Re: January 15 is Personal Firewall Day, help the cause David F. Skoll (Jan 16)
- RE: Re: January 15 is Personal Firewall Day, help the cause Bill Royds (Jan 16)
- RE: Re: January 15 is Personal Firewall Day, help the cause Erik van Straten (Jan 17)
- Re: Re: January 15 is Personal Firewall Day, help the cause jan . muenther (Jan 17)
- Re: Re: January 15 is Personal Firewall Day, help the cause William Warren (Jan 17)
- Re: Re: January 15 is Personal Firewall Day, help the cause Ron DuFresne (Jan 20)