From: Jeff Graham <[email protected]>
Message-Id: <[email protected]>
Subject: FAQ revision 0.9
To: [email protected] (security audit)
Date: Fri, 2 Oct 1998 14:20:45 -0700 (PDT)
I have removed most of the << references and made some proceedural
changes in how to do things. Please drop me a note if you see anything
that should be changed. Thank you.
Archive-name: security-audit-faq
Security-Audit's Frequently Asked Questions
$Id: audit-faq,v 0.9 1998/10/02 21:18:38 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 '*'.
The current FAQ maintainer is Jeff Graham <[email protected]>. All
corrections, submissions and FAQ administration-related messages should
go to this address (for now.)
------------------------------------------------------------------------
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
[email protected]. 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=[email protected], so for
instance to subscribe [email protected] you would send to
security-audit-subscribe-mylogin=[email protected]. 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
[email protected] address. Anything you send there
will be sent to the list.
To unsubscribe from this mailing list, send an empty note to
[email protected].
There is not a digest form of security-audit at this time.
The latest version of the FAQ (this file) will be posted to the list
once a month and will also be available at:
http://www-jcr.lmh.ox.ac.uk./~security
-------------------------------------------------------------------------
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.3) Are there any archives for the security-audit list?
There is an unofficial archive of the mailing list at:
http://www.nas.nasa.gov/Pubs/Mail/archive/linux-security-audit/
It was started 2 days after the creating of the mailing list.
The maintainer is: Tyler Allison <[email protected]>
There is a site that has all fixes discussed in RedHat RPM format at
ftp://ftp.uk.linux.org/pub/linux/alan/Security.
-------------------------------------------------------------------------
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.5) What other security resources are available?
Some resources:
FTP:
coast.cs.purdue.edu
ftp.cert.org
ftp.redhat.com
ftp.tux.org (/pub/dclug/jam or /pub/tux/jam)
ftp.linux.org.uk (/pub/linux/alan/Security NON OFFICIAL)
HTTP:
http://www.eds.org/audit
http://www.aoy.com/Linux/Security
http://www.l0pht.com/
http://www.sun.com/sunsolveonline (some secure programs
references)
http://seclab.cs.ucdavis.edu/~bishop/
http://www.sun.com/sunworldonline/swol-04-1998/swol-04\
-security.html
http://rootshell.connectnet.com/docs/
http://www.rootshell.com/
http://ferret.lmh.ox.ac.uk/~chris/rhbugs.txt
http://olympus.cs.ucdavis.edu/~bishop/secprog.html
http://www.false.com/security/linux
http://www.cs.colorado.edu/homes/zorn/public_html\
/MallocDebug.html
MAIL ADDRESSES:
[email protected] (for reporting of NetKit bugs)
MAIL LISTS:
[email protected]
[email protected]
[email protected]
[email protected] (for Pluggable Authentication Module
info)
RFC:
rfc 1244
rfc 2196 obsoletes RFC 1244
MAILING LIST ARCHIVE:
http://www.nas.nasa.gov/Pubs/Mail/archive/linux-security-audit/
http://www2.merton.ox.ac.uk/~securtiy/ (also has some Bugtraq
and linux-security as well)
MISC SECURITY RELATED ARCHIVES:
http://www.phrack.com/Archives/
-------------------------------------------------------------------------
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
-------------------------------------------------------------------------
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 ([email protected])
You should take a look at:
http://www.pobox.com/~kragen/security-holes.html for an idea of what
sort of thing you should be looking for. 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)
sprintf, strcat, strcpy, scanf, memcpy, [^f]gets, open
creat, system, popen, exec.p, s[gu]id, getenv, chown
chmod
This section mainly from [email protected]
You can try throwing random streams of characters or X
events at applications and see if they crash or hang.
There is a study at:
<http://www.cs.wisc.edu/~bart/fuzz/fuzz.html>
You can do chattr +a tmp and wait for a ton of programs
to scream at you that it cannot "unlink: operation not
permitted". (submitted by Chris Evans
<[email protected]>).
-------------------------------------------------------------------------
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 <[email protected]>
for the information in this section (and other changes)). Available
from: ftp://larch.lcs.mit.edu/pub/Larch/lclint, last version (2.3i) Sep
1997. (This is a late alpha/early beta in Dr. Brands opinion.)
LCLint is also available at http://www.sds.lcs.mit.edu/lclint/
Slint (http://www.l0pht.com/slint.html)
Slint is a commercial product.
gcc -Wall
-------------------------------------------------------------------------
Subject: 2.6) Where are some secure programming references?
You can find some secure programming references at:
http://www.sun.com/sunworldonline/swol-04-1998/swol-04-unixsecurity.html
http://www.sun.com/sunworldonline/swol-04-1998/swol-04-security.html
http://www.homeport.org/~adam/review.html
http://olympus.cs.ucdavis.edu/~bishop/secprog.html
http://www.research.att.com/~smb/talks/odds.[ps|pdf]
http://www.pobox.com/~kragen/security-holes.txt
Chapter 22 in "Practical UNIX & Internet Security" is called "Writing
Secure SUID and Network Programs".
"Writing Solid Code", published by Microsoft Press (I forget the
author). The book actually focuses on writing bug-free software, and
not on security issues, but there's definitely a large overlap there.
Take the SANS course on security programming taught by Matt Bishop. It
is very highly rated by those that have attended.
See www.sans.org for locations and dates.
Thanks to:
Tom Hall <[email protected]>
Marko Milivojevic <[email protected]>
Wilson Roberto Afonso <[email protected]>
Joseph Pung <[email protected]>
Doug Hughes <[email protected]>
Kragen <[email protected]>
Steven M. Bellovin <[email protected]>
Aleph One <[email protected]>
-------------------------------------------------------------------------
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 [email protected] or [email protected] 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.
-------------------------------------------------------------------------
4. Other security information.
-------------------------------------------------------------------------
Subject: 4.1) What about encrypted file systems?
There are various in progress encrypted file systems some of which you
can find detailed here:
CFS: ftp://ftp.research.att.com/dist/mab (read the README file)
Reportedly this encrypts directories as well.
Transparent Cryptographic Filesystem:
http://tcfs.dia.unisa.it/
has PAM support for auth as well as support for encrypted
NFS.
DES encryption with loopback:
ftp://ftp.csua.berkeley.edu/pub/cypherpunks/filesystems/linux
Patches for DES encryption with loopback:
ftp://ftp.is.co.za/linux/local/kernel/crypto/\
loopback-device-berkeley-recent/
Patches for 2.1 series kernels:
ftp://ftp.is.co.za/linux/local/kernel/crypto/\
loopback-device-aem/
-------------------------------------------------------------------------
Subject: 4.2) What are some automatic tools I can use to improve
security?
There are a number of things that will "automatically" help to improve
security both while programming and on systems.
These include (but are not limited to):
StackGuard
bounds-checking gcc
LD_PRELOAD checks that will catch /tmp openings and chroot()
dmalloc
StackGuard
This tool is specifically designed to help defend against stack
smashing attacks. Available at:
http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/
Other sites that may be relevant:
http://www.cygnus.com/ml/egcs/1998-May/0073.html
http://www.cygnus.com/ml/egcs/1998-May/0557.html
http://www.cygnus.com/ml/egcs/1998-May/0559.html
Bounds-checking gcc
This compiler does full bounds-checking of arrays in C. Not very
stable or mature but relevant. Available at:
http://www-ala.doc.ic.ac.uk/~phjk/BoundsChecking.html
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:
http://www.letters.com/dmalloc/ << would someone send me a description
of this please? >>
-- Jeffrey Graham | PGP public key by request Senior Systems Administrator (UNIX) |