Archive-name: security-audit-faq
Security-Audit's Frequently Asked Questions (released)
$Id: audit-faq,v 1.7 1999/07/17 18:09:52 demit Exp $
This is a collection of common questions posted to the security-audit
mailing list once a month. It is intended to reduce the traffic to this
list by providing quick answers to common questions.
This is a blatant rip off of the format of the sun-managers FAQ which
itself credits a similar FAQ for comp.windows.x (can we say rfc for faqs
maybe?), questions marked with a '+' indicate questions new to this
version; those with significant changes of content since the last
version are marked by '*'; those with minor changes of content that may
be of interest are marked by '-'.
The current FAQ maintainer is Jeff Graham <demit@best.com>. All
corrections, submissions and FAQ administration-related messages should
go to this address (for now.)
Additional content and HTML conversion added by Greg Patterson
<gomer@gomer.mlink.net>
------------------------------------------------------------------------
Questions
1. The Security-Audit Mailing list.
1.1) How do I read, join, post to, or remove myself from the
security-audit mailing list?
1.2) What is the purpose of this list?
1.3) Are there any archives for the security-audit list?
1.4) What should I post to this list?
1.5) What other security resources are available?
1.6) What sort of thing is considered "off topic" for the list?
1.7) What programs have been "fixed" by the audit?
2. Bugs and what to do about them.
2.1) I have found a bug, what should I do?
2.2) I reported a bug to the programmer(s) and never got an
answer, what should I do now?
2.3) I think this is a bug, but I am not sure. What should I
do?
2.4) What kind of things should I be looking for?
2.5) Are there any tools that can help me check for bugs?
2.6) Where are some secure programming references?
3. Auditing tasks.
3.1) How do I suggest something I feel needs auditing but do
not have time to do myself?
3.2) How can I find something that needs auditing and is not
currently being worked on by anyone?
4. Other security information.
4.1) What about encrypted file systems?
4.2) What are some automatic tools I can use to improve
security?
-------------------------------------------------------------------------
Answers
-------------------------------------------------------------------------
-------------------------------------------------------------------------
1. The Security-Audit Mailing list
-------------------------------------------------------------------------
Subject: 1.1) How do I read, join, post to, or remove myself from the
security-audit mailing list.
To read this mailing list you must be subscribed as mentioned below.
To subscribe to this mailing list you should send an empty note to
<security-audit-subscribe@ferret.lmh.ox.ac.uk>. Once you send a mail to
this address, you will receive a mail back as confirmation that you wish
to subscribe, if your mail program understands Reply-To headers, all you
have to do is hit reply (you don't even need to send the body of it
back). Once this is done, you are subscribed.
To subscribe other addresses send mail to
<security-audit-subscribe-USER=host.domain@ferret.lmh.ox.ac.uk>, so for
instance to subscribe mylogin@myhost.com you would send to
<security-audit-subscribe-mylogin=myhost.com@ferret.lmh.ox.ac.uk>. When
subscribing other addresses than the one you are mailing from, the
"other" address will receive a confirmation message which will need to
be replied to.
To post to the Security-audit mailing list you just send mail to the
<security-audit@ferret.lmh.ox.ac.uk> address. Anything you send there
will be sent to the list.
To unsubscribe from this mailing list, send an empty note to
<security-audit-unsubscribe@ferret.lmh.ox.ac.uk>.
There is not a digest form of security-audit at this time.
-------------------------------------------------------------------------
Subject: 1.2) What is the purpose of this list?
This list has been formed to coordinate a group of people who are
attempting to make the linux operating system more secure. This is
being done by reviewing commonly run code for security issues. This
group of people is all volunteers and is doing this project on their own
time (for now.) The group is attempting to make a sort of "verified"
linux. This is a massive task but every fix that is put in place is one
less exploit waiting to happen.
-------------------------------------------------------------------------
Subject: 1.4) What should I post to this list?
The list is currently open so you can post anything you wish to the
list. However, unless you wish to start a flame war against yourself
you may wish to stay at least marginally on topic. Typically things
that should be posted to the list included: bugs found, requests for
information on questionable code, packages/programs you are currently
auditing (including messages like "Is anyone already auditing XXX?",)
ideas for auditing techniques, and so on. Please try to keep your posts
succinct and try to keep the included amount of code to revelant
amounts.
-------------------------------------------------------------------------
Subject: 1.6) What sort of thing is considered "off topic" for the list?
How do I configure my machine to be secure?
How do I set up ipfwadm to reject packets from a specific
host?
BIOS and boot security prior to Linux being loaded.
Where do I find the current release of "bind" for XXX Linux?
-------------------------------------------------------------------------
Subject: 1.7) What programs have been "fixed" by the audit?
A partial list of programs that have had bugs identified in them is:
dosemu
ncurses
slang (setfsuid issue - current slang already fixed $TERM)
termcap
metamail
tin
bsd games
elm
Note: this list is old and there have been MANY MANY more bugs found and
fixed by the LSAP. The LSAP is your friend, the LSAP knows all, the
LSAP wants to know if you have found any communists.
-------------------------------------------------------------------------
2. Bugs and what to do about them.
-------------------------------------------------------------------------
Subject: 2.1) I have found a bug, what should I do?
The first thing you should do is try to verify the bug on other
systems, making sure that the bug is actually what you think it is. The
next thing is you should report the bug to the programmer(s) or
maintainer of the software. Reporting the bug to the maintainer does
not gather as much "glory" for being an 3r334 (elite) cracker, but is the
responsible thing to do. If this does not work see Subject: 2.2 below.
When you report the bug to the programmer(s) you are giving them a
chance to repair the bug before it becomes general knowledge. When you
just release the bug to the public, you are actually endangering
systems. The amount of endangerment is dependent on the severity of the
bug.
When reporting a bug please be complete on your report, mention OS
version, system information, what you found, how you verified it and
other information in a similar vein.
If you can, sending a patch will be appreciated.
-------------------------------------------------------------------------
Subject: 2.2) I reported a bug to the programmer(s) and never got an
answer, what should I do now?
Now it is time to start considering either patching the program
yourself, or other measures. If you do not feel comfortable patching
yourself (or cannot due to licensing restrictions), about the only thing
you can do is release it to the public. The best venue to start with is
a smaller venue (such as this list), as some people on this list may be
able to exert a little more pressure on the person (or may actually know
or BE the person).
If this fails, you can release to bugtraq. This one is almost SURE to
get a response. It is a pretty sure way to get a response but is also a
very irresponsible first action. Please try to exhaust all other
resources and methods before doing this.
-------------------------------------------------------------------------
Subject: 2.3) I think this is a bug, but I am not sure. What should I
do?
This one is a little more tricky than the reported bug problem. You
have to try to strike a balance between exposing an actual bug and
giving enough information to get some help with figuring it out. It
helps if you are succinct. You can also just ask for people who know
about what you think is a bug and maybe take it "private."
The idea is not to give the bad guys a shot at exploiting the bug
before a fix is available.
-------------------------------------------------------------------------
Subject: 2.4) What kind of things should I be looking for?
First an administrative note: If you know of anythings that should be
being looked for in general and they are not on this list please email
me <demit@best.com>
You should take a look at:
Note: this is not a complete
document (as mentioned in the document itself.) Kragen is probably open
to suggestions on improvements to this so even if you don't need it, you
may wish to take a look at it and help improve it.
ADMIN NOTE: Thanks to Dr. Brand for input on many things below.
A partial list of what should be being looked for is:
/tmp race conditions (unsafe /tmp/blah-foo$$ opens)
If a program creates a file in /tmp (or other world/group-writable
directories) and then uses it later, it might be stolen or exchanged for
another one by the attacker with right timing. Examples have been files
created SUID +rwx for others that are stolen and filled in with a copy
of /bin/sh, files created and then given privileges that were exchanged
for copies of a shell that ended up privileged, files that a process
fills with data that are then exchanged for doctored files before the
data is used. Can be prevented by sticky bit on the directory itself,
but beware if the whole directory can be moved and replaced (i.e., the
parent can be written by anyone, or replaced by a symlink).
The following is from Kragen:
The largest class of /tmp races I've seen lately come from creating a
new file in /tmp with open() without using O_EXCL, which means that if
there's a file already there -- perhaps owned by someone else or with
lousy permissions -- it will be used, and can therefore be used to (a)
read private information (b) write untrustworthy information. Sticky
bit doesn't help a bit here.
This class of bugs can be reduced somewhat by using a special open()
that checks to see if we're writing into a world-writable directory,
and if so, sticks O_EXCL on the open().
Passing sensitive information between processes
Symlink following
This is the case where somebody runs a SUID/SGID program making one of
its outputs a symlink to a file to be overwritten/damaged. e.g.,
somehow get /var/log/messages to be a symlink to /etc/passwd will make
the system unusable (or in some cases force authentication to fall back
on a secondary mechanism that may be undesired (such as root in nis));
or a specially contrived syslog message could replace the passwd file
with a UID=0 account. If done to an input, it might enable the attacker
to read files that should be protected (e.g., /etc/shadow).
Buffer overruns (especially in suid/sgid processes)
This involves writing over the end of some buffer, thus damaging other
variables that happen to be defined before. In the worst cases, this
can lead to overwriting the return address of the function containing
the buffer (assuming the stack of the machine grows downwards, as it
almost always does), either causing a crash or getting the affected
function to "return" to somewhere else, like the start of the
'exec("/bin/sh", ...)' that is in libc for system(3) (giving a shell) or
something similar that the attacker could build up himself. This is
usually called "stack smashing." Typical attacks involve overlong
strings that are written into buffers without length checking. Many
functions in the C library don't check for buffer lengths, and are thus
exploitable. Examples include strcpy(3) strcat(3), sprintf(3),
getwd(3), gets(3). There are replacement functions available that do
check the lengths of what they are writing: strncpy(3), strncat(3),
snprintf(3) (or use the format to limit the length), getcwd(3),
fgets(3). At least glibc-2.0.94 does complain on linking if several of
the dangerous functions are used in a program. The right solution is
probably not just to rely on the cutoff done by functions that limit the
writing into buffers, but to check beforehand since a string mutilated
by chopping off its end might do other damage elsewhere.
Bad permissions on conf and other files (world/group writable)
Things like a world writable /etc/passwd are VERY dangerous. If you do
not know why I would suggest getting UNIX and Internet Security 2nd
edition from O'Reilly and Associates.
Not releasing suid/sgid when no longer needed
Not zeroing memory (such as passing plain text passwords)
Buffer overflows from untrusted sources
Examples: Environment variables, input from a network, program
arguments, etc) which may be passed to the following functions:
(including but not limited to):
sprintf, strcat, strcpy, scanf, memcpy, [^f]gets, open
creat, system, popen, exec.p, s[gu]id, getenv, chown
chmod
You can try throwing random streams of characters or X
events at applications and see if they crash or hang.
-------------------------------------------------------------------------
Subject: 2.5) Are there any tools that can help me check for bugs?
LCLint - Forces you to write code with annotations, which it then uses
to guide the checking of the code. If the code wasn't written with the
peculiar style and hand in hand with the annotations it demands,
you'll just get huge amounts of useless complaints. Some users report
that they were unable to write code for specific instances that did not
give errors. (thanks to Dr. Horst H. von Brand <vonbrand@inf.utfsm.cl>
for the information in this section (and other changes)).
A core product to be sold into an existing GUI development package.
Helps people be proactive while writing secure code by
highlighting potentional hot spots of exploitable routines and
poor memory allocations.
Identifies suspect blocks of code.
Makes the task of security review more paletable so you don't
need a team of high-level experts to go through megabytes of
code.
Supplies solutions and/or alternatives to problem areas.
Most security problems could have been fixed at the beginning
of development. Secure applications must start with a secure
base. The Best *BANG* for the buck is to be proactive at the
start of program creation.
Easy to implement into existing Y2K code review packages.
Slint is a commercial product of L0pht Industries.
gcc -Wall
Run the GNU gcc compiler with -Wall argument to enable all compiler
warning messages. This can help trap many problems in your code.
[e]grep 
-------------------------------------------------------------------------
3. Auditing tasks.
-------------------------------------------------------------------------
Subject: 3.1) How do I suggest something I feel needs auditing but do
not have time to do myself?
You can suggest it to the list for possible review by auditing members.
Things will be worked on by people as they have the time. Please bear
in mind that this security project is HUGE and is not really limiting
itself to the linux community, we are using linux as the os we are
fixing things on but the fixes are going into the programs and not just
the kernel. If you have seen no action for maybe a month (or if you
feel this is a critical bug (for instance one that allows root access,)
you can contact me at jeff@kodenkan.com or demit@best.com directly, I'll
attempt to route it to whoever is handling things of this sort,) you
can repost it to the list.
-------------------------------------------------------------------------
Subject: 3.2) How can I find something that needs auditing and is not
currently being worked on by anyone?
You will have to follow the list for suggestions of what to do. If you
are really eager to get started, just post a message to the list asking
what people would like to see done. Alternatively, you can follow the
list and wait until someone asks for a package to be audited or for
someone else to ask for help in their audit.
-------------------------------------------------------------------------
Electric fence, checker, ccmalloc, and mpr are available on
sunsite.unc.edu in /pub/Linux/devel/lang/c:
Electric Fence:
Electric Fence is a different kind of malloc() debugger. It uses the
virtual memory hardware of your system to detect when software overruns
the boundaries of a malloc() buffer. It will also detect any accesses
of memory that has been released by free(). Because it uses the VM
hardware for detection, Electric Fence stops your program on the first
instruction that causes a bounds violation. It's then trivial to use a
debugger to display the offending statement.
checker:
checker - Memory access debugger for C language development
Drop-in addition to `gcc' that allows programmers to find most
memory-related bugs easily. Checker automatically finds:
* null pointer dereferences (read, write, and execute accesses)
* writes to read-only memory
* accesses to free blocks (read, write, and execute)
* reads/writes to uninitialized bytes (in automatic and dynamic
memory)
* reads/writes to "red zones" (in automatic and dynamic memory)
* reads/writes/executes outside memory segments
* free called with address not obtained from malloc
* free an already freed block
* ...and many more!
Checker's main disadvantage is that it causes the program to run many
times slower. You can compile your program to use Checker by using
the command `checkergcc' in place of `gcc'. Please do read the
documentation, it contains some important information.
ccmalloc:
ccmalloc - A memory profiler/debugger
This is a memory profiling package. It can be used to debug various
memory allocation problems, including:
o memory leaks
o multiple deallocation of the same data
o under writes and over writes
o writes to already deallocated data
mpr:
mpr can be used to find malloc/realloc memory leaks and memory
allocation statistics and patterns - it does not find memory
corruption errors. It uses a simple, brute force strategy - log all
memory alloc/free requests to a file and then post-process this log
file once the program has terminated.
mpr keeps track of the entire call chain leading up to a memory
alloc/free request, making it much easier to find memory allocation
problems. This is superior to conventional methods of keeping track of
only the immediate caller of a memory alloc/free routine, e.g. using
__FILE__ and __LINE__.
dmalloc:
The debug memory allocation or dmalloc library has been designed as a
drop in replacement for the system's malloc, realloc, calloc, free and
other memory management routines while providing powerful debugging
facilities configurable at runtime. These facilities include such
things as memory-leak tracking, fence-post write detection, file/line
number reporting, and general logging of statistics.
The library is reasonably portable having been run successfully on at
least the following operating systems: AIX, BSDI, DG/UX, FreeBSD, HPUX,
Irix, Linux, MS-DOG, NeXT, OSF, SCO, Solaris, SunOS, Ultrix, Unixware,
Windows and even Unicos on a Cray Y-MP. It also provides support for
the debugging of threaded programs.
The package includes the library, configuration scripts, debug utility
application, test program, and extensive documentation (formats: text,
texi, info, and ps).
Multi-stack allocator (technique for ecgs) (patch and run-time lib):
"Multi-stack" is a technique of allocating local arrays to prevent
exploits for most of the buffer overflows. It is NOT a complete
solution for buffer overflows.
--
Jeffery Graham - Senior Systems Administrator (UNIX)
PGP public key available by request