[ Many ideas taken from: HaxNet - APG V1.3 : Guide to finding new holes]
NOTE: I think this should be divided into general categories:
1) General principles
2) Looking for holes in src (most items here)
3) Looking in binary distributions
4) Looking in site specific configurations
The following general classifications suggest themselves:
1) SUID/SGID
2) Return codes/error conditions
3) unexpected input
4) race conditions
5) authentication
6) implicit trust
7) parameters
8) permissions
9) interrupts
10) I/O
11) symbolic links
12) Daemons, particularly those taking user input.
13) Kernel race conditions
14) what else? - please add categories
(Suggested splitting of above into main and sub-catagories)
I: Suid binaries and scripts
unexpected user interactions
flawed liberary calls
implicit assumptions of external conditions (sym links, loc. paths)
race conditions
II: daemons running with priviliged uid's
race conditions
poor file protectons
implicit file protections
trust
authentication
III: Kernel problems
Kernel race conditions
device driver code
The following four step method was created by System Development
Corporation, who report a 65% success rate on the flaw hypotheses
generated. Doing a comprehensive search for operating system flaws
requires four steps:
Step 1) Knowledge of system control structure.
===============================================
To find security holes, and identifying design weaknesses it is
necessary to understand the system control structure, and layers.
One should be able to list the:
A) security objects: items to be protected. ie: a users file.
B) control objects: items that protect security objects. ie: a i-node
C) mutual objects : objects in both classes. ie: the password file
With such a list, it is possible to graphically represent a control
hierarchy and identify potential points of attack. Making flow charts
to give a visual breakdown of relationships definitely helps.
Reading the various users, operators, and administrators manuals should
provide this information.
(following para's should probably be moved to a "legal" section)
Reading and greping source code should also prove valuable. For those
without a source licence, I would suggest we use LINUX, NET2, and BSD386
distributions in order to stay legal. At some future time we may be able
to form a working contract between someone or a company with legal access
to other distributions and members actively participating in this project.
It appears that extracts of proprietary code may be used for academic
study, so long as they are not reused in a commercial product - more
checking is necessary though.
Step 2) Generate an inventory of suspected flaws. (i.e. flaw hypotheses)
========================================================================
In particular we want:
Code history:
What UNIX src does a particular flavor derive from? This is important
for cross references (very often only one vendor patches certain code,
which may get reused, in it's unpatched reincarnation by others)
A solid cross reference:
Who checked which bug in what OS and what version prevents us from
duplicating work.
A good start would be listing all the suid binaries on the various OS
flavors/versions. Then try to work out why each program is suid. i.e.:
rcp is suid root because it must use a privilaged port to do user
name authentication.
Often code that was never designed to be suid, is made suid, durring
porting to solve file access problems.
We need to develope a data base that will be able to look at pairs and
triplets of data, specificly: program name, suid, sgid, object accessed
(why prog is suid/sgid), OS flavor/version, and flav/vers geniology.
Any sugestions on how to implement such a DB?
Step 3) Confirm hypotheses. (test and exploit flaws)
Step 4) Make generalizations of the underlying system weaknesses, for
which the flaw represents a specific instance.
No comments:
Post a Comment