KuangPlus Project Proposal

Warren Toomey

Introduction

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:

1.

It is specific to the Unix operating system: this makes it useless for other systems.

2.

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

• 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

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 mechanism here.
• 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 interface.
• The KangPlus core inductive engine must itself be very flexible, to make the writing of new rulesets possible.

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:

1.

Literature review on similar software, e.g COPS, the original SU-Kuang, NetKuang, etc.

2.

Review previous inductive engine implementations, in preparation to ...

3.

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?

4.

Sketch mechanisms to verify rules before running them.

5.

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.

6.

Start creating some rulesets. Concentrate on most recent security problems in most common systems and applications.

7.

Investigate possible methods to allow sites to download new rules. Also, consider if rules can be updated as well.

8.

Write project report.