Remove a lot of rot and other 'useless' information from the security
website. Approved by: nectar
This commit is contained in:
Tom Rhodes
parent
9185cda095
commit
5e96910ed3
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/www/; revision=20686
1 changed files with 3 additions and 319 deletions
|
|
@ -1,11 +1,11 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" [
|
||||
<!ENTITY base CDATA "..">
|
||||
<!ENTITY date "$FreeBSD: www/en/security/security.sgml,v 1.153 2004/04/03 15:54:16 nectar Exp $">
|
||||
<!ENTITY date "$FreeBSD: www/en/security/security.sgml,v 1.154 2004/04/04 21:49:41 phantom Exp $">
|
||||
<!ENTITY title "FreeBSD Security Information">
|
||||
<!ENTITY % includes SYSTEM "../includes.sgml"> %includes;
|
||||
<!ENTITY advisories.html.inc SYSTEM "advisories.html.inc">
|
||||
]>
|
||||
<!-- $FreeBSD: www/en/security/security.sgml,v 1.153 2004/04/03 15:54:16 nectar Exp $ -->
|
||||
<!-- $FreeBSD: www/en/security/security.sgml,v 1.154 2004/04/04 21:49:41 phantom Exp $ -->
|
||||
|
||||
<html>
|
||||
&header;
|
||||
|
|
@ -29,10 +29,6 @@ introduce vulnerabilities.</P>
|
|||
<LI><A HREF="#sec">Information about the FreeBSD Security Officer</A></LI>
|
||||
<LI><A HREF="#pol">Information handling policies</A></LI>
|
||||
<LI><A HREF="#adv">FreeBSD Security Advisories</A></LI>
|
||||
<LI><A HREF="#ml">FreeBSD Security Mailing Lists Information</A></LI>
|
||||
<LI><A HREF="#tat">FreeBSD Security Tips and Tricks</A></LI>
|
||||
<LI><A HREF="#spg">Secure Programming Guidelines</A></LI>
|
||||
<LI><A HREF="#misc">Other Related Security Information</A></LI>
|
||||
</UL>
|
||||
|
||||
<A NAME=sec></A>
|
||||
|
|
@ -289,318 +285,6 @@ for the very latest advisories please check the
|
|||
|
||||
&advisories.html.inc;
|
||||
|
||||
<A NAME=ml></A>
|
||||
<H2>FreeBSD Security Mailing Lists Information</H2>
|
||||
|
||||
<P>If you are administering or using any number of FreeBSD systems, you
|
||||
should probably be subscribed to one or more of the following lists:</P>
|
||||
|
||||
<TABLE>
|
||||
<TR>
|
||||
<TD><A HREF="http://lists.FreeBSD.org/mailman/listinfo/freebsd-security">freebsd-security</A></TD>
|
||||
<TD>General security related discussion</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD><A HREF="http://lists.FreeBSD.org/mailman/listinfo/freebsd-security-notifications">freebsd-security-notifications</A></TD>
|
||||
<TD>Security notifications (low-volume moderated list)</TD>
|
||||
</TR>
|
||||
</TABLE>
|
||||
|
||||
<A NAME=spg></A>
|
||||
<H2>Secure Programming Guidelines</H2>
|
||||
<P></P><UL>
|
||||
<LI>Never trust any source of input, i.e. command line arguments,
|
||||
environment variables, configuration files, incoming TCP/UDP/ICMP packets,
|
||||
hostname lookups, function arguments, etc. If the length of 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 are:
|
||||
<P></P>
|
||||
<UL>
|
||||
|
||||
<LI>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 the length is unknown). In fact, never ever use
|
||||
gets() or sprintf(), period. If you do - we will send evil dwarfs after you.
|
||||
<P></P></LI>
|
||||
|
||||
<LI>If you have to check the user input so it does not contain bad
|
||||
characters of some sort, do NOT check for those bad characters. Instead
|
||||
simply verify that it consists ONLY of those characters that you do
|
||||
allow. In general concept is: disallow anything that is not
|
||||
explicitly allowed.
|
||||
<P></P></LI>
|
||||
|
||||
<LI>Read man pages for strncpy() and strncat() calls. Be sure to
|
||||
understand how they work!!! While strncpy() might not append a terminating
|
||||
\0, strncat() on the other hand adds the \0.
|
||||
<P></P></LI>
|
||||
|
||||
<LI>Watch for strvis() and getenv() abuse. With strvis() it is easy to get
|
||||
the destination string wrong, and getenv() can return strings much
|
||||
longer then the program might expect. These two functions 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. Be very paranoid!
|
||||
<P></P></LI>
|
||||
|
||||
<LI>Ever time you use open() or stat() call - ask yourself: "What if it
|
||||
is a symbolic link?"
|
||||
<P></P></LI>
|
||||
|
||||
<LI>Make sure to use mkstemp() instead of mktemp(), tempnam(), etc.
|
||||
Also make sure to look for races in /tmp in general, being aware that
|
||||
there are very few things which 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>
|
||||
If you use mkstemp() the above cases will be properly handled for you. Hence
|
||||
all temp files should use mkstemp() to guarantee there is not race
|
||||
condition and that the permissions are correct.
|
||||
<P></P></LI>
|
||||
|
||||
<LI>If an attacker can force packets to go/come from another arbitrary
|
||||
system then that attacker has complete control over the data that we get
|
||||
and <B>NONE</B> of it should be trusted.
|
||||
<P></P></LI>
|
||||
|
||||
<LI>Never trust a configuration file is correctly formatted or that it was
|
||||
generated by the appropriate utility. Don't trust user input such as
|
||||
terminal names or language strings to be free of '/' or '../../../' if
|
||||
there is any chance that they can be used in a path name. Don't trust
|
||||
<B>ANY</B> paths supplied by the user when you are running setuid root.
|
||||
<P></P></LI>
|
||||
|
||||
<LI>Look for holes or weaknesses in how data is stored. All temp files
|
||||
should have 600 permission in order to be protected from prying eyes.
|
||||
<P></P></LI>
|
||||
|
||||
<LI>Do not just grep for the usual suspects in programs which run with
|
||||
elevated privileges. Look line by line for possible overflows in these
|
||||
cases since there are a lot more ways to cause buffer overflows than
|
||||
by abusing strcpy() and friends.
|
||||
<P></P></LI>
|
||||
|
||||
<LI>Just because you drop privileges somewhere, it does not mean that no
|
||||
exploit is possible. The attacker may put the necessary code on the
|
||||
stack to regain the privileges before executing /bin/sh.</LI></UL>
|
||||
<P></P></LI>
|
||||
|
||||
<LI>Do uid management. Do drop privileges as soon as possible, and really
|
||||
do drop them. Switching between euid and uid is NOT enough. Use setuid()
|
||||
when you can.
|
||||
<P></P></LI>
|
||||
|
||||
<LI>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>Tips for those reviewing existing code for security problems:<P></P><UL>
|
||||
|
||||
<LI>If you are unsure of your security fixes, send them to a reviewer with
|
||||
whom you already have arrangements for a second glance over your
|
||||
code. Don't commit code you are not sure about since breaking something
|
||||
in the name of a security fix is rather embarrassing.
|
||||
<P></P></LI>
|
||||
|
||||
<LI>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>When sending changes around for review, always use context or unidiff
|
||||
format diffs - this way diffs can be easily fed to patch(1). Do not simply
|
||||
send the 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 the -current branch of
|
||||
development.
|
||||
<P></P></LI>
|
||||
|
||||
<LI>Always directly test your changes (e.g. build and run the affected
|
||||
sources) before sending them to a reviewer. Nobody 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 submitting
|
||||
(which is also hardly
|
||||
confidence building). If you need accounts on a machine with a specific
|
||||
version which you don't have available - just ask. The project has
|
||||
resources available for exactly such purposes.
|
||||
<P></P></LI>
|
||||
|
||||
<LI>Note for committers: do not forget to retrofit -current patches into
|
||||
the -stable branch as appropriate.
|
||||
<P></P></LI>
|
||||
|
||||
<LI>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 reasons for it.</LI></UL>
|
||||
<P></P></LI>
|
||||
|
||||
<LI>Look out for programs doing complex things with signal
|
||||
handlers. Many routines in the various libraries are not sufficiently
|
||||
reentrant to make this safe.
|
||||
<P></P></LI>
|
||||
|
||||
<LI>Pay special attention to realloc() usage - more often then not the
|
||||
function is not used 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:
|
||||
<pre>
|
||||
char buf[1024];
|
||||
struct foo { ... };
|
||||
...
|
||||
BAD:
|
||||
xxx(buf, 1024)
|
||||
xxx(yyy, sizeof(struct foo))
|
||||
GOOD:
|
||||
xxx(buf, sizeof(buf))
|
||||
xxx(yyy, sizeof(yyy))
|
||||
</pre>
|
||||
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 that 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 that one 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>
|
||||
|
||||
<P>A useful auditing tool is the its4 port, located in
|
||||
/usr/ports/security/its4/. This is an automated C code auditor which
|
||||
highlights potential trouble-spots in the code. It is a useful
|
||||
first-pass tool, but should not be relied upon as being authoritative,
|
||||
and a complete audit should include human examination of the entire
|
||||
code.</P>
|
||||
|
||||
<P>For more information on secure programming techniques and resources, see
|
||||
the <A HREF="http://www.shmoo.com/securecode/">How to Write Secure Code</A>
|
||||
resource center.</P>
|
||||
|
||||
<A NAME=tat></A>
|
||||
<H2>FreeBSD Security Tips and Tricks</H2>
|
||||
<P>There are several steps one must take to secure a FreeBSD system, or
|
||||
in fact any &unix; system:</P>
|
||||
<UL>
|
||||
|
||||
<LI>Disabling potentially dangerous software<BR><P></P>
|
||||
A lot of software has to be run as a special privileged user to make
|
||||
use of specific resources, by making the executable set-uid. An
|
||||
example is UUCP or PPP software that makes use of a serial port, or
|
||||
sendmail which has to write in the mail spool and bind to a privileged
|
||||
network port. When you are not using UUCP, it is of little use to have
|
||||
software on your system and it may be wise to disable it. Of course,
|
||||
this requires good knowledge of what can be thrown away and what not,
|
||||
as well as good indication whether or not you will want the functionality
|
||||
in the future.<BR><P></P>
|
||||
Also some utilities you may find not useful enough to have
|
||||
around pose a possible security risk, like swapinfo. If you remove
|
||||
the set-uid bit for the executable (via 'chmod ug-s filename' command)
|
||||
you can always keep on using swapinfo when you're root. It is however
|
||||
not a good idea to strip so many sbits that you have to be root all
|
||||
the time.<BR><P></P>
|
||||
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 editing the
|
||||
<TT>/etc/inetd.conf</TT> and <TT>/etc/rc.conf</TT> files and turning
|
||||
off all services you don't use.<P></P></LI>
|
||||
|
||||
<LI>Fixing software which has security bugs (or how to stay one step ahead
|
||||
of crackers)<BR><P></P>
|
||||
Make sure you are subscribed to various <A HREF="#ml">FreeBSD Security
|
||||
mailing lists</A> so you get updates on security bugs and
|
||||
fixes. Apply the fixes immediately.<P></P></LI>
|
||||
|
||||
<LI>Backups - repair your system if a security breach does occur<BR><P></P>
|
||||
Always have backups and a clean version of the operating system (e.g. on
|
||||
CD-Rom).
|
||||
Make sure your backups do not contain corrupted data or
|
||||
data modified by attackers.<P></P></LI>
|
||||
|
||||
<LI>Install software to watch the state of the system<BR><P></P>
|
||||
Programs like the tcp wrappers and tripwire (both in packages/ports) can
|
||||
help you to monitor activity on your system. This makes it easier
|
||||
to detect break-ins. Also read outputs of the /etc/security scripts
|
||||
which are run daily and mailed to the root account.<P></P></LI>
|
||||
|
||||
<LI>Educating the people who work on the system<BR><P></P>
|
||||
Users should know what they are doing. They should be told to never give
|
||||
out their password to anyone and to also use hard-to-guess passwords.
|
||||
Let them understand that the security of the system/network is partly
|
||||
in their hands.<P></P></LI>
|
||||
</UL>
|
||||
|
||||
|
||||
<P>There is also a FreeBSD Security How-To available which provides some
|
||||
advanced tips on how to improve security of your system. You can
|
||||
find it at <A HREF="http://www.FreeBSD.org/~jkb/howto.html">
|
||||
http://www.FreeBSD.org/~jkb/howto.html</A>.</P>
|
||||
<P>Security is an ongoing process. Make sure you are following the latest
|
||||
developments in the security arena.</P>
|
||||
|
||||
<A NAME=misc></A>
|
||||
<H2>What to do when you detect a security compromise</H2>
|
||||
|
||||
<UL>
|
||||
<LI><B>Determine the level of the security breach</B><BR>
|
||||
What privileges did the attacker get? Did the attacker manage to get
|
||||
root access? Did the attacker only manage to get user level access?</LI>
|
||||
|
||||
<LI><B>Determine if the state of system (kernel or userland) has been
|
||||
tampered with</B><BR>
|
||||
What software has been tampered with? Was new kernel installed? Were any
|
||||
of the system binaries (such as telnetd, login, etc) modified? If you
|
||||
believe an attacker could have done any tampering with an OS, you may want
|
||||
to re-install the operating system from a safe medium.</LI>
|
||||
|
||||
<LI><B>Find out how the break-in was done</B><BR>
|
||||
Did the break-in occur via a well-known security bug? If that is the case,
|
||||
make sure to install the correct patches. Was the break-in successful due
|
||||
to a misconfiguration? Was the break-in result of a new bug? If you believe
|
||||
the break-in occurred via a new bug, you should warn the
|
||||
<A HREF="mailto:security-officer@FreeBSD.org"> FreeBSD Security
|
||||
Officer</A>.</LI>
|
||||
|
||||
<LI><B>Fix the security hole</B><BR>
|
||||
Install new software or apply patches to the old one in order to fix the
|
||||
problems. Disable any compromised accounts.</LI>
|
||||
|
||||
<LI><B>Other resources</B><BR>
|
||||
<A HREF="http://www.cert.org">CERT</A> also offers
|
||||
<A HREF="http://www.cert.org/nav/recovering.html">detailed information</A>
|
||||
on what steps to take in case of a system compromise.</LI>
|
||||
</UL>
|
||||
|
||||
<H2>Other Related Security Information</H2>
|
||||
<UL>
|
||||
<LI><A href="http://www.cerias.purdue.edu/coast/archive/index.html">The COAST
|
||||
archive</A> contains a huge collection of security related materials.</LI>
|
||||
|
||||
<LI><A href="http://www.cerias.purdue.edu/infosec/hotlist/">The Center for
|
||||
Education and Research in Information Assurance and Security (CERIAS)</A>
|
||||
is the place to start looking for security related materials.
|
||||
It contains hundreds of useful security pointers. Everything you always
|
||||
wanted to know about security... and more.</LI>
|
||||
|
||||
<LI>The various CERT teams such as <A href="http://www.cert.org">
|
||||
http://www.cert.org</A> and <A href="http://www.auscert.org.au">
|
||||
http://www.auscert.org.au</A>.</LI>
|
||||
|
||||
<LI>Mailing lists such as <A HREF="http://www.securityfocus.com/forums/bugtraq/intro.html">
|
||||
Bugtraq</A> and <A HREF="http://list.nfr.com/forum/firewall-wizards.html">
|
||||
Firewall Wizards</A>.</LI>
|
||||
</UL>
|
||||
|
||||
&footer
|
||||
</body>
|
||||
</html>
|
||||
</html>
|
||||
Loading…
Add table
Add a link
Reference in a new issue