diff --git a/en/security/advisories.xml b/en/security/advisories.xml
index 475f50993f..0695aa71fa 100644
--- a/en/security/advisories.xml
+++ b/en/security/advisories.xml
@@ -1,1722 +1,1738 @@
- $FreeBSD: www/en/security/advisories.xml,v 1.127 2003/02/24 13:09:48 nectar Exp $
+ $FreeBSD: www/en/security/advisories.xml,v 1.128 2003/03/03 17:25:51 nectar Exp $
2003
March
+
+ 21
+
+
+ FreeBSD-SA-03:06.openssl
+
+
+
+
+ 20
+
+
+ FreeBSD-SA-03:05.xdr
+
+
+
3
FreeBSD-SA-03:04.sendmail
February
24
FreeBSD-SA-03:03.syncookies
FreeBSD-SA-03:02.openssl
04
FreeBSD-SA-03:01.cvs
January
07
FreeBSD-SA-02:44.filedesc
2002
November
15
FreeBSD-SA-02:43.bind
FreeBSD-SA-02:41.smrsh
12
FreeBSD-SA-02:42.resolv
FreeBSD-SA-02:40.kadmind
October
10
FreeBSD-SN-02:06
September
16
FreeBSD-SA-02:39.libkvm
August
28
FreeBSD-SN-02:05
19
FreeBSD-SA-02:38.signed-error
05
FreeBSD-SA-02:37.kqueue
FreeBSD-SA-02:36.nfs
FreeBSD-SA-02:35.ffs
FreeBSD-SA-02:33.openssl
01
FreeBSD-SA-02:34.rpc
July
31
FreeBSD-SA-02:32.pppd
15
FreeBSD-SA-02:31.openssh
12
FreeBSD-SA-02:30.ktrace
FreeBSD-SA-02:29.tcpdump
June
26
FreeBSD-SA-02:28.resolv
19
FreeBSD-SN-02:04
May
29
FreeBSD-SA-02:27.rc
FreeBSD-SA-02:26.accept
28
FreeBSD-SN-02:03
20
FreeBSD-SA-02:25.bzip2
FreeBSD-SA-02:24.k5su
13
FreeBSD-SN-02:02
April
22
FreeBSD-SA-02:23.stdio
18
FreeBSD-SA-02:22.mmap
17
FreeBSD-SA-02:21.tcpip
16
FreeBSD-SA-02:20.syncache
March
30
FreeBSD-SN-02:01
26
FreeBSD-SA-02:19.squid
18
FreeBSD-SA-02:18.zlib.v1.2
12
FreeBSD-SA-02:17.mod_frontpage
FreeBSD-SA-02:16.netscape
FreeBSD-SA-02:15.cyrus-sasl
FreeBSD-SA-02:14.pam-pgsql
07
FreeBSD-SA-02:13.openssh
February
21
FreeBSD-SA-02:12.squid
12
FreeBSD-SA-02:11.snmp
06
FreeBSD-SA-02:10.rsync
FreeBSD-SA-02:09.fstatfs
January
24
FreeBSD-SA-02:08.exec
18
FreeBSD-SA-02:07.k5su
16
FreeBSD-SA-02:06.sudo
04
FreeBSD-SA-02:05.pine
FreeBSD-SA-02:04.mutt
FreeBSD-SA-02:03.mod_auth_pgsql
FreeBSD-SA-02:02.pw
FreeBSD-SA-02:01.pkg_add
2001
December
04
FreeBSD-SA-01:64.wu-ftpd
02
FreeBSD-SA-01:63.openssh
October
08
FreeBSD-SA-01:62.uucp
FreeBSD-SA-01:61.squid
September
24
FreeBSD-SA-01:60.procmail
04
FreeBSD-SA-01:59.rmuser.v1.1
August
30
FreeBSD-SA-01:58.lpd
27
FreeBSD-SA-01:57.sendmail.v1.2
23
FreeBSD-SA-01:56.tcp_wrappers
21
FreeBSD-SA-01:55.procfs
20
FreeBSD-SA-01:54.ports-telnetd
17
FreeBSD-SA-01:53.ipfw
06
FreeBSD-SA-01:52.fragment
July
30
FreeBSD-SA-01:51.openssl.v1.1
27
FreeBSD-SA-01:50.windowmaker
23
FreeBSD-SA-01:49.telnetd.v1.1
17
FreeBSD-SA-01:48.tcpdump
10
FreeBSD-SA-01:47.xinetd
FreeBSD-SA-01:46.w3m
FreeBSD-SA-01:45.samba
FreeBSD-SA-01:44.gnupg
FreeBSD-SA-01:43.fetchmail
FreeBSD-SA-01:42.signal.v1.1
09
FreeBSD-SA-01:41.hanterm
June
04
FreeBSD-SA-01:40.fts.v1.1
May
02
FreeBSD-SA-01:39.tcp-isn
April
23
FreeBSD-SA-01:38.sudo
FreeBSD-SA-01:37.slrn
FreeBSD-SA-01:36.samba
FreeBSD-SA-01:35.licq
FreeBSD-SA-01:34.hylafax
17
FreeBSD-SA-01:33.ftpd-glob.v1.1
16
FreeBSD-SA-01:32.ipfilter.v1.1
06
FreeBSD-SA-01:31.ntpd
March
22
FreeBSD-SA-01:30.ufs-ext2fs
12
FreeBSD-SA-01:29.rwhod
FreeBSD-SA-01:28.timed
FreeBSD-SA-01:27.cfengine
FreeBSD-SA-01:26.interbase
FreeBSD-SA-01:23.icecast
February
14
FreeBSD-SA-01:25.kerberosIV
12
FreeBSD-SA-01:24.ssh
07
FreeBSD-SA-01:22.dc20ctrl
FreeBSD-SA-01:21.ja-elvis
FreeBSD-SA-01:20.mars_nwe
FreeBSD-SA-01:19.ja-klock
January
31
FreeBSD-SA-01:18.bind
29
FreeBSD-SA-01:17.exmh
FreeBSD-SA-01:16.mysql
FreeBSD-SA-01:15.tinyproxy
FreeBSD-SA-01:14.micq
FreeBSD-SA-01:13.sort
FreeBSD-SA-01:12.periodic.v1.1
FreeBSD-SA-01:11.inetd.v1.1
23
FreeBSD-SA-01:10.bind
FreeBSD-SA-01:09.crontab.v1.1
FreeBSD-SA-01:08.ipfw
FreeBSD-SA-01:07.xfree86
15
FreeBSD-SA-01:06.zope
FreeBSD-SA-01:05.stunnel
FreeBSD-SA-01:04.joe
FreeBSD-SA-01:03.bash1
FreeBSD-SA-01:02.syslog-ng
FreeBSD-SA-01:01.openssh
2000
December
20
FreeBSD-SA-00:81.ethereal
FreeBSD-SA-00:80.halflifeserver
FreeBSD-SA-00:79.oops
FreeBSD-SA-00:78.bitchx.v1.1
18
FreeBSD-SA-00:77.procfs.v1.1
November
20
FreeBSD-SA-00:76.tcsh-csh
FreeBSD-SA-00:75.php
FreeBSD-SA-00:74.gaim
FreeBSD-SA-00:73.thttpd
FreeBSD-SA-00:72.curl
FreeBSD-SA-00:71.mgetty
14
FreeBSD-SA-00:70.ppp-nat
FreeBSD-SA-00:69.telnetd.v1.1
13
FreeBSD-SA-00:68.ncurses.v1.1
10
FreeBSD-SA-00:67.gnupg
06
FreeBSD-SA-00:66.netscape
FreeBSD-SA-00:65.xfce
FreeBSD-SA-00:64.global
01
FreeBSD-SA-00:63.getnameinfo
FreeBSD-SA-00:62.top.v1.1
October
31
FreeBSD-SA-00:61.tcpdump.v1.1
30
FreeBSD-SA-00:60.boa
FreeBSD-SA-00:59.pine
FreeBSD-SA-00:58.chpass
13
FreeBSD-SA-00:57.muh
FreeBSD-SA-00:56.lprng
FreeBSD-SA-00:55.xpdf
FreeBSD-SA-00:54.fingerd
06
FreeBSD-SA-00:52.tcp-iss
September
27
FreeBSD-SA-00:53.catopen
13
FreeBSD-SA-00:51.mailman
FreeBSD-SA-00:50.listmanager
FreeBSD-SA-00:49.eject
FreeBSD-SA-00:48.xchat
FreeBSD-SA-00:47.pine
FreeBSD-SA-00:46.screen
August
31
FreeBSD-SA-00:45.esound
28
FreeBSD-SA-00:44.xlock
FreeBSD-SA-00:43.brouted
FreeBSD-SA-00:42.linux
FreeBSD-SA-00:41.elf
FreeBSD-SA-00:40.mopd
FreeBSD-SA-00:39.netscape
14
FreeBSD-SA-00:38.zope
FreeBSD-SA-00:37.cvsweb
FreeBSD-SA-00:36.ntop
FreeBSD-SA-00:35.proftpd
FreeBSD-SA-00:34.dhclient
July
12
FreeBSD-SA-00:33.kerberosIV
05
FreeBSD-SA-00:32.bitchx
FreeBSD-SA-00:31.canna.asc.v1.1
FreeBSD-SA-00:30.openssh
FreeBSD-SA-00:29.wu-ftpd.asc.v1.1
FreeBSD-SA-00:28.majordomo
FreeBSD-SA-00:27.XFree86-4
FreeBSD-SA-00:26.popper.asc.v1.1
FreeBSD-SA-00:24.libedit
June
19
FreeBSD-SA-00:23.ip-options.asc.v1.1
12
FreeBSD-SA-00:25.alpha-random
07
FreeBSD-SA-00:22.apsfilter
FreeBSD-SA-00:21.ssh.asc.v1.1
May
26
FreeBSD-SA-00:20.krb5
23
FreeBSD-SA-00:19.semconfig
09
FreeBSD-SA-00:18.gnapster.knapster.asc.v1.1
FreeBSD-SA-00:17.libmytinfo
FreeBSD-SA-00:16.golddig
April
24
FreeBSD-SA-00:15.imap-uw
FreeBSD-SA-00:14.imap-uw
19
FreeBSD-SA-00:13.generic-nqs
10
FreeBSD-SA-00:12.healthd
FreeBSD-SA-00:11.ircii
March
15
FreeBSD-SA-00:10.orville-write
FreeBSD-SA-00:09.mtr
FreeBSD-SA-00:08.lynx.asc.v1.1
FreeBSD-SA-00:07.mh
01
FreeBSD-SA-00:06.htdig
February
28
FreeBSD-SA-00:05.mysql
19
FreeBSD-SA-00:04.delegate
FreeBSD-SA-00:03.asmon
January
24
FreeBSD-SA-00:02.procfs
19
FreeBSD-SA-00:01.make
1999
September
16
FreeBSD-SA-99:06.amd
15
FreeBSD-SA-99:05.fts
FreeBSD-SA-99:04.core
05
FreeBSD-SA-99:03.ftpd
04
FreeBSD-SA-99:02.profil
FreeBSD-SA-99:01.chflags
1998
November
04
FreeBSD-SA-98:08.fragment
October
13
FreeBSD-SA-98:07.rst
June
10
FreeBSD-SA-98:06.icmp
04
FreeBSD-SA-98:05.nfs
02
FreeBSD-SA-98:04.mmap
May
14
FreeBSD-SA-98:03.ttcp
March
12
FreeBSD-SA-98:02.mmap
1997
December
09
FreeBSD-SA-97:06.f00f
01
FreeBSD-SA-98:01.land
October
29
FreeBSD-SA-97:05.open
August
19
FreeBSD-SA-97:04.procfs
April
07
FreeBSD-SA-97:03.sysinstall
March
26
FreeBSD-SA-97:02.lpd
February
05
FreeBSD-SA-97:01.setlocale
January
18
FreeBSD-SA-96:21.talkd
1996
December
16
FreeBSD-SA-96:20.stack-overflow
10
FreeBSD-SA-96:19.modstat
November
25
FreeBSD-SA-96:18.lpr
July
16
FreeBSD-SA-96:17.rzsz
12
FreeBSD-SA-96:16.rdist
04
FreeBSD-SA-96:15.ppp
June
28
FreeBSD-SA-96:12.perl
24
FreeBSD-SA-96:14.ipfw
05
FreeBSD-SA-96:13.comsat
May
21
FreeBSD-SA-96:11.man
17
FreeBSD-SA-96:10.mount_union
FreeBSD-SA-96:09.vfsload
April
22
FreeBSD-SA-96:02.apache
21
FreeBSD-SA-96:08.syslog
FreeBSD-SA-96:01.sliplogin
20
FreeBSD-SA-96:03.sendmail-suggestion
diff --git a/en/security/security.sgml b/en/security/security.sgml
index 45bedafa6d..d15db197de 100644
--- a/en/security/security.sgml
+++ b/en/security/security.sgml
@@ -1,890 +1,892 @@
-
+
%includes;
]>
-
+
&header;
Introduction
This web page is designed to assist both new and experienced users
in the area of FreeBSD security. FreeBSD
takes security very seriously and is constantly working
on making the OS as secure as possible.
Here you will find additional information, or links to information,
on how to protect your system against various types of attack,
on whom to contact if you find a security-related bug, and so on. There is
also a section on the various ways that the systems programmer can
become more security conscious so that he is less likely to
introduce vulnerabilities.
Table of Contents
The FreeBSD Security Officer and the Security Officer Team
To better coordinate information exchange with others in the security
community, FreeBSD has a focal point for security-related communications:
the FreeBSD Security Officer.
If you need to contact the FreeBSD Project about
a possible security issue, you should therefore send mail to the Security
Officer with a description of what you have found and the type of
vulnerability it represents.
In order that the FreeBSD Project may respond to vulnerability
reports in a timely manner, there are four members of the Security
Officer mail alias: the Security Officer, the Deputy Security Officer,
and two Core Team members. Therefore, messages sent to the
<security-officer@FreeBSD.org>
mail alias are currently delivered to:
The Security Officer is supported by the Security Officer Team
<security-team@FreeBSD.org>, a
group of committers selected by the Security Officer. The current
make up of the team is as follows:
Please use the Security
Officer PGP key to encrypt your messages to the Security Officer
when appropriate.
Information handling policies
As a general policy, the FreeBSD Security Officer favors full
disclosure of vulnerability information after a reasonable delay to
permit safe analysis and correction of a vulnerability, as well as
appropriate testing of the correction, and appropriate coordination
with other affected parties.
The Security Officer will notify one or more of the
FreeBSD Cluster Admins of
vulnerabilities that put the FreeBSD Project's resources under
immediate danger.
The Security Officer may bring additional FreeBSD developers
or outside developers into discussion of a submitted security
vulnerability if their expertise is required to fully understand or
correct the problem. Appropriate discretion will be exercised to
minimize unnecessary distribution of information about the submitted
vulnerability, and any experts brought in will act in accordance of
Security Officer policies. In the past, experts have been brought
in based on extensive experience with highly complex components of
the operating system, including FFS, the VM system, and the network
stack.
If a FreeBSD release process is underway, the FreeBSD Release
Engineer may also be notified that a vulnerability exists, and its
severity, so that informed decisions may be made regarding the release
cycle and any serious security bugs present in software associated
with an up-coming release. If requested, the Security Officer will
not share information regarding the nature of the vulnerability with
the Release Engineer, limiting information flow to existence and
severity.
The FreeBSD Security Officer has close working relationships
with a number of other organizations, including third-party vendors
that share code with FreeBSD (the OpenBSD and NetBSD projects,
Apple, and other vendors deriving software from FreeBSD, as well
as the Linux vendor security list), as well as organizations
that track vulnerabilities and security incidents, such as CERT.
Frequently vulnerabilities may extend beyond the scope of the
FreeBSD implementation, and (perhaps less frequently) may have
broad implications for the global networking community. Under such
circumstances, the Security Officer may wish to disclose vulnerability
information to these other organizations: if you do not wish the
Security Officer to do this, please indicate so explicitly in any
submissions.
Submitters should be careful to explicitly document any special
information handling requirements.
If the submitter of a vulnerability is interested in a coordinated
disclosure process with the submitter and/or other vendors, this
should be indicated explicitly in any submissions. In the absence
of explicit requests, the FreeBSD Security Officer will select a
disclosure schedule that reflects both a desire for timely disclosure
and appropriate testing of any solutions. Submitters should be aware
that if the vulnerability is being actively discussed in public forums
(such as bugtraq), and actively exploited, the Security Officer may
choose not to follow a proposed disclosure timeline in order to
provide maximum protection for the user community.
Submitters should be aware that the FreeBSD Project is an open
source project, and source revision control information for every
change made to the FreeBSD source tree is publicly accessible. If a
disclosure schedule is provided, it should take into account both the
official release of advisory, patch, and update information, as well
as initial inclusion of fixes in the FreeBSD source tree. There is
necessarily a lag between the inclusion of fixes in the tree and the
generation and releases of advisories, patches, and binary updates, as
the source control system is used to generate them.
Submissions may be protected using PGP. If desired, responses will
also be protected using PGP.
FreeBSD Security Advisories
The FreeBSD Security Officer provides security advisories for
several branches of FreeBSD development. These are the -STABLE
Branches and the Security Branches. (Advisories are not
issued for the -CURRENT Branch.)
There is usually only a single -STABLE branch, although
during the transition from one major development line to another
(such as from FreeBSD 4.x to 5.x), there is a time span in which
there are two -STABLE branches. The -STABLE branch tags have names
like RELENG_4. The corresponding builds have names like
FreeBSD 4.6-STABLE.
Each FreeBSD Release has an associated Security Branch.
The Security Branch tags have names like RELENG_4_6.
The corresponding builds have names like FreeBSD
4.6-RELEASE-p7.
Each branch is supported by the Security Officer for a limited time
only, typically through 12 months after the release. The estimated
lifetimes of the currently supported branches are given below. The
Estimated EoL (end-of-life) column gives the earliest date on
which that branch is likely to be dropped. Please note that these dates
may be extended into the future, but only extenuating circumstances
would lead to a branch's support being dropped earlier than the date
listed.
Branch |
Release |
Estimated EoL |
RELENG_4 |
n/a |
December 31, 2003 |
RELENG_4_6 |
4.6-RELEASE |
May 31, 2003 |
RELENG_4_7 |
4.7-RELEASE |
September 30, 2003 |
RELENG_5_0 |
5.0-RELEASE |
June 30, 2003 |
Older releases are not maintained and users are strongly encouraged
to upgrade to one of the supported releases mentioned above.
Like all development efforts, security fixes are first brought into
the FreeBSD-current branch.
After a couple of days and some testing, the fix is retrofitted into
the supported FreeBSD-stable branch(es) and an advisory is then sent
out.
Some statistics about advisories released during 2001:
- A total of 68 advisories were released, covering both the base
system and the optional third party applications included in the
Ports Collection.
- 26 advisories of various severity were issued for the base system,
with the remaining 42 relating to optional third party applications
available in the Ports Collection.
- 8 advisories described vulnerabilities found only in FreeBSD.
The remaining 60 were problems shared with at least one other OS
(often due to shared code).
Advisories are sent to the following FreeBSD mailing lists:
- FreeBSD-security-notifications@FreeBSD.org
- FreeBSD-security@FreeBSD.org
- FreeBSD-announce@FreeBSD.org
Advisories are always signed using the FreeBSD Security Officer
PGP key
and are archived, along with their associated patches, at our
FTP CERT
repository. At the time of this writing, the following advisories are
currently available (note that this list may be a few days out of date -
for the very latest advisories please check the
FTP site):
FreeBSD 5.0-RELEASE released.
FreeBSD 4.7-RELEASE released.
FreeBSD 4.6.2-RELEASE released.
FreeBSD 4.6-RELEASE released.
FreeBSD 4.5-RELEASE released.
FreeBSD 4.4-RELEASE released.
FreeBSD 4.3-RELEASE released.
FreeBSD Security Mailing Lists Information
If you are administering or using any number of FreeBSD systems, you
should probably be subscribed to one or more of the following lists:
freebsd-security General security related discussion
freebsd-security-notifications Security notifications (moderated mailing list)
Send mail to
majordomo@FreeBSD.ORG with
subscribe <listname> [<optional address>]
in the body of the message in order to subscribe yourself.
For example:
% echo "subscribe freebsd-security" | mail majordomo@FreeBSD.org
and if you would like to unsubscribe from a mailing list:
% echo "unsubscribe freebsd-security" | mail majordomo@FreeBSD.org
Secure Programming Guidelines
- 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 date 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:
- 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.
- 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.
- 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.
- 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!
- Ever time you use open() or stat() call - ask yourself: "What if it
is a symbolic link?"
- 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:
- Creating a directory. This will either succeed or fail.
- Opening a file O_CREAT | O_EXCL
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.
- 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 NONE of it should be trusted.
- 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
ANY paths supplied by the user when you are running setuid root.
- 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.
- 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.
- 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.
- 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.
- 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.
- Tips for those reviewing existing code for security problems:
- 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.
- 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.
- 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.
- 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.
- Note for committers: do not forget to retrofit -current patches into
the -stable branch as appropriate.
- 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.
- Look out for programs doing complex things with signal
handlers. Many routines in the various libraries are not sufficiently
reentrant to make this safe.
- Pay special attention to realloc() usage - more often then not the
function is not used correctly.
- 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:
char buf[1024];
struct foo { ... };
...
BAD:
xxx(buf, 1024)
xxx(yyy, sizeof(struct foo))
GOOD:
xxx(buf, sizeof(buf))
xxx(yyy, sizeof(yyy))
Be careful though with sizeof of pointers when you really want the size
of where it points to!
- 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.
- 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.
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.
For more information on secure programming techniques and resources, see
the How to Write Secure Code
resource center.
FreeBSD Security Tips and Tricks
There are several steps one must take to secure a FreeBSD system, or
in fact any Unix system:
- Disabling potentially dangerous software
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.
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.
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
/etc/inetd.conf and /etc/rc.conf files and turning
off all services you don't use.
- Fixing software which has security bugs (or how to stay one step ahead
of crackers)
Make sure you are subscribed to various FreeBSD Security
mailing lists so you get updates on security bugs and
fixes. Apply the fixes immediately.
- Backups - repair your system if a security breach does occur
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.
- Install software to watch the state of the system
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.
- Educating the people who work on the system
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.
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
http://www.FreeBSD.org/~jkb/howto.html.
Security is an ongoing process. Make sure you are following the latest
developments in the security arena.
What to do when you detect a security compromise
- Determine the level of the security breach
What privileges did the attacker get? Did the attacker manage to get
root access? Did the attacker only manage to get user level access?
- Determine if the state of system (kernel or userland) has been
tampered with
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.
- Find out how the break-in was done
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
FreeBSD Security
Officer.
- Fix the security hole
Install new software or apply patches to the old one in order to fix the
problems. Disable any compromised accounts.
- Other resources
CERT also offers
detailed information
on what steps to take in case of a system compromise.
Other Related Security Information
&footer