Buffer Overflow attacks and Minix3
bre...@dcsi.net.au
vunerabilities and I have had a thought about buffer overflow and
buffer management.
What do people think (particularly Andy and Company) of placing the
responsibiliry of buffer management within a buffer manager? It would
mean providing appropriate messages for their management but this might
be a very useful enhancement for MINIX3.
Having a secure buffer management system for driver, server and user
code might well demonstrate the proper way of handling this particular
security flaw.
It appears that every buffer overflow attack depends on the application
writer (driver, server or application) not handling buffer management
carefully and consistently.
A point of discussion for anyone who cares.
regards
Bruce Rennie
(God's Own Country Downunder)
Warragul. Victoria
Australia
Marten Kemp
I've always wondered whenever the question of buffer overflows
comes up. I'm from a mainframe background and I think that I/O
calls should include information about how much data is expected,
especially in networking applications where the sizes are variable.
"hey, device driver, I'm expecting about this much stuff;"
"sorry, the packet was 'way too big; here's the first bunch,
I threw away the rest."
I may also be a little critical about the skills of programmers
whose code isn't defensive enough to avoid buffer overflows in
the first place. If your buffer is x bytes, trying to stuff x+n
bytes into it is Not Good Programming Practice (I can kinda,
sorta see an off-by-one bug where x+1 bytes are stored, but not
where n>1). Of course, in the mainframe world, I/O commands have
explicit lengths.
And, since you asked, no, I haven't written much c-ish code.
My languages of choice are REXX and S/390 Assembler.
--
-- Marten Kemp
(Fix name and ISP to reply)
-=-=-
... Remember, Republicans traditionally get in trouble over money, while
Democrats get in trouble due to sex. This is reasonable, because very
few people are interested in a piece of elephant.
-- Harold Berkowitz on alt.books.tom-clancy
* TagZilla 0.059 * http://tagzilla.mozdev.org
J.N. Herder
> I have just been reading some of the SANS Newsbites on security
> vunerabilities and I have had a thought about buffer overflow and
> buffer management.
>
> What do people think (particularly Andy and Company) of placing the
> responsibiliry of buffer management within a buffer manager? It would
> mean providing appropriate messages for their management but this might
> be a very useful enhancement for MINIX3.
When I understand this proposal correctly, I don't think having a buffer
manager is the way to go. It might work, but it seems inconvenient for the
programmer, and there may be better ways to get rid of the problem.
Currently we have different ways to battle problems caused by buffer
overflows. By default MINIX 3 uses separate Text (read-only) and
Stack/Data (read-write) segments. While buffer overflows can still occur,
the text segment won't be overwritten. This means it's not possible to
directly inject your own code and execute it, as most viruses and worms
do. It is still possible to change the return address on the stack,
though, but this leads to a much harder to exploit class of attacks, known
as 'return-to-libc' attacks.
Although we have no direct plans to work on this, we are thinking of using
type-safe languages to get rid of the problem altogether. Since all of the
OS servers and drivers run as a separate program, this seems relative easy
to implement (and analyze) for one or more components. In theory, any
(type-safe) programming language can be used to implement the user-space
parts of the OS. We've done some experiments with Cyclone, but there may
be better candidates. The hardest part will be to get the message passing
mechanism to work. It would be great if there's anyone to give this
approach a try.
Jorrit
bre...@dcsi.net.au
>
> When I understand this proposal correctly, I don't think having a buffer
> manager is the way to go. It might work, but it seems inconvenient for the
> programmer, and there may be better ways to get rid of the problem.
In terms of programming in C, maybe. However, as many programs make
requests for memory from the OS, I think a unified approach might be
worth looking at. Particularly if an API and an appropriate set of
messages could be developed.
>
> Currently we have different ways to battle problems caused by buffer
> overflows. By default MINIX 3 uses separate Text (read-only) and
> Stack/Data (read-write) segments. While buffer overflows can still occur,
Question, how would this affect a language/environment like FORTH or
FACTOR? Both of these build definitions (executable code) on the fly -
interactive development. With FORTH there is an ANSI standard defining
BUFFER handling as well as a lot of other things.
I must try compiling gforth and bigforth on MINIX 3 to see how they go.
I will try out FACTOR as well - should be interesting.
> the text segment won't be overwritten. This means it's not possible to
> directly inject your own code and execute it, as most viruses and worms
> do. It is still possible to change the return address on the stack,
> though, but this leads to a much harder to exploit class of attacks, known
> as 'return-to-libc' attacks.
>
> Although we have no direct plans to work on this, we are thinking of using
> type-safe languages to get rid of the problem altogether. Since all of the
> OS servers and drivers run as a separate program, this seems relative easy
> to implement (and analyze) for one or more components. In theory, any
> (type-safe) programming language can be used to implement the user-space
> parts of the OS. We've done some experiments with Cyclone, but there may
> be better candidates. The hardest part will be to get the message passing
If I can get FACTOR or FORTH working, I'll give it a shot.
> mechanism to work. It would be great if there's anyone to give this
> approach a try.
>
> Jorrit
Again thank to both of you for your comments.
David Given
Hash: SHA1
In article <1132967591.2...@g44g2000cwa.googlegroups.com>,
bre...@dcsi.net.au writes:
[...]
> Having a secure buffer management system for driver, server and user
> code might well demonstrate the proper way of handling this particular
> security flaw.
>
> It appears that every buffer overflow attack depends on the application
> writer (driver, server or application) not handling buffer management
> carefully and consistently.
- From Minix' perspective, this is because all application-level buffers are
managed *by* the application --- it's all anonymous code manipulating the
application's data segment. Minix doesn't know what the application
considers to be a buffer or not.
Having an add-on library that provides secure memory management could well
be a good idea, but unfortunately, it's got to interoperate with C and C
doesn't pass around the necessary information to do this universally. This
means that you're still going to need coding discipline to do things
properly, even with the aid of the library, which means that you may as
well do without the library completely.
However, you might be interested in having a look at OpenBSD's new memory
allocator:
http://www.securityfocus.com/columnists/359
It's a user-level allocator that works with the kernel (using mmap()
extensively) to ensure that all (greater than a page) memory blocks
allocated by a process are guarded each end with an unmapped page. This
causes buffer overruns to become SIGSEGVs; they say they've already found
several ancient bugs in X that nobody's ever spotted...
- --
+- David Given --McQ-+
| d...@cowlark.com | "The further you are from your server, the more
| (d...@tao-group.com) | likely it is to crash." --- Woodhead's law
+- www.cowlark.com --+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDiuqFf9E0noFvlzgRAgTKAKCYU7yIXfbqCX/QG7UsJuTRSfZUcQCfYDBe
VY4DU7Lh7WfO9qNZd8dke38=
=//vA
-----END PGP SIGNATURE-----