lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.SOL.4.44.0308182047220.15-100000@zektor.gpcc.itd.umich.edu>
Date: Mon, 18 Aug 2003 21:16:37 -0400 (EDT)
From: Kyle Roger Hofmann <krhofman@...ch.edu>
To: Balwinder Singh <balwinder@....net>
Cc: bugtraq@...urityfocus.com
Subject: Re: Need help. Proof of concept 100% security.


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@...ch.edu>



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