diff --git a/en/security/security.sgml b/en/security/security.sgml index b82b7b5b7e..8d2a3c1e48 100644 --- a/en/security/security.sgml +++ b/en/security/security.sgml @@ -1,621 +1,621 @@ - + %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.

Information about the FreeBSD Security Officer
Information handling policies
FreeBSD Security Advisories
FreeBSD Security Mailing Lists Information
FreeBSD Security Tips and Tricks
Secure Programming Guidelines
Other Related Security Information

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:

Jacques Vidrine <nectar@FreeBSD.org>	Security Officer
Chris Faulhaber <jedgar@FreeBSD.org>	Deputy Security Officer
Robert Watson <rwatson@FreeBSD.org>	FreeBSD Core Team member, Release Engineering liaison, TrustedBSD Project liaison, system security architecture expert
Warner Losh <imp@FreeBSD.org>	FreeBSD Core Team liaison, Security Officer Emeritus

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:

Bill Fumerola <billf@FreeBSD.org>	FreeBSD Infrastructure liaison
Daniel Harris <dannyboy@FreeBSD.org>	Doc and ports committer
Trevor Johnson <trevor@FreeBSD.org>	ports committer
Kris Kennaway <kris@FreeBSD.org>	Port Manager liaison, Security Officer Emeritus
Wes Peters <wes@FreeBSD.org>	FreeBSD Core Team member; former security software researcher and developer for the US Air Force, Axent Technologies/Symantec, Intel, and Alcatel Internetworking.
Guido van Rooij <guido@FreeBSD.org>	Security Officer Emeritus
Dag-Erling Smorgrav <des@FreeBSD.org>

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_7	4.7-RELEASE	September 30, 2003
RELENG_4_8	4.8-RELEASE	March 31, 2004
RELENG_5_1	5.1-RELEASE	December 31, 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 2002:

44 advisories of varying severity were issued for the base system.
12 advisories described vulnerabilities found only in FreeBSD. The remaining 32 were problems shared with at least one other OS (often due to shared code).
6 security notices were issued, covering a total of 95 issues in optional third party applications included in the Ports Collection.

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):

&advisories.html.inc;

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 (low-volume moderated list)

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 +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:
- 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

The COAST archive contains a huge collection of security related materials.
The Center for Education and Research in Information Assurance and Security (CERIAS) 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.
The various CERT teams such as http://www.cert.org and http://www.auscert.org.au.
Mailing lists such as Bugtraq and Firewall Wizards.

&footer