Eric Hutchinson writes:
> On Sat, 11 Sep 1999, Dr. Joel M. Hoffman wrote:
> > In particular, I was thinking that part of building a kernel would
> > involve assigning a random number to each syscall, and creating a
> > syscall.h file with these random numbers. [...]
Another way of saying this is to make the syscalls into capabilities
(in the traditional sense, not in the Linux sense). If the space of
system call numbers were large relative to the number of actual system
calls, it would not be feasible to search using brute force.
Especially since the kernel could kill the process and sound an alarm
if a nonexistent syscall were attempted.
> ok what happens when you need to compile soemthing else? [...]
Well, you link against libc like you always do -- don't need syscall.h
for that. Oops. :-) Protecting libc is a lot harder than protecting
syscall.h. An little disassembly of libc would tell you most
everything you needed to know, and dynamically linking against libc
requires that you can read it....
So it won't stop
- attacks that call library entry points directly,
- attacks by people who can get read access to libc (either in a
shared library or in core),
- data-directed attacks, where the program flow is unchanged but the
data is changed, and of course,
- attacks on higher-level scripting languages (like shell
metacharacter parsing).
Not to mention some other things I've forgotten. But it would get
script kiddies out of nearly all the binary-code remote exploit
business.
Best,
daniel dulitz
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:03:28 PDT