os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

The new FreeBSD Security homepage.

Browse source 
Submitted by: guido
This commit is contained in:
Wolfram Schneider 1998-06-19 09:46:53 +00:00
parent aea44d65d6
commit 80d71116c1
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/www/; revision=2970
10 changed files with 1218 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
data/security/Makefile Normal file
View file

@ -0,0 +1,12 @@
# $Id: Makefile,v 1.1 1998-06-19 09:46:48 wosch Exp $
.if exists(Makefile.conf)
.include "Makefile.conf"
.endif
DOCS=
DOCS+= programmers.sgml
DOCS+= security.sgml
DOCS+= secure.sgml
.include "../web.mk"

205
data/security/programmers.html Normal file
View file

@ -0,0 +1,205 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>Security Do's and Don'ts for Programmers</TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" ALINK="#FFCC33"><IMG SRC="../gifs/bar.gif" ALT="Navigation Bar" HEIGHT="33" WIDTH="565" BORDER="0" USEMAP="#bar">
<H1 ALIGN="LEFT"><FONT COLOR="#660000">Security Do's and Don'ts for Programmers</FONT></H1><BR CLEAR="ALL">
<MAP NAME="bar">
<AREA SHAPE="RECT" COORDS="1,1,111,31" HREF="../index.html" ALT="Top">
<AREA SHAPE="RECT" COORDS="112,11,196,31" HREF="../ports/index.html" ALT="Applications">
<AREA SHAPE="RECT" COORDS="196,12,257,33" HREF="../support.html" ALT="Support">
<AREA SHAPE="RECT" COORDS="256,12,365,33" HREF="../docs.html" ALT="Documentation">
<AREA SHAPE="RECT" COORDS="366,13,424,32" HREF="../commercial.html" ALT="Vendors">
<AREA SHAPE="RECT" COORDS="425,16,475,32" HREF="../search.html" ALT="Search">
<AREA SHAPE="RECT" COORDS="477,16,516,33" HREF="../index-site.html" ALT="Index">
<AREA SHAPE="RECT" COORDS="516,15,562,33" HREF="../index.html" ALT="Top">
<AREA SHAPE="RECT" COORDS="0,0,564,32" HREF="../index.html" ALT="Top">
</MAP>
<P></P><UL>
<LI><A NAME="#rule1"></A>Never trust any source of input, i.e. command line
arguments, environment variables, configuration files, incoming UDP packets,
hostname lookups, function arguments, etc. If the length or contents of
the data received is at all subject to outside control then the program
or function should watch for this when copying it around. Specific
security issues to watch for in this area are:
<P></P><UL>
<LI><A NAME="#rule1_1"></A>strcpy() and sprintf() calls from
unbounded data. Use strncpy() and snprintf() when the length is known
(or implement some other form of bounds-checking when it's not).
In fact, never use gets(3) or sprintf(3), period.
<P></P></LI>
<LI><A NAME="#rule1_1"></A>strncpy() and strncat() calls. Be sure
you understand how these work\! strncpy() might not append a terminating
\\0 while strncat() always adds the \\0.
<P></P></LI>
<LI><A NAME="#rule1_2"></A>Watch for strvis(3) and getenv(3) abuse.
strvis() is easy to get the destination string wrong for, and getenv()
can return strings much longer than the user might expect - they are
one of the key ways an attack is often made on a program, causing it
to overwrite stack or variables by setting its environment variables
to unexpected values. If your program reads environment variables,
be paranoid!
<P></P></LI>
<LI>Every time you see an open(2) or stat(2) call, ask yourself, "What
if it's a symbolic link?"
<P></P></LI>
<LI><A NAME="#rule1_3"></A>All uses of mktemp(), tempnam(), mkstemp(),
etc.; make sure that they use mkstemp() instead. Also look for races in
/tmp in general, being aware that there are very few things can be atomic
in /tmp:
<UL>
<LI>Creating a directory. This will either succeed or fail.
</LI>
<LI>Opening a file O_CREAT | O_EXCL
</LI>
</UL>
mkstemp(3) properly handles this for you, so all temp files should
use mkstemp to guarantee there's no race and that the permissions
are right.
<P></P></LI>
<LI><A NAME="#rule1_4"></A>If an attacker can force packets to go/come
from another arbitrary system then that hacker has complete control
over the data that we get and *NONE* of it should be trusted.
<P></P></LI>
<LI><A NAME="#rule1_5"></A>Understand the differences between uid,
euid and svuid in 2.1 and 2.2. We sure don't. [XXX but we should find out
and fill this in after talking to Bruce]
<P></P></LI>
<LI><A NAME="#rule1_6"></A>Never trust that a config file is correctly
formatted or that it was generated by the appropriate utility. If there
is some chance for being sneaky, then some twisted cracker will try
to be sneaky: Don't trust user input like terminal names or language
strings to be free of '/' or ../../... embedded if there is any chance
that they can be used in a path name. Don't trust *ANY* paths supplied
by the user when you are running setuid root.
<P></P></LI>
<LI><A NAME="#rule1_7"></A>Look for holes or weaknesses in how data
is stored. All temp files should be 600 permission.
<P></P></LI>
<LI><A NAME="#rule1_8"></A>Don't just grep for the usual suspects
in programs which run at elevated privs. Look line by line for possible
overflows in these cases since there are a lot more ways than strcpy()
and friends to cause buffer overflows.
<P></P></LI>
<LI><A NAME="#rule1_9"></A>Just because you drop privs somewhere doesn't
necessarily mean that no exploit is possible. The attacker may put the
necessary code on the stack to regain them before execing /bin/sh.
</LI>
</UL>
<P></P></LI>
<LI><A NAME="#rule2"></A>Do uid management. So drop privs as soon as possible,
and really drop them. Switching between euid and uid is not enough. Use
setuid() when you can.
<P></P></LI>
<LI><A NAME="#rule3"></A>Never display configuration file contents on errors.
A line number and perhaps position count is enough. This is true for all
libs and for any SUID/SGID program.
<P></P></LI>
<LI><A NAME="#rule4"></A>Tips for those reviewing existing code for security
problems:
<P></P><UL>
<LI><A NAME="#rule4_1"></A>If you're unsure of your security fixes, send them
to a reviewer with whom you've already made arrangements for a second glance
over. Don't commit code you're not sure of since breaking something in
the name of securing it is rather embarrassing. :)
<P></P></LI>
<LI><A NAME="#rule4_2"></A>Those without CVS commit privileges should make
sure that a reviewer with such privileges is among the last to review the
changes. That person will both review and incorporate the final version
you would like to have go into the tree.
<P></P></LI>
<LI><A NAME="#rule4_3"></A>When sending changes around for review, always
use context or unidiff format diffs which may be easily fed to patch(1).
Do not simply send whole files! Diffs are much easier to read and apply to
local sources (especially those in which multiple, simultaneous changes
may be taking place). All changes should be relative to 3.0-current
just so we can all be working from a common base, unless there is strong
reason in a specific instance to do otherwise.
<P></P></LI>
<LI><A NAME="#rule4_4"></A>Always directly test your changes (e.g. build and
run the affected module(s)) before sending them to a reviewer; no one likes
being sent obviously broken stuff for review, and it just makes it appear
as though the submitter didn't even really look at what he was
doing (which is hardly confidence-building). If you need accounts
on a 2.1, 2.2 or 3.0 machine in order to do proper testing, just
ask - the project has such resources available for just such
purposes.
<P></P></LI>
<LI><A NAME="#rule4_5"></A>For committers: Be sure to retrofit -current
patches into the 2.2 and 2.1 branches as appropriate.
<P></P></LI>
<LI><A NAME="#rule4_6"></A>Do not needlessly rewrite code to suit
your style/tastes - it only makes the reviewer's job needlessly more
difficult. Do so only if there are clear technical reasons for it.
</LI>
</UL>
<P></P></LI>
<LI><A NAME="#rule5"></A>Look out for programs doing complex things in
signal handlers. Many routines in the various libraries are not
sufficiently reentrant to make this safe.
<P></P></LI>
<LI><A NAME="#rule6"></A>Pay special attention to realloc() usage - more
often than not, it's not done correctly.
<P></P></LI>
<LI>When using fixed-size buffers, use sizeof() to prevent lossage when
a buffer size is changed but the code which uses it isn't. For example:
<LISTING> char buf[1024];
struct foo { ... };
...
BAD:
xxx(buf, 1024)
xxx(yyy, sizeof(struct foo))
GOOD:
xxx(buf, sizeof(buf))
xxx(yyy, sizeof(yyy))</LISTING>
Be careful though with sizeof of pointers when you really want the size
of where it points to\!
<P></P></LI>
<LI>Every time you see "char foo[###]", check every usage of foo to
make sure it can't be overflowed. If you can't avoid overflow
(and cases of this have been seen) then at least malloc the buffer
so you can't walk on the stack.
<P></P></LI>
<LI>Always close file descriptors as soon as you can -- this makes it
more likely that the stdio buffer contents will be discarded. In
library routines, always set any file descriptors that you open to
close-on-exec.
<P></P></LI>
</UL>
<HR NOSHADE>
<ADDRESS><A HREF="../mailto.html">questions@FreeBSD.ORG</A><BR>
Copyright © 1995-1998 FreeBSD Inc.
All rights reserved.<BR>$Date: 1998-06-19 09:46:50 $</ADDRESS> </BODY>
</HTML>

60
data/security/secure.sgml Normal file
View file

@ -0,0 +1,60 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN" [
<!ENTITY base CDATA "..">
<!ENTITY date "$Date: 1998-06-19 09:46:52 $">
<!ENTITY title "How to secure a FreeBSD system">
<!ENTITY % includes SYSTEM "../includes.sgml"> %includes;
]>
<!-- $Id: secure.sgml,v 1.1 1998-06-19 09:46:52 wosch Exp $ -->
<html>
&header;
There are several steps involved in securing a FreeBSD system, or in
fact any UNIX system:
<UL>
<LI>disabling potentially dangerous software<BR>
A lot of software has to be run as a special privileged user to make use
of specific resources, bij making
the executable set-uid. An example is UUCP software or PPP
software that makes use of a serial port, or sendmail which has to write
in the mail spool and bind to a network port. When you are not using
UUCP, it is of little use to have the software on your system and it may
be wise to disable it. Of course, this requires good knowlegde of what
can be thrown away and what not, as well as a good indication whether or
not you will want the functionality in the future.<BR>
Also some utilities you may find not interesting enough to have them
around and pose a possible security risk, like swapinfo. If you remove
the set-uid bit for the executable (via chmod ug-s filename) you
can always keep on using swapinfo when you're root. It is however
not a good idea stripping so many sbits you have to be root all
the time.<BR>
Not only remove programs that you don't use, also remove services you
don't want or need to provide. This can be done by editting the
<TT>/etc/inetd.conf</TT> file and uncommenting out all services you
don't use.
<LI>fixing software with security bugs<BR>
Subscribe yourself to mailinglist to get updates on security bugs in
software and to get the fixes. Apply them immediately.
<LI>checking your system on a regular basis<BR>
With programs like COPS and SATAN you can find gaping holes and
misconfigurations on your system. It is a good idea to run them
occasionaly to see if you have made any mistakes.<BR>
Also check the daily security reporting that FreeBSD send to root. Check
the logfiles once in a while. Clean up unused accounts.
<LI>being able to repair your system when security has been breached<BR>
Always have backups and a clean version of the operating system (e.g. on
CD-ROM).
<LI>installing software that watches the system<BR>
Programs like the tcp wrapper (a package with FreeBSD) and tripwire help you
monitor activity on your system. This makes it easier to detect
breakins.
<LI>educating the people working on the system<BR>
Users should know what they are doing, and e.g. use hard to guess
password. Let them understand that the security of the system is partly
in their hands.
</UL>
&footer
</body>
</html>

166
data/security/security.sgml Normal file
View file

