Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Re: Need help. Proof of concept 100% security.

From: Alaric B Snell (alaricalaric-snell.com)
Date: Fri Aug 15 2003 - 17:01:54 CDT

Balwinder Singh wrote:

> Brief Introduction of EFC
> -------------------------
> 1. Kernel runs in kernel space, which cannot be modified by user space
> programs. Each request from program ends up calling a routine in kernel
> space called syscall. Lets call syscall with arguments just syscalls
> Each program will make a defind set of syscalls to achieve its
> objective. Now idea is to watch syscalls that a program is supposed to
> make during its run time. A database which describes the syscalls that a
> program can make is called behavior model of the program. Lets assume we
> can generate a behavior model which perfectly describes an application.
> Now any deviation from behavior model of program essentially indicates
> an intrusion at real time. Thus a corrective action can be taken. This
> makes kernel intelligent which knows which program should do what,
> rather than a slave of program in which any program can ask anything and
> kernel will provide it.

That is indeed a nice approach to defence. It will stop a whole load (if
not all) of current exploits, which are written without it in mind.
However, what ways can we think of to try to attack it?

If the target program *ever* performs, say, the syscalls required to
start up a shell (fork, some socket calls to set up a listener, accept,
then dups of fds then exec, say?) - even with other syscalls inbetween -
then the shell code might well perform the syscalls in order, using
dummy arguments for syscalls it doesn't want (open /dev/zero and read
blocks of 0 bytes from it and so on).

I guess a lot of server apps only bind listening sockets early on in
their lives (SIGHUP aside). So maybe forking off a shell might become
too hard to do in general.

But daemons that write to files as root and so on are often exploited to
put stuff in /etc/inetd, /etc/passwd, crontabs, and executables. Would
it protect against a careful subversion of such a program that is
designed to act within the syscall behaviour of the original program?
Buffer overflows that do not gain control of execution but manage to
overwrite, say, the name of the log file to append to would sneak
through without even trying, needless to say.

But still - it sounds promising; it reminds me of an idea I was
considering (but Theo de Raadt hated!) of allowing processes to drop
certain syscalls (or certain modes of operation of syscalls - many are
multi-function), shedding priveleges in the same manner as setuid-ing
down to nobody or chrooting. So Apache could, after binding to its
ports, drop the ability to bind to ports. After opening its log files,
it could drop the ability to open files for writing. Each child process
would abandon fork rights, and exec rights as soon as it sees it's not a

There could be two levels of 'dropping' a right - one that's inherited
across exec and one that's not. When you run a chrooted system then the
scripts that start sshd and whatnot inside the chroot could drop system
management syscalls like halt/reboot and writing to sysctls.

Many apps could start by dropping a whole load of abilities they plain
don't need.

An NTP server could open its log file then drop all filesystem related
syscalls right off. It'd still have the file descriptor of the log file
to write() to, but otherwise its only contact with the kernel would be
IO on the pre-opened UDP socket and log file, access to the system
clock, sleep, and exit when it's had enough. No fork, exec, opening new
files, etc.