KuangPlus Project Proposal
One of the dilemmas facing systems administrators today is the amount of
time they need to spend finding and fixing known security deficiencies
in their systems. Information about new security deficiencies is made
available in a timely fashion from operating systems vendors, application
vendors, computer emergency response teams and other groups interested in
computer security. A sysadmin must decide how much time they can devote to
reading these deficiency reports, determining if the local system is affected,
and taking the steps to rectify any holes found.
Currently, deficiency reports are usually written in a human language, e.g
English, and describe what the problem is and how it affects a system's
security. In some cases, exploit or other programs are available to test if
a system has the weakness. These reports and programs are often digitally
signed with a public key cryptosystem, so that the system administrator can
verify that they did come from a particular vendor, and that the report or
program has not been tampered with.
In many cases, newly-found security holes give an attacker full system
rights, e.g to become `root' under Unix or `administrator' under NT. In
other cases, In other cases, the holes give an attacker limited system rights.
However, combinations of existing system deficiencies may be combined by an
attacker to gain greater system rights than a single hole by itself. The
vendor reports about individual security holes obviously cannot describe
the effect of combined deficiencies.
Let us now turn the clock back a number of years.
In 1992, Dan Farmer and Eugene Spafford introduced the COPS
package: this was a toolkit which could check for many common Unix
configuration problems. See this COPS PostScript paper
this COPS ASCII paper.
In particular, the Kuang tool could chain together individual configuration
flaws, and find exploitable security holes that arose as a result of
the chain of configuration flaws.
The COPS system is an ingenious way to find individual system security
holes semi-automatically, and also to determine the security consequences
of holes in combination. However, the two main deficiencies of COPS are that:
- It is specific to the Unix operating system: this makes it useless for
- The rulesets originally provided with COPS were never kept up to date
by COPS' creators, nor by system vendors, application vendors nor
computer security groups. As time passed, COPS became less and less
We have a situation where
- a tool like COPS provides an automated way of determining a system's
vulnerability to known security holes and their combination, but
the tool does not track newly-found security deficiencies; and
- vendors and computer security groups provide timely reports of
newly-found security deficiencies in a tamper-proof fashion, but
only in a format which must be processed by a human.
It seems obvious that, if the computer security community could be persuaded
to provide details of security deficiencies in a rule-based format, then
these rules could be processed by a Kuang-like inference engine to
automatically test a system's vulnerability to the deficiencies.
In order for such a combination to actually be taken up by both the
providers of such rulesets, and by the end-users of the rulesets, such a
system must have a number of characteristics:
- Vendors must produce security reports of new holes in ruleset form.
- One or more mechanisms must allow end-users to obtain new rules
quickly and automatically.
- End-users must be able to trust the rules obtained: they must be
able to verify who created the rules, and verify that the rules
have not been tampered with.
- As the rules must be executed on the end-user's system, they must
be written in a fashion that is relatively easy to read and
understand. The rules must therefore be transmitted in source form.
- A Kuang-like inference engine should form part of the system, as this
can determine the effect of deficiency combinations. Again, the
engine must be distributed in source code form, in a way that
identifies the author and shows that it has not been tampered with.
- The copy of the software and rulesets on the end-user's system must
be able to verify its own `intactness' before it is used each time.
This prevents attackers from exploiting existing system holes, and
modifying the system to prevent detection of the deficiency. Therefore,
sections of the system should be designed to be rarely modified, and
to be placed on read-only media.
- The system and the rules should be implemented in a machine- and
system-independent language which has access to each systems' APIs.
- The system can obtain new rules from various rule sources, verify
their author and integrity, integrate them into the local system,
apply them, and report new system deficiencies to the system
administrator in one operation.
KuangPlus is a system which is being designed to meet the criteria listed
above. Kuang will be written in Perl, as it is machine- and
system-independent, and still has access to the system APIs. As it is
interpreted, this also allows the core software and the rulesets from vendors
to be distributed in commented source form.
The components of the system will be designed to be modular. Only the
Kuang-like inference engine will be a required component. Other components
will be built using existing security tools such as PGP, ssh, rsync, checksum
algorithms like MD4, MD5 etc. The other main components are:
- The mechanisms to obtain new rules. Several mechanisms should be
supported: anonymous ftp, web mirroring, CVS, anonymous rsync,
e-mail. As well, it would be nice to exclude the downloading
of rules which would not be applicable to the local system.
- The verification of obtained rules. It would be nice to provide
several mechanisms to perform this, but ruleset vendors would
have to provide rules in each verifiable format. Initially,
rules encrypted and signed using PGP2 or PGP5 may be the only
- The report generation of results from the inference engine.
Several possibilities here are plain text, text files, HTML
documents, and the delivery of these by e-mail of through a web
- The KangPlus core inductive engine must itself be very flexible, to
make the writing of new rulesets possible.
This document is essentially a call for expressions of interest. No part
of KuangPlus has been written yet. We need people who would be prepared to
rigorously specify what the system should do, design the components to
meet the requirements, implement the components, and convince the
computer security community to adopt KuangPlus once it has been implemented
Suggested list of things to do, in some rough order:
- Literature review on similar software, e.g COPS, the original
SU-Kuang, NetKuang, etc.
- Review previous inductive engine implementations, in preparation to ...
- Design a new one to be implemented in Perl:
- More goals than the the previous engines
- Allows on-the-fly loading and execution of rules
- Ignores rules which can't be used on the system
- One-off rules and apply-often rules
- Some rules run as nobody, some as root?
- Perhaps caching to speed it up?
- Sketch mechanisms to verify rules before running them.
- Implement the engine and the on-the-fly rule loading mechanism
in a fashion that will run on Solaris, FreeBSD and Linux. NT
would be a bonus.
- Start creating some rulesets. Concentrate on most recent security
problems in most common systems and applications.
- Investigate possible methods to allow sites to download new
rules. Also, consider if rules can be updated as well.
- Write project report.