@ -0,0 +1,166 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN" [
<!ENTITY base CDATA "..">
<!ENTITY date "$Date: 1998-06-19 09:46:53 $">
<!ENTITY title "FreeBSD Security Guide">
<!ENTITY % includes SYSTEM "../includes.sgml"> %includes;
]>
<!-- $Id: security.sgml,v 1.1 1998-06-19 09:46:53 wosch Exp $ -->
<html>
&header;
<P>This guide attempts to document some of the tips and tricks used by
many FreeBSD security experts for securing systems and writing secure
code. It is designed to help you learn about the various ways of protecting
a FreeBSD system against outside attacks and how to recover from such attacks
if and when they should happen. It also lists the various ways in which
the systems programmer can become more security conscious so he will
less likely introduce security holes in the first place.
</P><P>We welcome your comments on the contents and correctness of this page.
Please send email to the <A HREF="mailto:security-officer@FreeBSD.org">
FreeBSD Security Officers</A> if you have changes you'd like to see here.
</P><H2>The FreeBSD security officer</H2>
As FreeBSD takes security seriously, there is a security officer who is
the focal point for security related communications. The security officers'
main task is to send out advisories when there are known security holes
so FreeBSD users will be able to keep their systems secure. The security
officer also communicates with the various CERTs around the world to
give them information about vulnerabilities within FreeBSD and to receive
information about new ones. As such, the security officer is a member of
<A HREF="http://www.first.org/">FIRST</A>, the Forum of Incident Response
and Security Teams.
<P>
When you contact the security officer about sensitive matters, please use
our <A HREF="ftp://ftp.freebsd.org/pub/CERT/public_key.asc">PGP key</A> to encrypt your
message.
</P><H2>FreeBSD security related information</H2>
If you want to stay up to date on FreeBSD security, you can subscribe
yorself to one of the following mailing lists:
<PRE>
freebsd-security General security related discussion
freebsd-security-notification Security notifications (moderated mailing list)
</PRE>
Send mail to <A HREF="mailto:majordomo@freebsd.org">majordomo@FreeBSD.ORG</A>
with
<PRE>
subscribe &lt;listname&gt; [&lt;optional address&gt;]
</PRE>
in the body of the message in order to subscribe yourself.
<P>
Publications of the FreeBSD security officer can also be found on
<A HREF="ftp://ftp.freebsd.org/pub/CERT/">ftp://ftp.freebsd.org/pub/CERT/</A>
<P>Handbook?
</P><H2>FreeBSD security advisories:</H2>
FreeBSD provides security advisories. The advisories will cover
recent releases of FreeBSD. The security advisories will cover
these releases:
<UL>
<LI> the most recent official release of FreeBSD,
<LI> FreeBSD-current,
<LI> FreeBSD-stable, when 2 releases are based on it.
<LI> the previous FreeBSD-stable in case the new stable does not
yet have 2 releases based on it.
</UL>
At this time, security advisories are available for:
<UL>
<LI> FreeBSD 2.2.6
<LI> FreeBSD-current
<LI> FreeBSD-stable
</UL>
Older releases will not be actively maintained.
<p>
You are encouraged to upgrade to one of the supported releases.
<p>
An advisory will be sent out when a security hole exists that is either being
actively abused (as indicated to us via reports from end users or CERT
like organizations), or when the security hole is public knowledge
(e.g. because a report has been posted to a public mailing list).
<p>
Like all development efforts, security fixes are first brought into the
FreeBSD-current branch. After a couple of days, the fix will be retrofitted
into the covered FreeBSD-stable branch(es). Then an advisory will
be sent out.
<p>
Advisories will be sent to the following FreeBSD mailing lists:
<UL>
<LI> FreeBSD-security-notifications
<LI> FreeBSD-security
<LI> FreeBSD-announce
</UL>
Advisories will always be signed using the FreeBSD security-officer
<A HREF="ftp://ftp.freebsd.org/pub/CERT/public_key.asc">PGP key</A>
<p>
Advisories and patches are archived at our
<A HREF="ftp://ftp.freebsd.org/pub/CERT/">FTP site</A>.
</P>
<H2>What to do when you detect a security compromise </H2>
<UL>
<LI>determine the level of security breack<BR>
What privilege did the attack get? That of another user or more (up to
root privileges)?
<LI>determine the part of the system that is not in its original state
anymore<BR>
What software has been tampered with? You may decide to re-install the
operating system from a safe medium, or you might have MD5 checksums of
the original software with which you can check your system. The tripwire
package keeps MD5 checksums. Be aware that tripwire might be tampered
with as well.
<LI>find out how the breakin was done<BR>
Via a well-known security bug? A misconfiguration? When it's a new bug,
warn the FreeBSD Security Officer.
<LI>fix the hole(s)<BR>
Install new software that fixes the problems. If you aren't able to get
a fix quickly, you can temporarily disable remote access to your system.
</UL>
Other questions you may ask yourself are:
<UL>
<LI>Who do I warn? You can contact the security officer, or even the
local authorities. The choice is up to you.
<LI>Do I want to trace the person responsible? By not fixing the hole
right away, you have a chance to catch the cracker. Then again, you have
the chance the cracker wipes your disk. The choice is up to you.
</UL>
<h2><a href="secure.html">How to secure a FreeBSD system</a></h2>
There are several steps involved in securing a FreeBSD system, or in
fact any UNIX system.
<h2><a href="programmers.html">Security Do's and Don'ts for Programmers</a></h2>
<H2>Other usefull security information:</H2>
<UL>
<LI><A href="http://www.cs.purdue.edu/coast/archive/index.html">The COAST
archive</A>
Contains a huge collection of security related material.
<LI><A href="http://www.cs.purdue.edu/homes/spaf/hotlists/csec.htm">
The COAST Security hotlist</A>
This page is THE place to start looking for security related
material. It contains hundreds of usefull
security pointers. Everything you always wanted to know about
security...and more...
<LI>The various CERTs (e.g. <A href="http://www.cert.org">www.cert.org</A> and
<A href="http://www.auscert.org.au">www.auscert.org.au</A>)
<LI>Mailing lists: Bugtraq, BOS
</ul>
&footer
</body>
</html>

