Re: Exec-Shield vs. PaX
> > [...] 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.
having non-executable pages achieves the same *and* guarantees failure
(vs. the probabilistic failure/success rate of randomization), that's
why i said that randomization played no role 'in the grand scheme'. the
fact it's still useful these days is the consequence of our inability
to effectively protect against the attack methods 2 and 3 i had referred
to earlier (luckily for the defense side, existing worms have used
attack method 1 but i would not rely on that in the future).
> 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.
'they are broken for good' means just that, they are no longer able
to run under PaX without tagging (at least not when PaX is configured
in its optimal form, that is, with non-exec pages and MPROTECT on).
you're correct with what i meant by 'managed' although i think you
may not like it because of the choice of my wording, not because what
i meant. if i say 'we need an API to allow userland to generate
code at runtime', will you still disagree with that (meaning 'disagree
on principles', not the suggested implementation)?
> The moment you start to 'manage' stuff that you believe is
> 'broken for good' it ends up being less accessible to people.
'root for everyone!' - isn't that concept 'broken for good' (in the
sense you originally interpreted it, i.e., 'flawed by design')? see,
we do change systems to be able to 'manage stuff' even if that means
that we'll make that stuff 'less accessible to people' (how many times
do system admins have to do things on behalf of their users because
said users are now not allowed to do it themselves?). so what am i
getting at here? the fact that secure (heck, even just usable) systems
should follow the principle of 'least privilege'. in the multi-user
system case, it says (among others) that if a user does not need to
have the privilege of root (read: complete system control), then he
should not have it, hence we have the concept of UIDs (and capabilites,
as the case may be). in the PaX memory protection case it means that
if an application does not need the privilege to generate code at
runtime, then it should not have it.
interestingly enough, this is exactly what i say in [3] - did you
read/understand it? if you did, then you should have realized that
you can argue only about whether you want to follow a least privilege
policy in this case, you cannot argue about how to do it because
there's just one way (the memory protection concept of PaX).
> 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.
i would not call [1] or [2] 'zero efforts'.
> > 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.)
[...]
> 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.
i'm sorry that you still haven't realized what PaX/paxtest are about.
PaX works against *exploit*methods* and paxtest simulates the core
steps of those methods to determine to what extent they work on a
given system. what you call 'bogus' again shows your misunderstanding
of how one writes exploits. let's do some thinking:
why did you write Exec-Shield (non-exec pages, randomization)? to
make exploit methods non-working. now the question is, have you
achieved that goal or not? or a bit harder question: what did you
achieve exactly? my answers are below:
Exec-Shield prevents existing exploits that rely on injecting/executing
their own payload from working (well, more or less, there can be cases
like with multithreaded apps on a non-RedHat system where such payload
shows up in a writable/executable part of the address space since such
does exist under Exec-Shield, unlike PaX).
i'd like to stress *existing* in the above because it leads to the
next question: what can you say about *future* exploits? what can
you say about the *possibility* of creating exploits that circumvent
Exec-Shield? you cannot make any generic claim either way because of
the lack of design in Exec-Shield. you can make claims about what
is needed to circumvent it, like the attacker needs to do a
return-to-libc style exploit to call mmap/mprotect and elevate the
executable region limit so that he can simply execute his payload
just like he did so in the past. however you cannot claim whether
this is possible for a given bug or not, at least not until you or
someone examines the precise circumstances and determines whether
it's possible or not. who's gonna do this every time a new bug
becomes public? why do we even have to ask this question and waste
precious human resources to answer it? see, that's the difference
between PaX and everything else i know of: PaX gives you guarantees
and you can sleep a bit better because you can rest assured as to
what an attacker can do with a bug (in the future that 'what' will
be 'nothing beyond denial of service'). you don't understand/care
about such assurance - that's your personal choice but there are
people who think otherwise and don't appreciate your calling PaX
methods 'bogus'.
> > [...] 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.
the brk() managed heap has also been executable. yet you break apps
that assume so (the ominous XFree86 server would also use the brk()
managed heap if you were to tell malloc() to not use mmap() at all
or for 'big' areas only, well beyond the default 128k. actually, for
'small' modules XFree86 does use the brk() heap).
speaking of breakage, you didn't not react on Exec-Shield breaking
POSIX/SUSv3 - any comments?
[1] http://adamantix.org
[2] http://www.gentoo.org/proj/en/hardened
[3] http://pageexec.virtualave.net/docs/noexec.txt
Reply to: