Message-ID: <200308181409.42381.emt3734@rit.edu>
Date: Mon, 18 Aug 2003 14:09:42 -0400
From: Evan Teran <emt3734@...vax.isc.rit.edu>
To: "Joyce, MP (Matthew) " <M.P.Joyce@...ac.uk>,
	'Balwinder Singh' <balwinder@....net>, bugtraq@...urityfocus.com
Subject: Re: Need help. Proof of concept 100% security.



One concept that is similar to this that I was thinking would be to give each 
process a 32 byte array to represent a syscall allowed mask (1 bit for each, 
up to 256 syscalls).  And there would be a special syscall which allows a 
process to drop permission to call a given syscall (similar to those 
processes which start with root and drop to a nobody user like apache, but 
lower level).  This syscall would only allow to drop, not add a permission 
and could accept a mask to do several at a time for efficiency purposes.

Finally as apposed to killing the process, simply return the "syscall not 
implemented" value.

This mod would be entirely backwards compatible but has the downside of 
relying one the user space program to do a good job of dropping all but the 
bare neccessities, but i think has a lot of potential for success.

The nice thing is that it doesnt rely on any database or tracking, just a 
quick check in the int 0x80 handler (for linux at least).

Just a thought


On Monday 18 August 2003 05:15 am, Joyce, MP (Matthew) wrote:
> Some issues for these types of systems:
>
> EFC has to build the behavioural model for each application. For simple
> applications, it may be possible to build the behavioural model in a test
> environment, then use that model in production. However complex
> applications will have behaviour that may be very difficult to capture
> easily in a test environment, unless the test environment is very *very*
> complete. Therefore there may be some building of the behaviour model in a
> production
> environment. While this is happening, EFC cannot protect the application
> completely as it has no full model yet, but the application may be under
> attack as this is a production environment. So there is the risk of
> successful attacks forming part of the behavioural model.
>
> Every time a new version is released into production, a new model has to be
> built or the current model modified by aging old behaviours and allowing
> admins to flag deviant behaviour as permissible. So for complex
> applications, the training time may be long, or may require plenty of
> administrative input to mark false positives as permissible.  and rememnber
> there's no protection while the model is being built.
>
> I built a similar system for Windows apps in '99. It easily captured simple
> behaviours (e.g. winhlp32 or notepad) and with some more effort captured
> more complex behaviours. But big apps such as IIS were constantly
> generating new sequences of system calls and it looks like the learning
> phase was going to be longer than the time between patches to IIS, meaning
> the system would constantly be in learning mode.
>
> Also you only capture the behaviour used during training. If the sysadmin
> decided one day to use a feature that's never been used before, it
> generates many false positives as the behavioural model doesn't recognise
> the system calls sequences. So the system has to go back into learning mode
> until the new behaviour is learnt, inhibting the protection.
>
> So some problems still to be solved. But as part of a multi-variable IDS or
> IDP system, these systems will have a part to play.
>
> I would add to the model learning about what files were accessed in which
> directories, under Windows what registry entries were accessed and how,
> what ports were used and & what IPs were communicated with. So record
> particular parameters used with the syscalls, not just the syscalls
> themselves. That would form a fuller picture of how the app behaved and
> would reduce the false positives from only looking at the system calls.
>
> Matt
> -----Original Message-----
> From: Balwinder Singh [mailto:balwinder@....net]
> Sent: 18 August 2003 16:25
> To: bugtraq@...urityfocus.com
> Subject: Need help. Proof of concept 100% security.
>
>
> Hi All,
>
> I have developed an application, which I believe can provide 100% security
> against various attacks.I can hear people laughing. Hmm.. The applications
> is called Execution Flow Control (EFC). Details of software can be found at
> http://203.197.88.14/efc
>
> Now the help part:
> I have put up a site at http://203.197.88.14 which is protected by EFC. It
> is unpatched RH7.0 system with 2.4.20 kernel, no firewall, no IDS. All
> holes in the kernel and programs are intentionally kept. It is put up there
> for people to attack and try to get into the system. Gaining root to system
> is not enough as another level of protection unfolds when one has become
> root. There have been 1000+ attacks but no one could get even a normal
> user. This is first release and there got to be bugs in the system. The
> fact that so far no one could get into the system, is creating all kinds of
> complications in me (nervous, sad, bad ...). Machine is up for past one
> month and I still have a weeks internet time. Can you help me by providing
> your expert guidance on this software project. Can you help me by breaking
> into the system and then letting me know how can I improve the software.
> The paper at http://203.197.88.14/efc gives introduction only. detailes and
> most recent documentation will be made available as soon as I finish making
> it (The job is in the pipeline). I know about systrace, but have never used
> it. ----------------------------------------------------------------------
>
>
> 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.
>
>
> REGARDS
>
> Balwinder
>
> ---------------------------------------------------------------------
> We do not allow postman to bedroom but kernel does.
> ---------------------------------------------------------------------

Powered by blists - more mailing lists