12
en/security/Makefile Normal file
View file

@ -0,0 +1,12 @@
# $Id: Makefile,v 1.1 1998-06-19 09:46:48 wosch Exp $
.if exists(Makefile.conf)
.include "Makefile.conf"
.endif
DOCS=
DOCS+= programmers.sgml
DOCS+= security.sgml
DOCS+= secure.sgml
.include "../web.mk"

166
en/security/advisories.xml Normal file
View file

@ -0,0 +1,166 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN" [
<!ENTITY base CDATA "..">
<!ENTITY date "$Date: 1998-06-19 09:46:53 $">
<!ENTITY title "FreeBSD Security Guide">
<!ENTITY % includes SYSTEM "../includes.sgml"> %includes;
]>
<!-- $Id: advisories.xml,v 1.1 1998-06-19 09:46:53 wosch Exp $ -->
<html>
&header;
<P>This guide attempts to document some of the tips and tricks used by
many FreeBSD security experts for securing systems and writing secure
code. It is designed to help you learn about the various ways of protecting
a FreeBSD system against outside attacks and how to recover from such attacks
if and when they should happen. It also lists the various ways in which
the systems programmer can become more security conscious so he will
less likely introduce security holes in the first place.
</P><P>We welcome your comments on the contents and correctness of this page.
Please send email to the <A HREF="mailto:security-officer@FreeBSD.org">
FreeBSD Security Officers</A> if you have changes you'd like to see here.
</P><H2>The FreeBSD security officer</H2>
As FreeBSD takes security seriously, there is a security officer who is
the focal point for security related communications. The security officers'
main task is to send out advisories when there are known security holes
so FreeBSD users will be able to keep their systems secure. The security
officer also communicates with the various CERTs around the world to
give them information about vulnerabilities within FreeBSD and to receive
information about new ones. As such, the security officer is a member of
<A HREF="http://www.first.org/">FIRST</A>, the Forum of Incident Response
and Security Teams.
<P>
When you contact the security officer about sensitive matters, please use
our <A HREF="ftp://ftp.freebsd.org/pub/CERT/public_key.asc">PGP key</A> to encrypt your
message.
</P><H2>FreeBSD security related information</H2>
If you want to stay up to date on FreeBSD security, you can subscribe
yorself to one of the following mailing lists:
<PRE>
freebsd-security General security related discussion
freebsd-security-notification Security notifications (moderated mailing list)
</PRE>
Send mail to <A HREF="mailto:majordomo@freebsd.org">majordomo@FreeBSD.ORG</A>
with
<PRE>
subscribe &lt;listname&gt; [&lt;optional address&gt;]
</PRE>
in the body of the message in order to subscribe yourself.
<P>
Publications of the FreeBSD security officer can also be found on
<A HREF="ftp://ftp.freebsd.org/pub/CERT/">ftp://ftp.freebsd.org/pub/CERT/</A>
<P>Handbook?
</P><H2>FreeBSD security advisories:</H2>
FreeBSD provides security advisories. The advisories will cover
recent releases of FreeBSD. The security advisories will cover
these releases:
<UL>
<LI> the most recent official release of FreeBSD,
<LI> FreeBSD-current,
<LI> FreeBSD-stable, when 2 releases are based on it.
<LI> the previous FreeBSD-stable in case the new stable does not
yet have 2 releases based on it.
</UL>
At this time, security advisories are available for:
<UL>
<LI> FreeBSD 2.2.6
<LI> FreeBSD-current
<LI> FreeBSD-stable
</UL>
Older releases will not be actively maintained.
<p>
You are encouraged to upgrade to one of the supported releases.
<p>
An advisory will be sent out when a security hole exists that is either being
actively abused (as indicated to us via reports from end users or CERT
like organizations), or when the security hole is public knowledge
(e.g. because a report has been posted to a public mailing list).
<p>
Like all development efforts, security fixes are first brought into the
FreeBSD-current branch. After a couple of days, the fix will be retrofitted
into the covered FreeBSD-stable branch(es). Then an advisory will
be sent out.
<p>
Advisories will be sent to the following FreeBSD mailing lists:
<UL>
<LI> FreeBSD-security-notifications
<LI> FreeBSD-security
<LI> FreeBSD-announce
</UL>
Advisories will always be signed using the FreeBSD security-officer
<A HREF="ftp://ftp.freebsd.org/pub/CERT/public_key.asc">PGP key</A>
<p>
Advisories and patches are archived at our
<A HREF="ftp://ftp.freebsd.org/pub/CERT/">FTP site</A>.
</P>
<H2>What to do when you detect a security compromise </H2>
<UL>
<LI>determine the level of security breack<BR>
What privilege did the attack get? That of another user or more (up to
root privileges)?
<LI>determine the part of the system that is not in its original state
anymore<BR>
What software has been tampered with? You may decide to re-install the
operating system from a safe medium, or you might have MD5 checksums of
the original software with which you can check your system. The tripwire
package keeps MD5 checksums. Be aware that tripwire might be tampered
with as well.
<LI>find out how the breakin was done<BR>
Via a well-known security bug? A misconfiguration? When it's a new bug,
warn the FreeBSD Security Officer.
<LI>fix the hole(s)<BR>
Install new software that fixes the problems. If you aren't able to get
a fix quickly, you can temporarily disable remote access to your system.
</UL>
Other questions you may ask yourself are:
<UL>
<LI>Who do I warn? You can contact the security officer, or even the
local authorities. The choice is up to you.
<LI>Do I want to trace the person responsible? By not fixing the hole
right away, you have a chance to catch the cracker. Then again, you have
the chance the cracker wipes your disk. The choice is up to you.
</UL>
<h2><a href="secure.html">How to secure a FreeBSD system</a></h2>
There are several steps involved in securing a FreeBSD system, or in
fact any UNIX system.
<h2><a href="programmers.html">Security Do's and Don'ts for Programmers</a></h2>
<H2>Other usefull security information:</H2>
<UL>
<LI><A href="http://www.cs.purdue.edu/coast/archive/index.html">The COAST
archive</A>
Contains a huge collection of security related material.
<LI><A href="http://www.cs.purdue.edu/homes/spaf/hotlists/csec.htm">
The COAST Security hotlist</A>
This page is THE place to start looking for security related
material. It contains hundreds of usefull
security pointers. Everything you always wanted to know about
security...and more...
<LI>The various CERTs (e.g. <A href="http://www.cert.org">www.cert.org</A> and
<A href="http://www.auscert.org.au">www.auscert.org.au</A>)
<LI>Mailing lists: Bugtraq, BOS
</ul>
&footer
</body>
</html>

