security patch

security patch

[breno]

Hi people,

I'm doing a new feature for linux kernel 2.6 to protect against all kinds of buffer
overflow. It works with new sys_control() system call controling if a process can or can't
call a system call ie. sys_execve();

You can do it using /bin/sys_control <pid> <enable or not system call> <eax of system
call> <secret number>
for process that never call for example sys_execve(), setuid() ( you must need specify
each eax for each system call) and use some functions in sys_control.h like lock_execve(n)
and unlock_execve(n), where n is a secret number defined in sysctl. With this functions
you will use system calls only when you need. 
All shellcodes that use system calls like sys_execve() sys_setuid() will not work with
this feature.

I think it can be an option in linux kernel.

Questions .. suggestions.

Thanks

Breno at kalangolinux.org 

Re: security patch

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 822 bytes --]

On Thu, 22 Sep 2005 19:44:33 -0000, breno@kalangolinux.org said:

> I'm doing a new feature for linux kernel 2.6 to protect against all kinds of buffer
> overflow. It works with new sys_control() system call controling if a process can or can't
> call a system call ie. sys_execve();

This has been done before. ;)

Also, note *VERY* carefully that this does *NOT* protect against buffer overflow
the way ExecShield and PAX and similar do - this merely tries to mitigate the
damage.

Note that you probably don't *DARE* remove open()/read()/write()/close() from
the "permitted syscall" list - and an attacker can have plenty of fun just with
those 4 syscalls.

(That's also why SELinux was designed to give better granularity to syscalls - it
can restrict a program to "write only to files it *should* be able to write").

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: security patch

[linux-os (Dick Johnson)]

On Thu, 22 Sep 2005 breno@kalangolinux.org wrote:

> Hi people,
>
> I'm doing a new feature for linux kernel 2.6 to protect against all kinds of buffer
> overflow. It works with new sys_control() system call controling if a process can or can't
> call a system call ie. sys_execve();
>

Are you aware that there are very few 'built-in' commands in
any of the shells?  If a user can't execute anything, the
user can't do anything.

If you think that this will protect against improperly-written
daemons, and things that never exec anything, you are wrong.
The place to fix bad code is in the code.

> You can do it using /bin/sys_control <pid> <enable or not system call>
> <eax of system call> <secret number>


This is a joke, right?


> for process that never call for example sys_execve(), setuid()
> ( you must need specify each eax for each system call) and use
> some functions in sys_control.h like lock_execve(n)
> and unlock_execve(n), where n is a secret number defined in sysctl.
> With this functions you will use system calls only when you need.
> All shellcodes that use system calls like sys_execve() sys_setuid()
> will not work with this feature.

What will they do? I try to execute `ls`, the kernel says I can't
fork and exec `/bin/ls`. So, do I get killed, logged out? The
shells handle errors in different ways. There is a big difference
between how bash handles ENOENT (No such file or directory) and
ENOSYS (Function not implimented).

>
> I think it can be an option in linux kernel.
>
> Questions .. suggestions.
>
> Thanks
>

I think this is just another ruse to attempt to get the system
call table exported, something you don't need to do in order
to replace any of its elements. Am I guessing correctly?

> Breno at kalangolinux.org
>

Cheers,
Dick Johnson
Penguin : Linux version 2.6.13 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: security patch

[Zan Lynx]

[-- Attachment #1: Type: text/plain, Size: 1257 bytes --]

On Thu, 2005-09-22 at 16:03 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Thu, 22 Sep 2005 19:44:33 -0000, breno@kalangolinux.org said:
> 
> > I'm doing a new feature for linux kernel 2.6 to protect against all kinds of buffer
> > overflow. It works with new sys_control() system call controling if a process can or can't
> > call a system call ie. sys_execve();
> 
> This has been done before. ;)
> 
> Also, note *VERY* carefully that this does *NOT* protect against buffer overflow
> the way ExecShield and PAX and similar do - this merely tries to mitigate the
> damage.
> 
> Note that you probably don't *DARE* remove open()/read()/write()/close() from
> the "permitted syscall" list - and an attacker can have plenty of fun just with
> those 4 syscalls.
> 
> (That's also why SELinux was designed to give better granularity to syscalls - it
> can restrict a program to "write only to files it *should* be able to write").

An interesting thing that I don't think has been done before is to
create a map linking stack call chains to syscalls.  If the call stack
doesn't match then it isn't a valid call.

Although that might already be part of execution fingerprinting, now
that I think about it...
-- 
Zan Lynx <zlynx@acm.org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: security patch

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 476 bytes --]

On Thu, 22 Sep 2005 14:24:48 MDT, Zan Lynx said:

> An interesting thing that I don't think has been done before is to
> create a map linking stack call chains to syscalls.  If the call stack
> doesn't match then it isn't a valid call.

I suspect longjmp() and friends would play havoc on this, and vice versa,
as well as those syscalls that are legal from inside signal handlers, and
a few other cases.

What validity check were you planning to make on the stack call chain?

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: security patch

[Chris Wright]

* Zan Lynx (zlynx@acm.org) wrote:
> An interesting thing that I don't think has been done before is to
> create a map linking stack call chains to syscalls.  If the call stack
> doesn't match then it isn't a valid call.

There's been a fair amount of research in anomaly detection.  It's not
as effective as you might hope.  Can be slow, and since it's typically
based on statistics, needs to be properly trained (can be difficult) and
may be ineffective if you stay below anomaly threshold.

thanks,
-chris

Re: security patch

[Hagen Paul Pfeifer]

* breno@kalangolinux.org | 2005-09-22 19:44:33 [-0000]:

>I'm doing a new feature for linux kernel 2.6 to protect against all kinds of buffer
>overflow. It works with new sys_control() system call controling if a process can or can't
>call a system call ie. sys_execve();

[...]

>Questions .. suggestions.

Think about userspace loaders! E.g. John Reiser's UPX or technics used in
self[0]. What about "protect against all kinds of buffer overflow", at
least the aplication can still be crash.

>Breno at kalangolinux.org 

HGN

[0] http://www.phrack.org/show.php?p=63&a=11

Re: security patch

[Chris Wright]

* breno@kalangolinux.org (breno@kalangolinux.org) wrote:
> I'm doing a new feature for linux kernel 2.6 to protect against all kinds of buffer
> overflow. It works with new sys_control() system call controling if a process can or can't
> call a system call ie. sys_execve();

This is insufficient to protect against buffer overflow.  You are
re-inventing something that's been done multiple times.  Each are
arguably more effective.  Look at the seccomp option in current kernels.
Look also to policy enforcement via something expressive such as
SELinux.

> I think it can be an option in linux kernel.

We've got what we need in the kernel now.

thanks,
-chris