Onderwerp: 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.
---------------------------------------------------------------------

On Mon, Aug 18, 2003 at 08:54:54PM +0530, Balwinder Singh composed:
> 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

You are doing system call monitoring based on a program model, and
killing programs which deviate, assuming I read the documentation
correctly...

A: You have false positives unless you generate this database through
program analysis or some other technique. "Security" procedures which
make systems less reliable are only rarely acceptable.



B: This has been done, based on program analysis, traces, and a whole
host of other techniques. Probably the best example based on program
analysis is

"Intrusion Detection via Static Analysis"
David Wagner and Drew Dean:
http://www.cs.berkeley.edu/~daw/papers/ids-oakland01.ps

This is probably the nicest imply because their model does NOT have
false positives, only false negatives.



C: How to waltz through this "100%" protection:
"Mimicry Attaks on Host-Based Intrusion Detection"
David Wagner and Paolo Soto:
http://www.cs.berkeley.edu/~daw/papers/mimicry.pdf

--
Nicholas C. Weaver nweaver@cs.berkeley.edu

Balwinder Singh wrote:

>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
>
This sounds somewhat similar to our SubDomain
<http://immunix.org/subdomain.html> product, which profiles applications
in terms of what files they may access. It sounds very similar to the
approach taken by Systrace
<http://www.citi.umich.edu/u/provos/systrace/>, Okena
<http://newsroom.cisco.com/dlls/corp_012403.html> and Entercept
<http://www.entercept.com/>, which like EFC, profile applications in
terms of which system calls they may invoke.

At least Systrace also allows you to profile the arguments presented to
syscalls, so you can fake SubDomain's file access control paradigm. This
is important, because "touch /etc/pointless" is rather different from
"touch /etc/hosts.allow". It is unclear from the EFC documents if EFC
supports argument profiling.

The advantages of syscall access control:

* more expressive: if you know that application Foo has no business
calling e.g. mkdir, then you can catch exploits that try to
leverage that kind of thing.

The advantages of SubDomain:

* It is easier to generate a file access profile for an application
than a syscall profile. Instead, SubDomain just has a long list of
prohibited/dangerous syscalls for confined applications, letting
the admin think about important stuff (which files to grant access
to) and ignore less important stuff (who cares if *this* app calls
getpid?).
* Syscall mediation is prone to race conditions inside the kernel if
it is implemented using syscall interposition.

Crispin

--
Crispin Cowan, Ph.D. http://immunix.com/~crispin/
Chief Scientist, Immunix http://immunix.com
http://www.immunix.com/shop/

On Mon, Aug 18, 2003 at 08:54:54PM +0530, Balwinder Singh wrote:
> I have developed an application, which I believe can provide 100%
> security against various attacks.I can hear people laughing. Hmm..

It's not a new idea, FWIW. I've certainly heard of this kind of
thing before. That doesn't mean it's inherently bad, but you don't
provide any evidence that you've addressed the fundamental weakness in
the concept, or are even aware of it.

The general weakness is that a system which "learns" the expected
behavior of software and then enforces it will then prohibit correct
but *unexpected* behavior, as opposed to wrong behavior.

> 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.

* This assumption is the weak point in the whole plan.

> 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.