205
en/security/programmers.html Normal file
View file

@ -0,0 +1,205 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>Security Do's and Don'ts for Programmers</TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" ALINK="#FFCC33"><IMG SRC="../gifs/bar.gif" ALT="Navigation Bar" HEIGHT="33" WIDTH="565" BORDER="0" USEMAP="#bar">
<H1 ALIGN="LEFT"><FONT COLOR="#660000">Security Do's and Don'ts for Programmers</FONT></H1><BR CLEAR="ALL">
<MAP NAME="bar">
<AREA SHAPE="RECT" COORDS="1,1,111,31" HREF="../index.html" ALT="Top">
<AREA SHAPE="RECT" COORDS="112,11,196,31" HREF="../ports/index.html" ALT="Applications">
<AREA SHAPE="RECT" COORDS="196,12,257,33" HREF="../support.html" ALT="Support">
<AREA SHAPE="RECT" COORDS="256,12,365,33" HREF="../docs.html" ALT="Documentation">
<AREA SHAPE="RECT" COORDS="366,13,424,32" HREF="../commercial.html" ALT="Vendors">
<AREA SHAPE="RECT" COORDS="425,16,475,32" HREF="../search.html" ALT="Search">
<AREA SHAPE="RECT" COORDS="477,16,516,33" HREF="../index-site.html" ALT="Index">
<AREA SHAPE="RECT" COORDS="516,15,562,33" HREF="../index.html" ALT="Top">
<AREA SHAPE="RECT" COORDS="0,0,564,32" HREF="../index.html" ALT="Top">
</MAP>
<P></P><UL>
<LI><A NAME="#rule1"></A>Never trust any source of input, i.e. command line
arguments, environment variables, configuration files, incoming UDP packets,
hostname lookups, function arguments, etc. If the length or contents of
the data received is at all subject to outside control then the program
or function should watch for this when copying it around. Specific
security issues to watch for in this area are:
<P></P><UL>
<LI><A NAME="#rule1_1"></A>strcpy() and sprintf() calls from
unbounded data. Use strncpy() and snprintf() when the length is known
(or implement some other form of bounds-checking when it's not).
In fact, never use gets(3) or sprintf(3), period.
<P></P></LI>
<LI><A NAME="#rule1_1"></A>strncpy() and strncat() calls. Be sure
you understand how these work\! strncpy() might not append a terminating
\\0 while strncat() always adds the \\0.
<P></P></LI>
<LI><A NAME="#rule1_2"></A>Watch for strvis(3) and getenv(3) abuse.
strvis() is easy to get the destination string wrong for, and getenv()
can return strings much longer than the user might expect - they are
one of the key ways an attack is often made on a program, causing it
to overwrite stack or variables by setting its environment variables
to unexpected values. If your program reads environment variables,
be paranoid!
<P></P></LI>
<LI>Every time you see an open(2) or stat(2) call, ask yourself, "What
if it's a symbolic link?"
<P></P></LI>
<LI><A NAME="#rule1_3"></A>All uses of mktemp(), tempnam(), mkstemp(),
etc.; make sure that they use mkstemp() instead. Also look for races in
/tmp in general, being aware that there are very few things can be atomic
in /tmp:
<UL>
<LI>Creating a directory. This will either succeed or fail.
</LI>
<LI>Opening a file O_CREAT | O_EXCL
</LI>
</UL>
mkstemp(3) properly handles this for you, so all temp files should
use mkstemp to guarantee there's no race and that the permissions
are right.
<P></P></LI>
<LI><A NAME="#rule1_4"></A>If an attacker can force packets to go/come
from another arbitrary system then that hacker has complete control
over the data that we get and *NONE* of it should be trusted.
<P></P></LI>
<LI><A NAME="#rule1_5"></A>Understand the differences between uid,
euid and svuid in 2.1 and 2.2. We sure don't. [XXX but we should find out
and fill this in after talking to Bruce]
<P></P></LI>
<LI><A NAME="#rule1_6"></A>Never trust that a config file is correctly
formatted or that it was generated by the appropriate utility. If there
is some chance for being sneaky, then some twisted cracker will try
to be sneaky: Don't trust user input like terminal names or language
strings to be free of '/' or ../../... embedded if there is any chance
that they can be used in a path name. Don't trust *ANY* paths supplied
by the user when you are running setuid root.
<P></P></LI>
<LI><A NAME="#rule1_7"></A>Look for holes or weaknesses in how data
is stored. All temp files should be 600 permission.
<P></P></LI>
<LI><A NAME="#rule1_8"></A>Don't just grep for the usual suspects
in programs which run at elevated privs. Look line by line for possible
overflows in these cases since there are a lot more ways than strcpy()
and friends to cause buffer overflows.
<P></P></LI>
<LI><A NAME="#rule1_9"></A>Just because you drop privs somewhere doesn't
necessarily mean that no exploit is possible. The attacker may put the
necessary code on the stack to regain them before execing /bin/sh.
</LI>
</UL>
<P></P></LI>
<LI><A NAME="#rule2"></A>Do uid management. So drop privs as soon as possible,
and really drop them. Switching between euid and uid is not enough. Use
setuid() when you can.
<P></P></LI>
<LI><A NAME="#rule3"></A>Never display configuration file contents on errors.
A line number and perhaps position count is enough. This is true for all
libs and for any SUID/SGID program.
<P></P></LI>
<LI><A NAME="#rule4"></A>Tips for those reviewing existing code for security
problems:
<P></P><UL>
<LI><A NAME="#rule4_1"></A>If you're unsure of your security fixes, send them
to a reviewer with whom you've already made arrangements for a second glance
over. Don't commit code you're not sure of since breaking something in
the name of securing it is rather embarrassing. :)
<P></P></LI>
<LI><A NAME="#rule4_2"></A>Those without CVS commit privileges should make
sure that a reviewer with such privileges is among the last to review the
changes. That person will both review and incorporate the final version
you would like to have go into the tree.
<P></P></LI>
<LI><A NAME="#rule4_3"></A>When sending changes around for review, always
use context or unidiff format diffs which may be easily fed to patch(1).
Do not simply send whole files! Diffs are much easier to read and apply to
local sources (especially those in which multiple, simultaneous changes
may be taking place). All changes should be relative to 3.0-current
just so we can all be working from a common base, unless there is strong
reason in a specific instance to do otherwise.
<P></P></LI>
<LI><A NAME="#rule4_4"></A>Always directly test your changes (e.g. build and
run the affected module(s)) before sending them to a reviewer; no one likes
being sent obviously broken stuff for review, and it just makes it appear
as though the submitter didn't even really look at what he was
doing (which is hardly confidence-building). If you need accounts
on a 2.1, 2.2 or 3.0 machine in order to do proper testing, just
ask - the project has such resources available for just such
purposes.
<P></P></LI>
<LI><A NAME="#rule4_5"></A>For committers: Be sure to retrofit -current
patches into the 2.2 and 2.1 branches as appropriate.
<P></P></LI>
<LI><A NAME="#rule4_6"></A>Do not needlessly rewrite code to suit
your style/tastes - it only makes the reviewer's job needlessly more
difficult. Do so only if there are clear technical reasons for it.
</LI>
</UL>
<P></P></LI>
<LI><A NAME="#rule5"></A>Look out for programs doing complex things in
signal handlers. Many routines in the various libraries are not
sufficiently reentrant to make this safe.
<P></P></LI>
<LI><A NAME="#rule6"></A>Pay special attention to realloc() usage - more
often than not, it's not done correctly.
<P></P></LI>
<LI>When using fixed-size buffers, use sizeof() to prevent lossage when
a buffer size is changed but the code which uses it isn't. For example:
<LISTING> char buf[1024];
struct foo { ... };
...
BAD:
xxx(buf, 1024)
xxx(yyy, sizeof(struct foo))
GOOD:
xxx(buf, sizeof(buf))
xxx(yyy, sizeof(yyy))</LISTING>
Be careful though with sizeof of pointers when you really want the size
of where it points to\!
<P></P></LI>
<LI>Every time you see "char foo[###]", check every usage of foo to
make sure it can't be overflowed. If you can't avoid overflow
(and cases of this have been seen) then at least malloc the buffer
so you can't walk on the stack.
<P></P></LI>
<LI>Always close file descriptors as soon as you can -- this makes it
more likely that the stdio buffer contents will be discarded. In
library routines, always set any file descriptors that you open to
close-on-exec.
<P></P></LI>
</UL>
<HR NOSHADE>
<ADDRESS><A HREF="../mailto.html">questions@FreeBSD.ORG</A><BR>
Copyright © 1995-1998 FreeBSD Inc.
All rights reserved.<BR>$Date: 1998-06-19 09:46:50 $</ADDRESS> </BODY>
</HTML>

60
en/security/secure.sgml Normal file
View file

@ -0,0 +1,60 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN" [
<!ENTITY base CDATA "..">
<!ENTITY date "$Date: 1998-06-19 09:46:52 $">
<!ENTITY title "How to secure a FreeBSD system">
<!ENTITY % includes SYSTEM "../includes.sgml"> %includes;
]>
<!-- $Id: secure.sgml,v 1.1 1998-06-19 09:46:52 wosch Exp $ -->
<html>
&header;
There are several steps involved in securing a FreeBSD system, or in
fact any UNIX system:
<UL>
<LI>disabling potentially dangerous software<BR>
A lot of software has to be run as a special privileged user to make use
of specific resources, bij making
the executable set-uid. An example is UUCP software or PPP
software that makes use of a serial port, or sendmail which has to write
in the mail spool and bind to a network port. When you are not using
UUCP, it is of little use to have the software on your system and it may
be wise to disable it. Of course, this requires good knowlegde of what
can be thrown away and what not, as well as a good indication whether or
not you will want the functionality in the future.<BR>
Also some utilities you may find not interesting enough to have them
around and pose a possible security risk, like swapinfo. If you remove
the set-uid bit for the executable (via chmod ug-s filename) you
can always keep on using swapinfo when you're root. It is however
not a good idea stripping so many sbits you have to be root all
the time.<BR>
Not only remove programs that you don't use, also remove services you
don't want or need to provide. This can be done by editting the
<TT>/etc/inetd.conf</TT> file and uncommenting out all services you
don't use.
<LI>fixing software with security bugs<BR>
Subscribe yourself to mailinglist to get updates on security bugs in
software and to get the fixes. Apply them immediately.
<LI>checking your system on a regular basis<BR>
With programs like COPS and SATAN you can find gaping holes and
misconfigurations on your system. It is a good idea to run them
occasionaly to see if you have made any mistakes.<BR>
Also check the daily security reporting that FreeBSD send to root. Check
the logfiles once in a while. Clean up unused accounts.
<LI>being able to repair your system when security has been breached<BR>
Always have backups and a clean version of the operating system (e.g. on
CD-ROM).
<LI>installing software that watches the system<BR>
Programs like the tcp wrapper (a package with FreeBSD) and tripwire help you
monitor activity on your system. This makes it easier to detect
breakins.
<LI>educating the people working on the system<BR>
Users should know what they are doing, and e.g. use hard to guess
password. Let them understand that the security of the system is partly
in their hands.
</UL>
&footer
</body>
</html>

166
en/security/security.sgml Normal file
View file

@ -0,0 +1,166 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN" [
<!ENTITY base CDATA "..">
<!ENTITY date "$Date: 1998-06-19 09:46:53 $">
<!ENTITY title "FreeBSD Security Guide">
<!ENTITY % includes SYSTEM "../includes.sgml"> %includes;
]>
<!-- $Id: security.sgml,v 1.1 1998-06-19 09:46:53 wosch Exp $ -->
<html>
&header;
<P>This guide attempts to document some of the tips and tricks used by
many FreeBSD security experts for securing systems and writing secure
code. It is designed to help you learn about the various ways of protecting
a FreeBSD system against outside attacks and how to recover from such attacks
if and when they should happen. It also lists the various ways in which
the systems programmer can become more security conscious so he will
less likely introduce security holes in the first place.
</P><P>We welcome your comments on the contents and correctness of this page.
Please send email to the <A HREF="mailto:security-officer@FreeBSD.org">
FreeBSD Security Officers</A> if you have changes you'd like to see here.
</P><H2>The FreeBSD security officer</H2>
As FreeBSD takes security seriously, there is a security officer who is
the focal point for security related communications. The security officers'
main task is to send out advisories when there are known security holes
so FreeBSD users will be able to keep their systems secure. The security
officer also communicates with the various CERTs around the world to
give them information about vulnerabilities within FreeBSD and to receive
information about new ones. As such, the security officer is a member of
<A HREF="http://www.first.org/">FIRST</A>, the Forum of Incident Response
and Security Teams.
<P>
When you contact the security officer about sensitive matters, please use
our <A HREF="ftp://ftp.freebsd.org/pub/CERT/public_key.asc">PGP key</A> to encrypt your
message.
</P><H2>FreeBSD security related information</H2>
If you want to stay up to date on FreeBSD security, you can subscribe
yorself to one of the following mailing lists:
<PRE>
freebsd-security General security related discussion
freebsd-security-notification Security notifications (moderated mailing list)
</PRE>
Send mail to <A HREF="mailto:majordomo@freebsd.org">majordomo@FreeBSD.ORG</A>
with
<PRE>
subscribe &lt;listname&gt; [&lt;optional address&gt;]
</PRE>
in the body of the message in order to subscribe yourself.
<P>
Publications of the FreeBSD security officer can also be found on
<A HREF="ftp://ftp.freebsd.org/pub/CERT/">ftp://ftp.freebsd.org/pub/CERT/</A>
<P>Handbook?
</P><H2>FreeBSD security advisories:</H2>
FreeBSD provides security advisories. The advisories will cover
recent releases of FreeBSD. The security advisories will cover
these releases:
<UL>
<LI> the most recent official release of FreeBSD,
<LI> FreeBSD-current,
<LI> FreeBSD-stable, when 2 releases are based on it.
<LI> the previous FreeBSD-stable in case the new stable does not
yet have 2 releases based on it.
</UL>
At this time, security advisories are available for:
<UL>
<LI> FreeBSD 2.2.6
<LI> FreeBSD-current
<LI> FreeBSD-stable
</UL>
Older releases will not be actively maintained.
<p>
You are encouraged to upgrade to one of the supported releases.
<p>
An advisory will be sent out when a security hole exists that is either being
actively abused (as indicated to us via reports from end users or CERT
like organizations), or when the security hole is public knowledge
(e.g. because a report has been posted to a public mailing list).
<p>
Like all development efforts, security fixes are first brought into the
FreeBSD-current branch. After a couple of days, the fix will be retrofitted
into the covered FreeBSD-stable branch(es). Then an advisory will
be sent out.
<p>
Advisories will be sent to the following FreeBSD mailing lists:
<UL>
<LI> FreeBSD-security-notifications
<LI> FreeBSD-security
<LI> FreeBSD-announce
</UL>
Advisories will always be signed using the FreeBSD security-officer
<A HREF="ftp://ftp.freebsd.org/pub/CERT/public_key.asc">PGP key</A>
<p>
Advisories and patches are archived at our
<A HREF="ftp://ftp.freebsd.org/pub/CERT/">FTP site</A>.
</P>
<H2>What to do when you detect a security compromise </H2>
<UL>
<LI>determine the level of security breack<BR>
What privilege did the attack get? That of another user or more (up to
root privileges)?
<LI>determine the part of the system that is not in its original state
anymore<BR>
What software has been tampered with? You may decide to re-install the
operating system from a safe medium, or you might have MD5 checksums of
the original software with which you can check your system. The tripwire
package keeps MD5 checksums. Be aware that tripwire might be tampered
with as well.
<LI>find out how the breakin was done<BR>
Via a well-known security bug? A misconfiguration? When it's a new bug,
warn the FreeBSD Security Officer.
<LI>fix the hole(s)<BR>
Install new software that fixes the problems. If you aren't able to get
a fix quickly, you can temporarily disable remote access to your system.
</UL>
Other questions you may ask yourself are:
<UL>
<LI>Who do I warn? You can contact the security officer, or even the
local authorities. The choice is up to you.
<LI>Do I want to trace the person responsible? By not fixing the hole
right away, you have a chance to catch the cracker. Then again, you have
the chance the cracker wipes your disk. The choice is up to you.
</UL>
<h2><a href="secure.html">How to secure a FreeBSD system</a></h2>
There are several steps involved in securing a FreeBSD system, or in
fact any UNIX system.
<h2><a href="programmers.html">Security Do's and Don'ts for Programmers</a></h2>
<H2>Other usefull security information:</H2>
<UL>
<LI><A href="http://www.cs.purdue.edu/coast/archive/index.html">The COAST
archive</A>
Contains a huge collection of security related material.
<LI><A href="http://www.cs.purdue.edu/homes/spaf/hotlists/csec.htm">
The COAST Security hotlist</A>
This page is THE place to start looking for security related
material. It contains hundreds of usefull
security pointers. Everything you always wanted to know about
security...and more...
<LI>The various CERTs (e.g. <A href="http://www.cert.org">www.cert.org</A> and
<A href="http://www.auscert.org.au">www.auscert.org.au</A>)
<LI>Mailing lists: Bugtraq, BOS
</ul>
&footer
</body>
</html>

166
share/sgml/advisories.xml Normal file
View file

@ -0,0 +1,166 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN" [
<!ENTITY base CDATA "..">
<!ENTITY date "$Date: 1998-06-19 09:46:53 $">
<!ENTITY title "FreeBSD Security Guide">
<!ENTITY % includes SYSTEM "../includes.sgml"> %includes;
]>
<!-- $Id: advisories.xml,v 1.1 1998-06-19 09:46:53 wosch Exp $ -->
<html>
&header;
<P>This guide attempts to document some of the tips and tricks used by
many FreeBSD security experts for securing systems and writing secure
code. It is designed to help you learn about the various ways of protecting
a FreeBSD system against outside attacks and how to recover from such attacks
if and when they should happen. It also lists the various ways in which
the systems programmer can become more security conscious so he will
less likely introduce security holes in the first place.
</P><P>We welcome your comments on the contents and correctness of this page.
Please send email to the <A HREF="mailto:security-officer@FreeBSD.org">
FreeBSD Security Officers</A> if you have changes you'd like to see here.
</P><H2>The FreeBSD security officer</H2>
As FreeBSD takes security seriously, there is a security officer who is
the focal point for security related communications. The security officers'
main task is to send out advisories when there are known security holes
so FreeBSD users will be able to keep their systems secure. The security
officer also communicates with the various CERTs around the world to
give them information about vulnerabilities within FreeBSD and to receive
information about new ones. As such, the security officer is a member of
<A HREF="http://www.first.org/">FIRST</A>, the Forum of Incident Response
and Security Teams.
<P>
When you contact the security officer about sensitive matters, please use
our <A HREF="ftp://ftp.freebsd.org/pub/CERT/public_key.asc">PGP key</A> to encrypt your
message.
</P><H2>FreeBSD security related information</H2>
If you want to stay up to date on FreeBSD security, you can subscribe
yorself to one of the following mailing lists:
<PRE>
freebsd-security General security related discussion
freebsd-security-notification Security notifications (moderated mailing list)
</PRE>
Send mail to <A HREF="mailto:majordomo@freebsd.org">majordomo@FreeBSD.ORG</A>
with
<PRE>
subscribe &lt;listname&gt; [&lt;optional address&gt;]
</PRE>
in the body of the message in order to subscribe yourself.
<P>
Publications of the FreeBSD security officer can also be found on
<A HREF="ftp://ftp.freebsd.org/pub/CERT/">ftp://ftp.freebsd.org/pub/CERT/</A>
<P>Handbook?
</P><H2>FreeBSD security advisories:</H2>
FreeBSD provides security advisories. The advisories will cover
recent releases of FreeBSD. The security advisories will cover
these releases:
<UL>
<LI> the most recent official release of FreeBSD,
<LI> FreeBSD-current,
<LI> FreeBSD-stable, when 2 releases are based on it.
<LI> the previous FreeBSD-stable in case the new stable does not
yet have 2 releases based on it.
</UL>
At this time, security advisories are available for:
<UL>
<LI> FreeBSD 2.2.6
<LI> FreeBSD-current
<LI> FreeBSD-stable
</UL>
Older releases will not be actively maintained.
<p>
You are encouraged to upgrade to one of the supported releases.
<p>
An advisory will be sent out when a security hole exists that is either being
actively abused (as indicated to us via reports from end users or CERT
like organizations), or when the security hole is public knowledge
(e.g. because a report has been posted to a public mailing list).
<p>
Like all development efforts, security fixes are first brought into the
FreeBSD-current branch. After a couple of days, the fix will be retrofitted
into the covered FreeBSD-stable branch(es). Then an advisory will
be sent out.
<p>
Advisories will be sent to the following FreeBSD mailing lists:
<UL>
<LI> FreeBSD-security-notifications
<LI> FreeBSD-security
<LI> FreeBSD-announce
</UL>
Advisories will always be signed using the FreeBSD security-officer
<A HREF="ftp://ftp.freebsd.org/pub/CERT/public_key.asc">PGP key</A>
<p>
Advisories and patches are archived at our
<A HREF="ftp://ftp.freebsd.org/pub/CERT/">FTP site</A>.
</P>
<H2>What to do when you detect a security compromise </H2>
<UL>
<LI>determine the level of security breack<BR>
What privilege did the attack get? That of another user or more (up to
root privileges)?
<LI>determine the part of the system that is not in its original state
anymore<BR>
What software has been tampered with? You may decide to re-install the
operating system from a safe medium, or you might have MD5 checksums of
the original software with which you can check your system. The tripwire
package keeps MD5 checksums. Be aware that tripwire might be tampered
with as well.
<LI>find out how the breakin was done<BR>
Via a well-known security bug? A misconfiguration? When it's a new bug,
warn the FreeBSD Security Officer.
<LI>fix the hole(s)<BR>
Install new software that fixes the problems. If you aren't able to get
a fix quickly, you can temporarily disable remote access to your system.
</UL>
Other questions you may ask yourself are:
<UL>
<LI>Who do I warn? You can contact the security officer, or even the
local authorities. The choice is up to you.
<LI>Do I want to trace the person responsible? By not fixing the hole
right away, you have a chance to catch the cracker. Then again, you have
the chance the cracker wipes your disk. The choice is up to you.
</UL>
<h2><a href="secure.html">How to secure a FreeBSD system</a></h2>
There are several steps involved in securing a FreeBSD system, or in
fact any UNIX system.
<h2><a href="programmers.html">Security Do's and Don'ts for Programmers</a></h2>
<H2>Other usefull security information:</H2>
<UL>
<LI><A href="http://www.cs.purdue.edu/coast/archive/index.html">The COAST
archive</A>
Contains a huge collection of security related material.
<LI><A href="http://www.cs.purdue.edu/homes/spaf/hotlists/csec.htm">
The COAST Security hotlist</A>
This page is THE place to start looking for security related
material. It contains hundreds of usefull
security pointers. Everything you always wanted to know about
security...and more...
<LI>The various CERTs (e.g. <A href="http://www.cert.org">www.cert.org</A> and
<A href="http://www.auscert.org.au">www.auscert.org.au</A>)
<LI>Mailing lists: Bugtraq, BOS
</ul>
&footer
</body>
</html>