recent security changes in openbsd
Theo de Raadt
some buffer overflow "solutions" into our source tree; under my
continual prodding. I thought I would summarize some of these and how
they fit together, since what I have seen written up so far has been
wildly inaccurate. (Bad reporter, no cookie).
These are, in short form:
1) PROT_* purity
2) W^X
3) .rodata
4) propolice
Let me start at the top then.
1) PROT_* purity
POSIX systems have three permissions for each page.
PROT_READ
PROT_WRITE
PROT_EXEC
To control the behaviour of a page, one or's these values together.
Unfortunately, as you can see from mprotect(2):
The mprotect() system call changes the specified pages to have protection
prot. Not all implementations will guarantee protection on a page basis;
the granularity of protection changes may be as large as an entire re-
gion.
This might not be true on a page. All real Unix systems I know of support
PROT_READ and PROT_WRITE correctly, but PROT_EXEC has largely been implied
as soon as you ask for PROT_READ.
This is because the pmap modules have been poorly written, or because the
mmu's in question are not fully capable. This change makes a best effort
based on the MMU in question to enforce PROT_EXEC as an independent flag.
BEFORE AFTER
sparc nope fully correct
sparc64 nope fully correct
alpha nope fully correct
vax nope impossible
m68k nope impossible
hppa nope fully correct
i386 nope see Note 1
powerpc nope see Note 2
Oh oh. i386 and powerpc, two very common architecures, have ominous
notes. Now you guys know why I want fast sparc64 machines to run.
Note 1)
The i386 is not capable of doing per-page execute permission.
At most it is only capable of drawing a line through the address
space, by limiting the code segment length (using the code segment
register). So we can say, "from 0 to this point is executable"
and "from that point on to the end of userland is not executable".
This sucks, but it is the best we can currently do. We can protect
the stack, and not much else.
There are a lot of other i386 details that are interesting to some
of us, but you don't want to know them. Anyways we are investigating
some possible changes that might help us protect more.
By the way, hammer will not have this problem...
Note 2)
The powerpc has a slightly more flexible mechanism than the i386,
but let me just say it still totally sucks. We can protect
the stack, and not much else.
So what we did here is to make a best effort solution at making the
stack non-executable on most architectures. On many others, we have
also made the data and bss segments non-executable.
In other words, the VM system needed slight tracks to correct the
tracking of PROT_EXEC more carefully, and then the pmap modules in
each architecture was modified to take a `best effort' approach
towards making PROT_EXEC an independent flag.
2) W^X.
W^X is a short form for "PROT_WRITE XOR PROT_EXEC". The basic
idea here is that most buffer overflow "eggs" rely on a particular
feature: That there is memory which they can write to, and then jump
to.
What if there was no such memory? Does a normal Unix process have
memory that is both writeable and executable? Turns out they do: In
particular, (ELF) shared library programs have these two segments
called GOT and PLT that are (depending on which architecture) normally
part of the text or data segment. They are overwritten at times.
But do they need it? The change that has been made is to put the
GOT and PLT into their own segments. The main goal of course, is to
try to ensure that at any time, no page in the system is both writeable
and executable.
We managed to get it working. The attackers just lost a place to put
their buffer overflow egg. On architectures where goal (1) is fully
working, that is...
3) .rodata
Now there is another problem. The code segment of a program, called
the text segment, has two parts in it on most systems: real code,
and read-only data. Historically a.out only had text, data and bss
segments, and it appears that when people moved to ELF they basically
just didn't use any new features that ELF has. We've finally now
moved to a seperate .rodata segment. Unlike the real text segment
which is PROT_READ|PROT_EXEC, this new segment is only PROT_READ.
What difference does this make? Well, if you manage to find some
data in a program that looks like instructions you might want to
run from your exploit, you can no longer do that. This may sound like
a minor chance (but there are also cache and performance reasons
too ;-)
4) Propolice
Propolice is, as I like say describe it, "Stackgaurd on steriods".
Stackgaurd uses a random canary (random value constant per run)
placed by the function prologue and checked by the function epilogues
to ensure the return address has not been moved. It was i386 only
code. Propolice is machine independent, running on most of our
architectures. As well, Propolice rearranges variables inside a
stack frame so that the ones most likely to overflow (ie buffers) are
closest to the canary, thereby making it hard to overwrite pointers or
regular integers (which it moves down).
We feel that these 4 technologies together will be a a royal pain in
the ass for the typical buffer overflow attacker.
We'll be writing a real paper about all of this later, but perhaps now
people will understand why we are excited about 3.4.
Theo de Raadt
> people will understand why we are excited about 3.4.
and 3.3 too of course ;-)
Almost all of what I described is already in the tree now. Just
a few mop-up bits to go...
Abdul Rehman Gani
>
> We feel that these 4 technologies together will be a a royal pain in
> the ass for the typical buffer overflow attacker.
>
> people will understand why we are excited about 3.4.
Do you have a summary of the affects, if any, these technologies will have as
far as installing and running s/w is concerned? Especially the install from
source route that requires the tar/configure/make cycle.
Thanks,
Abdul
--
http://www.eastcoast.co.za
Tel: +27-31-566-8080
Fax: +27-31-566-8010
Email: sup...@eastcoast.co.za
Theo de Raadt
> >
> > We feel that these 4 technologies together will be a a royal pain in
> > the ass for the typical buffer overflow attacker.
> >
> > We'll be writing a real paper about all of this later, but perhaps now
> > people will understand why we are excited about 3.4.
>
> Do you have a summary of the affects, if any, these technologies will have as
> far as installing and running s/w is concerned? Especially the install from
> source route that requires the tar/configure/make cycle.
Zero. It's invisible. We're just tightening up adherence to what
POSIX specifies.
Only one thing has cared: emacs, because it does stuff that is
entirely not right, and that has been worked around.
Don't you know us? You think we'd change it so it isn't Unix?
Abdul Rehman Gani
>
> Zero. It's invisible. We're just tightening up adherence to what
> POSIX specifies.
Great!
>
> Only one thing has cared: emacs, because it does stuff that is
> entirely not right, and that has been worked around.
>
> Don't you know us? You think we'd change it so it isn't Unix?
Know you?!?!? Damn! we trust you - but I needed to be prepared in case...
Thanks to the OBSD team for the proactive approach and the hard work to
implement it.
Abdul
btw: is there a TheoForUSPresident website?
Marc Espie
> Only one thing has cared: emacs, because it does stuff that is
> entirely not right, and that has been worked around.
What a surprise... gnu software that does not do things by the rules.
(sarcasm intended).
Over in ports, it's easy to get more and more fed-up with `the GNU system',
a large mass of incestuous kludges, where the shell is alway bash, m4
is always gnu-m4, yacc is always bison, ar always takes shortcuts because
it's part of binutils, -lpthread is the way to do threads, and you link
with -lresolv because it's there, not because you need it.
So, it's nothing new.
The sheer existence of BSD is a good thing, because otherwise there might
be the One Implementation of Unix tools, to rule them and in the dorkness
bind them... about as ood as Microsoft.
Dries Schellekens
> Hello,
>
> Are there any plans to develop/import formatguard-like solution for format bugs
> and blip-like gcc patch [1] for integer overflows?
Format string bugs are easy to find; they can be found automatically.
Blip seems to depend on gcc 3.x
http://marc.theaimsgroup.com/?l=openbsd-misc&m=104127568927422&w=2
Cheers,
Dries
--
Dries Schellekens
email: gwyl...@ulyssis.org
Pawel Jakub Dawidek
+> We feel that these 4 technologies together will be a a royal pain in
+> the ass for the typical buffer overflow attacker.
+>
+> We'll be writing a real paper about all of this later, but perhaps now
+> people will understand why we are excited about 3.4.
Excited? About what?!
All what have You done is just making C a "secure language".
So what You got now?
You can't exploit userland applications on _some_ architectures.
Yes, nice work! Next microsoft-like argument for OpenBSD promotion.
Maybe easier way is to not using C for set-uid/gid applications?
Sad, but kernel have to be a C program still...
Tell my (and all those I-pray-for-You-THEO rest), when You understand that
buffer overflows in userland applications are only one from very long list
type of attack. Yes, those are offten compromised, but only because it is
easy (in general) to use such a bug (but so fuckin what?).
Look at TrustedBSD project and see what REAL security looks like.
OpenBSD is dying, Theo. Only one can survive, and FreeBSD is the one,
but You already know that.
PS. Ok, now You can tell me how short my dick is.
--
Pawel Jakub Dawidek
UNIX Systems Administrator
http://garage.freebsd.pl
Am I Evil? Yes, I Am.
[demime 0.98d removed an attachment of type application/pgp-signature]
Dries Schellekens
> On Thu, Jan 30, 2003 at 02:11:09AM -0700, Theo de Raadt wrote:
> +> We feel that these 4 technologies together will be a a royal pain in
> +> the ass for the typical buffer overflow attacker.
> +>
> +> We'll be writing a real paper about all of this later, but perhaps now
> +> people will understand why we are excited about 3.4.
>
> Excited? About what?!
>
> All what have You done is just making C a "secure language".
>
> So what You got now?
> You can't exploit userland applications on _some_ architectures.
> Yes, nice work! Next microsoft-like argument for OpenBSD promotion.
>
> Maybe easier way is to not using C for set-uid/gid applications?
>
> Sad, but kernel have to be a C program still...
>
> Tell my (and all those I-pray-for-You-THEO rest), when You understand that
> buffer overflows in userland applications are only one from very long list
> type of attack. Yes, those are offten compromised, but only because it is
> easy (in general) to use such a bug (but so fuckin what?).
>
> Look at TrustedBSD project and see what REAL security looks like.
> OpenBSD is dying, Theo. Only one can survive, and FreeBSD is the one,
> but You already know that.
>
> PS. Ok, now You can tell me how short my dick is.
Your dick is short.
Lars Hansson
Do you people exist solely to complain? Don't you have any other reason
for living? Can't you bother some psychiatrist with your anger and
frustration instead of us?
Take your pathetic flamebait elsewhere.
> Am I Evil? Yes, I Am.
Aren't you just special.
---
Lars Hansson
Paladdin
technologies. So if you don't agree with them... That's great! Stick to your
projects and keep on working. Sure we can learn something from you -i.e.,
how to convince people how childlike we are-, and of course _sure_ you can
learn from us.
We're not pursuing devils, nor Microsoft, nor other OS's. This is our
proposal, nothing to do with FreeBSD, and IMHO is at least as good as yours;
it's only a question of taste. That's what 'free' stands for: everyone is
encouraged to do whatever they think it's the way, but hey, maybe you didn't
noticed: there are more than just one way.
Why the way, there is a bsd advocacy list were I'm sure you'd be welcomed.
Majordomo at bsd-advoca...@daemonnews.org should give you enough info
to subscribe.
Regards,
Paladdin
PS: I don't matter what's wrong with your dick, man. Just go and see a
doctor.
> --
> Pawel Jakub Dawidek
> UNIX Systems Administrator
> http://garage.freebsd.pl
> Am I Evil? Yes, I Am.
>
> [demime 0.98d removed an attachment of type application/pgp-signature]
___________________________________________________
Yahoo! Móviles
Personaliza tu móvil con tu logo y melodía favorito
en http://moviles.yahoo.es
Dave Feustel
[snipped]
An ATT researcher and a team at Cornel University have
developed Cyclone, a 'Safe dialect of C' that eliminates
buffer overflows and many other programming errors that
open the door to security exploits.
URL at http://www.research.att.com/projects/cyclone/
Dave Feustel
ope...@libkvm.org
i just wanted to say that i always see the different
BSD projects not competing but working differently and
sharing good developpment.
i mean i don't want to say "oh FreeBSD is the best, OpenBSD
blabla" because they ALL benefit from each other and all
belong to opensource interests.
I hope there won't remain only one BSD, because every project
can bring some great lights to us.
julien.
--------------------------------------------------------------------
Key fingerprint = 3A33 145C 2B0B 703A 0BFA BB87 D4A9 2BE0 4888 42F7
--------------------------------------------------------------------
Lurene Angela Grenier
Lurene
--
"What I cannot create, I cannot understand"
-- Richard Feynman
Toni Mueller
On Thu, Jan 30, 2003 at 02:11:09AM -0700, Theo de Raadt wrote:
> 1) PROT_* purity
> 2) W^X
> 3) .rodata
> 4) propolice
nice work!
The propolice stuff seems to benefit only those who get their box
cracked, but the attacker is too stupid to upload a binary that
runs on OBSD but may have been produced without propolice, and
instead relies on compiling his own source code on the target.
But for the rest of us, it gets us to see (and fix?) more ill
written programs.
Best,
--Toni++
Markus Friedl
> Hi,
>
> On Thu, Jan 30, 2003 at 02:11:09AM -0700, Theo de Raadt wrote:
> > 1) PROT_* purity
> > 2) W^X
> > 3) .rodata
> > 4) propolice
>
> nice work!
>
> The propolice stuff seems to benefit only those who get their box
> cracked, but the attacker is too stupid to upload a binary that
> runs on OBSD but may have been produced without propolice, and
why should the attack try to stack overflow his own programs?