Re: Exec-Shield vs. PaX
On Wed, 5 Nov 2003 pageexec@freemail.hu wrote:
> > non-executable pages on anything else but i386 is a triviality, as the
> > hardware and the kernel supports it. There's virtually nothing that PaX or
> > exec-shield has to add to enable them - they are there.
You are right that the other architectures you listed need alot of
nontrivial work and PaX did it very nicely. The two architectures that
will likely capture more than 90% of the CPU market in the next 10 years,
ia64 and amd64 both have executable bits in their pte formats. These need
no extra work. My sentence above should be "any of the x86 successors",
instead of "anything else".
[ i accept your points wrt. relative randomization. ]
> [...] randomization serves NO purpose in the grand scheme, it does not
> provide guaranteed protection against the PaX attack model (arbitrary
> read/write access to the address space). [...]
there's another, practical aspect of address-space randomization which i
find to be the most important: to make worms uneconomic in network
bandwidth terms. The most effective worm in recent history was a
single-packet exploit-and-infect attack, with a high likelyhood to infect
a machine via that single packet. If the worm has to guess certain exploit
parameters then the introduction of just one other packet can make or
break the dynamics of worm propagation - let alone the need for 1024 or
32K packets for a single infection. So randomization does have an
important longterm significance.
i agree that it's near worthless against local attacks or directed
attacks. It might help in eventually bringing more attention to the attack
itself but that's not a guarantee.
> > > second, paxtest had some bugs which Exec-Shield exposed and made
> > > Exec-Shield appear better than it is. i've fixed them here and
> > > expect to release 0.9.5 today or so. the results now look like:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > ( how fair that you give me a chance to run it ... not. )
i take this back - you did offer it for download. (I was parsing 'today or
so' as 'sometime later' and didnt check your site. I did check it after
sending the mail and discovered the new package. Obviously my points wrt.
the 'threading change' remain.)
> > you do realise that most of those 'exploit techniques' overlap with some
> > programming concepts, and you think that those concepts are flawed by
> > design and should be eliminated - i dont agree with this characterisation.
>
> putting words into my mouth or can you actually quote me on that?
i did not intend to put anything in your mouth - this is how i understood
your paragraph below:
> - apps that by their nature want to generate code runtime (e.g.,
> java). they're broken for good which many people noticed by now.
> that's good, that was my purpose because i wanted to draw
> attention to the fact that runtime code generation is an
> important privilege that should be carefully managed (as it
> happens to be also one of the exploit techniques).
i took the 'they are broken for good' as equivalent to 'concepts flawed by
design', and 'important privilege that should be carefully managed' as a
signal of your belief that the ability to generate code should be
restricted. I do not agree with this direction. The moment you start to
'manage' stuff that you believe is 'broken for good' it ends up being less
accessible to people.
(let me know if you think this is an unfair/inaccurate characterisation of
your words.)
> what i'm saying is that there are programming techniques (runtime code
> generation in this case) that should be handled more carefully than they
> have been. what PaX does by default FOR NOW is the result of me being
> cautious (and i have not heard of a single PaX user yet who did not
> appreciate it) and not having the resources to fix up userland all by
> myself. [...]
my experience is that resources that get 'managed' manually tend to be
much less accessible to the average user. Scripting (which is a form of
code generation) and generally writing code is the heart of Linux.
I would like to see all these security technologies to show up on Joe
Average's desktop, so government-style manual need-to-know access control
just doesnt cut it. It might work if packaged very very carefully with
lots of care towards making it simple, but i see zero efforts in that
direction. In fact i got flamed for even mentioning PT_GNU_STACK which i
believe is one careful step in that direction.
> you said a lot about what you don't agree with in PaX, what exactly
> prevented you from changing it *yourself*? what prevents *you* from
> disabling MPROTECT by default for example?
we did take a look at the PAX_SEGMEXEC portion of PaX for Fedora (you did
seem to be a reasonable person with tons of experience and this matters
alot when considering patches) and the killer at that time was the 1.5 GB
VM limitation on x86. Exec-shield, as coarse as it might be, does here and
today offer quite acceptable non-executability coverage of all actual apps
we checked, and this is what counts. (Nobody puts bogus mprotect(argv)
calls into these apps to disable exec-shield so exec-shield just works.)
If you ask any user about security they'll just nod and say it's very
important. But when facing them with the cost of security they'll just
shout at administration difficulties and broken apps and performance
impact, so only a careful and evolutionary approach suffices. Stuff can
only be added piece by piece, with frequent backtracks.
(Having said that, there's no reason why exec-shield couldnt be exchanged
for PaX in the future - most of the security features in Fedora are not
related to the dynamic-segmentation-limit thing of exec-shield at all,
what precise mechanism enforces the executability permission expressed in
the vma is irrelevant, as long as it works.)
the mprotect argument came not from my ability to enable or disable it in
PaX, but from the claim/impression that the (mprotect) tests in paxtest
constitude actual 'Vulnerabilities'. So i simply said i dont intend to
restrict mprotect semantics in exec-shield and explained my reasons for
doing so.
> speaking further about the 'prison' thing, you said this earlier
> in another thread:
>
> > if you could get rid of the 1.5 GB VM limitation of PaX and if you could
> > change it to use PT_GNU_STACK to set the process stack's protection bits
> > then i think there's no need for exec-shield - PaX will provide better
> > protection at no cost and no tradeoffs.
>
> have you changed your mind since then?
no, i havent. PaX is fundamentally finer grained than exec-shield. Eg.
exec-shield will never make library data/bss non-executable. The other
problems, like thread stacks or apps doing mprotect()s were solved, so all
the other exploitable areas are non-executable.
> > If you take that 'privilege' away you'll take away what drives
> > Linux forward - a constantly growing pool of programmers.
>
> i have the impression that you believe i'm trying to promote PaX to
> enter the 'main' kernels in its current from. [...]
this impression of yours is incorrect. PaX as a whole has no chance to get
into the kernel in the near future. Nor does exec-shield. (Linus is quite
strongly against security related restrictions.)
but i'd love it if you could start pushing eg. the arch exec-bit PTE
changes into the kernel - those would be very nice to have.
> [...] also, you did break userland yourself as well, otherwise how would
> you explain the patches RedHat made to the XFree86 server? [...]
that was a bugfix - X relied on executability of a non-executable area.
The x86 kernel just didnt enforce it. X would crash the same way on amd64
when running in x86 mode, without exec-shield.
(in fact X did properly use an executable area on other architectures -
just not x86 - the code was #ifdef-ed out on x86.)
it's not a bugfix to break apps that rely on an executable stack - the
stack _is_ executable.
> [...] see, there're just cases when userland is plain wrong and must be
> fixed. [...]
there's nothing wrong about an executable stack though. It's been part of
Linux ever since.
Ingo
Reply to: