KuangPlus Project Proposal

Warren Toomey


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 and 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 other systems.
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 useful.

Combining COPS and Vendor Reports

We have a situation where

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:


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:

Status (as at January, 1999)

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

Things to Do (as at January, 1999)

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

Warren Toomey