Consider this thought experiment: Assume you rotate your webserver
logs once a month, and have the usual system-dependent procedure to do
this (something along the lines of "apachectl graceful" or "apachectl
restart" in your /etc/monthly.local file, for a BSD-style config.) You
run your behavior monitor on the webserver for two weeks, and it learns
that the particular sequence of syscalls associated with closing the
logs, shutting down the children, and restarting them, "never happens".
Now at the end of the month when you run the log rotation, your web
server is killed as suffering from a security violation. Oops.

This is a trivial example. The general problem in abstract form is
that unless you have a system for forcing an application to generate a
trace of all possible execution paths, in particular those for dealing
with exceptional conditions, there is a high likelihood that you will
be interrupting and preventing valid execution paths, hence
implementing your own "denial of service" on the system. Software
quality testers will be aware what a difficult problem this is. Your
description of your test doesn't mention whether you are evaluating
that half of the problem as well, but it doesn't sound like it.

As often reiterated, the challenge of implementing secure computer
systems is not to make them secure; that can be done by disconnecting
them from the network, turning them off, and sealing them in a buried
vault. The challenge is to make them secure while they continue to
operate "normally".

All comments IMHO
-- Clifton

--
Clifton Royston -- LavaNet Systems Architect -- cliftonr@lava.net

Did you ever fly a kite in bed? Did you ever walk with ten cats on your head?
Did you ever milk this kind of cow? Well we can do it. We know how.
If you never did, you should. These things are fun, and fun is good.
-- Dr. Seuss

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
CGI.

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.

ABS

Hi All,

I thank to all those who helped me and replied to my request.
Fumes, advice, guidance everything is welcome.
Please accept my appologies for delay in reply.

1. Please note this is an effort by an indivisual. I am working
on it for last two years. There are going to be cirtain things
which I don't know OR even don't understand. I have tested the
system myself and found acceptable, but had no other way to have
experts advice. So I had to put up 203.197.88.14.

2. Various people have pointed me to various links and comparing EFC.
I will quote following from EFC docs at 203.197.88.14/efc

"We do not claim that this is the only technology providing guaranteed
security, there could be (should be) more methods aiming 100% security.
EFC is just one of those methods.
This is first release. Please note that we do not claim that right from
version EFC will provide 100% security (although it can) against all
kind of attacks.Future releases will achieve higher level of security
leading to unbreakable system"

3. Results of EFC are in front of you all. There have been 2000+ plus
attacks, still system is up and running without a reboot. All
applications are doing what they are supposed to do. All these
security loopholes and attacks have cost money in past.

--------------------------------------------------------------------

Let me describe main components of EFC here. Some components described
here will be described fully in future docs. Some people adviced me to
check for existing patents, if they clash with EFC. Well I am confused
what to do if that turns out to be true. At that same time I would like
to mention that I am not going to file any patents for any of concepts
described hereafter. So if somebody finds something interesting and
wants to implement in his own way is free to do so.

1. EFC is not a kernel patch it is module. The decesion weather to make
patch or module was tough one. A patch can even guard against kernel
flaws. But M$ showed the way, Some functionalities can sacrificed for
users ease.
How I added struct efc to struct task_struct from a module is another
debatable issue.

2. EFC has following components.

2.1. Tool to generate behavior model automatically: I will quote
following from EFC docs.

"A database can be generated for selected programs. One can even select
all programs in a system to generate database. This model is based on
system calls a program can make during its run time. Forks by a program
are also considered. This model is generated from binary of the program,
source code is not needed. Thus model can be generated for commercial
programs as well which do not supply source code.
To generate database program is run on the system. Now all
possible capabilities of the program are used in order to generate
database. If you do not want to use full capabilities of the program
just dont use them during database generation. For example when
generating database for ftpd you may chose only to download files.
In this case only downloads will be allowed the moment upload
is tried ftpd will die."

Any part of code which was not a activated during data base generation
will not be allowed at actual run. If I want to use that part of the
code I must create conditions needed to activate that part of code.

"May be some day law should make it compulsory for manufacturer to
supply behavioral model of his software in some standard format leading
to accurate database. The moment this happens most of security related
issues will vanish, given that we have perfect software to implement
model based control"

This will also discourage those who put back doors in their software,
as back doors can be detected by analyzing behavior model automatically.

2.3 Execution Flow Control (EFC): The moment request for execution of a
program is made, kernel also loads program's behavioral model into the
memory. Each request by a program is compared with model data base. If
request agrees with model it is permitted otherwise program is killed,
fact is logged, system administration is alerted and diagnosis are
started to find out the reason for violation. Currently EFC kills
program and logs an error message in system logs, starting diagnosis
part remains to be done.
With EFC all attacks which rely on stack corruption, binary image
modification can be avoided.

2.2 Making libpam to talk with kernel: The programs like sshd, ftpd etc
allow outside people come in, these program act as gates to the system,
I call call these programs GATES (not to be confused with a billionare).
I call libpam as GATEKEEPER.
Cirtain code of these programs must get activated only after
aunthetication. As soon as one logs in fact is communicated to kernel.
Kernel takes care of changing UID of resulting process, plus other
security measures.
EFC comes with modified libpam and a new syscall to register a user with
kernel. This syscall can only be called by libpam no other program can
call it.

2.3 Kernel based aunthetication: As of today it is a user process which
does aunthetication. But here kernel does not trust root as well. Any
operation which you think is important can be auntheticated by kernel.
Apart from behaviour model, EFC supports a rule base looking something
like this

open /var/www/html/* /usr/sbin/httpd

The rule says only /usr/sbin/httpd is allowed to open /var/www/html/*.
You can implement as many rules as you please.

As soon as some other process tries to open /var/www/html, kernel
prompts for aunthetication. A successful aunthetication will disable
that rule for five minutes. Every five minutes all ruled renabled.

--------------------------------------------------------------------

In need of comments

Balwinder

--------------------------------------------------------------------

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@gmx.net]
Sent: 18 August 2003 16:25
To: bugtraq@securityfocus.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.
---------------------------------------------------------------------

> 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.

Nothing new under the sun:

http://imsafe.sourceforge.net/inside.htm
ftp://ftp.cs.unm.edu/pub/forrest/uss-2000.ps

And even published research:
http://citeseer.ist.psu.edu/13864.html
http://citeseer.nj.nec.com/445166.html

There are conspicuous citations in the two papers above. As for the mimicry
attacks against this concept, an URL has already been posted

Cordialmente,
Stefano Zanero

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@gmx.net]
> Sent: 18 August 2003 16:25
> To: bugtraq@securityfocus.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.
> ---------------------------------------------------------------------

On Fri, Aug 15, 2003 at 11:01:54PM +0100, Alaric B Snell wrote:
>
> 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).

Wagner and Soto published a paper about these 'mimicry' attacks:
http://www.cs.berkeley.edu/~daw/papers/mimicry.pdf

.... with regards to intrusion detection systems; same applies for host
based security. It's a problem that any behavioural models based purely
on syscalls have a tough time getting around. That, and how to reduce
the size of the FSM generated if you trace through all possible
permutations of the control flow statically.

> 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
> CGI.

It just adds another layer of complexity to an already over-complex
kernel/userland interface. If you're going to change the source like this,
I prefer privilege separation instead, which works without kernel changes.

--
Anil Madhavapeddy http://anil.recoil.org
University of Cambridge http://www.cl.cam.ac.uk

On 21 Aug 2003, Balwinder Singh wrote:

> "We do not claim that this is the only technology providing guaranteed
> security, there could be (should be) more methods aiming 100% security.
> EFC is just one of those methods.
> This is first release. Please note that we do not claim that right from
> version EFC will provide 100% security (although it can) against all
> kind of attacks.Future releases will achieve higher level of security
> leading to unbreakable system"

This is impossible. To get 100% security by this method, you must model the
program's intended behavior perfectly; but if you do that, then you are, in
effect, writing a perfect reimplementation of the program, running the
reimplementation alongside the original, and comparing the results of the two
programs at every step. Reimplementing the program will either involve
mindlessly duplicating the original code (which adds no security, as any bug
will be in both versions), carefully and perfectly auditing every line of
source to determine the program's intended behavior in all cases (which will
find all the bugs in the original code, eliminating the need for EFC), or
some mix of those (which permits bugs to appear). Using anything less than a
perfect model of the program makes it possible for an attacker to take
control: If EFC does not know exactly what behavior should happen at every
clock tick, how does it know whether any given behavior is good or bad?

By design, EFC only knows when a program uses system calls, not why, so it is
an imperfect model and thus cannot know exactly which behaviors are good and
which are bad.

This does not make EFC a failure. It can still provide useful protection
from lots of attacks. It cannot, however, provide 100% security.

--
Kyle R. Hofmann <krhofman@umich.edu>

In-Reply-To: <1061409854.1743.99.camel@limit.tm.org>

>3. Results of EFC are in front of you all. There have been 2000+ plus
>attacks, still system is up and running without a reboot. All
>applications are doing what they are supposed to do. All these
>security loopholes and attacks have cost money in past.
>

Ok, hang on a second here.

- It's already been pointed out on vuln-watch that it is possible to view
the contents of /etc/shadow using the webshell.cgi located
in /var/www/cgi-bin/. This is just the result of a bad path check, so I
thought I would hammer on EFC a bit more...

- It was possible using the webshell.cgi to dump the full contents
of /dev/hd* through the web. This bypasses EFCs filesystem restrictions
in a obvious way. Again maybe just bad configuration.

- It was not possible via the webshell.cgi to view the contents of
numerous directories. Finally some visible signs of security.
Unfortunately it was possible to bypass these restrictions by accessing
the same directories via the proc filesystem ( /proc/N/root/whatever-
directory ). This is clearly a flaw in EFC's checks. I imagine a hard-
link would have worked as well. This made it possible to obtain a copy of
efcm.o, the EFC kernel module, as well as all of the configuration
information available in /var/efc/. In fact it was possible to read any
file on any filesystem. Good thing there wasn't anything sensitive
in /home/bal, although thank you very much for the collection of
precompiled exploits...

So clearly rules like:
open /var/www/html/* /usr/sbin/httpd

Plain old don't work.

Various people have pointed out why EFC's design can never be 100%
secure, which is transparently obvious, really. From what I've seen the
implementation is pretty broken as well, and I was trying to be forgiving.

Maybe EFC is providing some protection against shellcode, but from what
I could tell from /proc/efc/, all of the shellcodes being run against it
were failing on a socketcall. I'm guessing the protection is generally as
solid as it appears, which is to say not very, and a somewhat cleverly
crafted shellcode could get through without much trouble. From what I
could tell from /var/efc/db/usr/sbin/sshd, sshd was allowed to
access /etc/shadow. So I'm guessing one could read the contents back
through the open socket to sshd without much trouble and then crack them
offline. Maybe the syscall restrictions are clever and take ordering into
account, or maybe they take the value of EIP at the time of the call into
account, unless you can point out something novel your doing, common
sense dictates that breaking these schemes is just a question of writing
a smart shellcode.

Seriously, you should release the source instead of holding silly h4x0r
cockfights, this isn't a bad idea, but breaking it in it's current state
isn't worth the trouble.

Cheers,
~x

anil@recoil.org said this stuff:

> On Fri, Aug 15, 2003 at 11:01:54PM +0100, Alaric B Snell wrote:
> > 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
> > CGI.
>
> It just adds another layer of complexity to an already over-complex
> kernel/userland interface. If you're going to change the source like this,
> I prefer privilege separation instead, which works without kernel changes.

Privilege separation is (1) not always an option, and (2) not a complete
solution. For example, one may still open network sockets in a
chroot(2) environment, while running as a non-root user. One may still
"fork bomb". Dropping system calls is no more difficult than effecting
resource limits from the programmer's standpoint. If the programmer
would rather not use resource limits, he need not be bothered. If the
programmer would rather not drop system calls, he also need not be
bothered.

The ideas that alaric snell and evan teran have are similar to something
i'm currently implementing for freebsd; whether or not it will be
accepted into the core distribution is another story. If it goes over
well with the community at large, i'll port it to linux and other
open-source BSD operating systems as well. In truth, i have found it
neither difficult nor complex to implement. Tedious, perhaps, but
neither difficult nor complex.

Banning kernel calls, however, is the wrong way to go about this. To
effectively turn off filesystem accesses for a process, the programmer
would need to disable many system calls. When the kernel is updated,
the number of system calls may change. The programmer would then need
to change his code, and old versions of the software would become not
just old, but obsolete, even if no new bugs were fixed or features
added. Programs would also become nonportable between operating
systems, and the programmer would even need to accommodate for
third-party patches, which may add additional system calls. The proper
way to handle the concept is by action class; if i want to disable all
filesystem reads, i should be able to call a function that will
effectively disable all filesystem reads. If i want to disable the
creation of files on the filesystem, i shouldn't need to specifically
disable open, bind, mkfifo, link, symlink, mkdir, and possibly others,
depending on what other kernel calls may be available.

I created a page about the idea, which can be found at:

http://www.episec.com/people/edelkin...rnel/flowpriv/

The page is a bit out of date now (i created it about a week ago), and
it doesn't discuss some of the technical design decisions i have made,
nor does it offer the proof-of-concept code i have written for it. But
it will be modified to reflect all of this as soon as i find the time.

There is a mailing list referenced on the page as well; anyone
interested in the project is welcome to join.

Mind you, i do not believe that this idea should be considered a
replacement for system call profiling tools (such as systrace), just as
i don't believe that the existence of tools such as systrace obsoletes
this idea. I believe that the two should work together: one that
allows an administrator to create policies, and another that allows the
programmer to design additional security into programs, without
introducing more than a negligible performance impact.

I find it unfortunate that you say theo de raadt was not fond of the
idea. Perhaps if he would like to subscribe to the mailing list and
voice his concerns, they may all be addressed.

ari (edelkind)

------------------------------------------------------------------------
Note: server 203.197.88.14 has been brought down as contract period with
ISP has expired. Please do not set your exploits for that IP now.
------------------------------------------------------------------------

Webshell was provided to view logs by typing more /var/log/messages, so
that you can find out where your exploit is failing. There are so many
holes in the system, real guys should exploit them. Also on real servers
one may not find webshell kind of applications.

>
> - It's already been pointed out on vuln-watch that it is possible to view
>
> the contents of /etc/shadow using the webshell.cgi located
>
> in /var/www/cgi-bin/. This is just the result of a bad path check, so I
>
> thought I would hammer on EFC a bit more...

shadow can be obtained by exploiting ftpd,sshd also. This is a weak
link, which has been pointed out by many guys. My last post talked about
it and a probable solution.


> - It was possible using the webshell.cgi to dump the full contents
>
> of /dev/hd* through the web. This bypasses EFCs filesystem restrictions
>
> in a obvious way. Again maybe just bad configuration.

Again another creative use of webshell, I had never thought giving
"more /dev/hda*" in webshell. What all partitions you copied, I hope
bandwidth usage does not go beyond 5GB.


> Unfortunately it was possible to bypass these restrictions by accessing
>
> the same directories via the proc filesystem ( /proc/N/root/whatever-
>
> directory ). This is clearly a flaw in EFC's checks. I imagine a hard-
>
> link would have worked as well. This made it possible to obtain a copy of
>
> efcm.o, the EFC kernel module, as well as all of the configuration
>
> information available in /var/efc/. In fact it was possible to read any
>
> file on any filesystem. Good thing there wasn't anything sensitive
>
> in /home/bal, although thank you very much for the collection of
>
> precompiled exploits...
>
>
>
> So clearly rules like:
>
> open /var/www/html/* /usr/sbin/httpd

This is the kind of feedback I was looking for. Thanks for pointing this
out. This flaw will be fixed in next version.


> Maybe EFC is providing some protection against shellcode, but from what
>
> I could tell from /proc/efc/, all of the shellcodes being run against it
>
> were failing on a socketcall. I'm guessing the protection is generally as
>
> solid as it appears, which is to say not very, and a somewhat cleverly
>
> crafted shellcode could get through without much trouble. From what I
>
> could tell from /var/efc/db/usr/sbin/sshd, sshd was allowed to
>
> access /etc/shadow. So I'm guessing one could read the contents back
>
> through the open socket to sshd without much trouble and then crack them
>
> offline. Maybe the syscall restrictions are clever and take ordering into
>
> account, or maybe they take the value of EIP at the time of the call into
>
> account, unless you can point out something novel your doing, common
>
> sense dictates that breaking these schemes is just a question of writing
>
> a smart shellcode.

Syscall restriction does not take ordering into account. Each syscall has
two flags attached more can be added. One flag is NEED_AUTH and another
is NEED_CHROOT. For programs which require authentication(GATES) NEED_AUTH
bit is set after successful authentication via libpam. So causing sshd,ftpd
to run shell without authentication should not work.
Similarly for programs which call chroot, NEED_CHROOT is set after call to
chroot. This might help for programs like ftpd.


> Seriously, you should release the source instead of holding silly h4x0r
>
> cockfights, this isn't a bad idea, but breaking it in it's current state
>
> isn't worth the trouble.

I had no other option but to put this server up and I see nothing wrong in it.
Live net experience is different from lab testing.
Let me prepare tar.gz with some READMEs befor releasing the code. May take two days.
Detailed logs will be available describing where exploits failed but again will take
some time as logs are huge, alone messages file has grown to 22Mb during last week.

Little deviation from model: Does someone has some links pointing to the employment
generated by GPL SW distributer companies and layoffs caused by companies which
are loosing to linux? If not now will this be a problem in future?
Can somebody enlighten me on this?

Thanks