diff --git a/en/security/advisories.xml b/en/security/advisories.xml
index 1837921131..481800d202 100644
--- a/en/security/advisories.xml
+++ b/en/security/advisories.xml
@@ -1,214 +1,452 @@
-
-
+
+
%includes;
]>
-
+
&header;
-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.
-
-We welcome your comments on the contents and correctness of this page.
-Please send email to the
-FreeBSD Security Officers if you have changes you'd like to see here.
-
-The FreeBSD security officer
-
-FreeBSD takes security seriously, a dedicated team of security officers
-providing a focal point for security related communications. A security
-officers' main task is to send out advisories when there are known security
-holes and otherwise keep abreast of security issues. The security officers
-also communicate with the various CERT
-and FIRST teams around the world,
-sharing information about vulnerabilities in FreeBSD or utilities commonly
-used by FreeBSD, and keeping up to date on security issues in the world at
-large. The security officers are also active members of those
-organizations.
-
-When you need to contact the security officers about a sensitive matter,
-please use their
-PGP key
-to encrypt your message before sending it.
-
-FreeBSD security advisories:
-
-The FreeBSD security officers provide security advisories for
-the following releases of FreeBSD:
+Introduction
+
+This web page is designed to assist both new and experienced users
+in the area of security for the FreeBSD Operating System. The FreeBSD
+Development team 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 outside attack,
+whom to contact if you find a security related bug, etc. There is
+also a section on the various ways that the systems programmer can
+become more security conscious so he or she is less likely to
+introduce security holes in the first place.
+
+Table Of Content
+
+
+
+The FreeBSD Security Officer
+
+To better coordinate information exchange with others in the security
+community, FreeBSD has a focal point for security related communications:
+The FreeBSD security officer.
+The position is actually staffed by a team of dedicated security officers,
+their main tasks being to send out advisories when there are known security
+holes and to act on reports of possible security problems with FreeBSD.
+
+If you need to contact someone from the FreeBSD team about a
+possible security bug, you should therefore please send mail to the Security Officer
+with a description of what you've found and the type of vulnerability it
+represents. The Security Officers also communicate with the various
+CERT and FIRST teams around the world,
+sharing information about possible vulnerabilities in FreeBSD or
+utilities commonly used by FreeBSD. The Security Officers are also
+active members of those organizations.
+
+If you do need to contact the Security Officer about a particularly
+sensitive matter, please use their PGP key
+ to encrypt your message before sending it.
+
+
+FreeBSD Security Advisories
+
+The FreeBSD Security Officers provide security advisories for the
+following releases of FreeBSD:
-- the most recent official release of FreeBSD,
-
- FreeBSD-current,
+
- The most recent official release of FreeBSD.
+
- FreeBSD-current.
- FreeBSD-stable, when at least 2 releases are based on it.
-
- the previous FreeBSD-stable when a "new stable" does not
- yet have 2 releases based on it.
+
- The previous FreeBSD-stable when a "new stable" does not yet
+ have 2 releases based on it.
At this time, security advisories are available for:
-- FreeBSD 2.2.6
+
- FreeBSD 2.2.7
+
- FreeBSD 2.2.8
+
- FreeBSD 3.0
- FreeBSD-current
- FreeBSD-stable
-Older releases will not be actively maintained and users are strongly
-encouraged to upgrade to one of the supported releases.
-
-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).
+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 then sent out.
+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 then sent
+out.
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
+
+
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:
-FreeBSD security related information
+
+FreeBSD Security Mailing Lists Information
-If you want to stay up to date on FreeBSD security, you can subscribe
-yorself to one of the following mailing lists:
+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)
+freebsd-security General security related discussion
+freebsd-security-notification Security notifications (moderated mailing list)
-Send mail to majordomo@FreeBSD.ORG
-with
+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
+
-What to do when you detect a security compromise:
-
-
-- Determine the level of security breach:
-What privilege did the attack get? That of another user or more (up to
-root privileges)?
-
-- Determine those parts of the system which are not in their original state
-anymore:
-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 also keeps MD5 checksums, though be aware that tripwire might
-be tampered with as well and be sure and use a known-good copy.
-
-- Find out how the breakin was done:
-Via a well-known security bug? A misconfiguration? If it's a new bug,
-you should warn the
-FreeBSD Security Officer.
-
-- Fix the hole(s):
-Install new software that fixes the problems. If you aren't able to get
-a fix quickly, you should temporarily disable remote access to your system
-until you have done so.
+
+Secure Programing 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 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 - 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 for, 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(), mkstemp() and
+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_EXECL
+
+If you use mkstemp - 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 NONEof 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.
+
+
+- Don't 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 then
+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 have already arrangements for a second glance over your
+code. Don't commit code you are not sure about since breaking something
+in the name of 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 changed 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 (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 in 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 a 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.
+
-Other questions you may ask yourself are:
+
+FreeBSD Security Tips and Tricks
+There are several steps one must take to secure a FreeBSD system, or
+in fact any Unix system:
-- Who do I warn? You can contact the security officer, or even the
-local authorities. The choice is up to you.
-
-- 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.
+- 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 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' command)
+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.
+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 could get updates on security bugs and get
+fixes. Apply the fixes immediately.
+
+ - Backups - repair your system if security breach does occur
+Always have backups and a clean version of the operating system (e.g. on
+CD-Rom). Make sure your backups don't contain corrupted or modified by
+attackers data.
+
+ - 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 that 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 are several steps involved in securing a FreeBSD system, or in
-fact, any UNIX system:
+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
-Other useful security information:
+
+- Determine the level of the security breach
+What privileges did the attacker get? Did the attacker managed to get
+root access? Did the attacker only managed 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 breaking occur via a well know security bug? If that is the case,
+make sure to install the correct patches. Was the breaking successful due
+to a misconfiguration? Was the breakin result of a new bug? If you believe
+the breakin 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 already 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 material.
-
--
- The COAST Security hotlist
- This page is THE place to start looking for security related
- material. It contains hundreds of useful
- security pointers. Everything you always wanted to know about
- security...and more...
-
-- The various CERTs (e.g. www.cert.org and
- www.auscert.org.au)
+archive contains a huge collection of security related materials.
-- SecurityPortal.com
-is intended to be the comprehensive Web site for Internet
-Security. It is dedicated to providing corporate security professionals
-with the information and resources needed to protect their networks. We
-summarize breaking security news and provide a jumping off point for
-Security Alerts, Products, Tools, Tips & Tricks and other Resources.
-
+- The COAST Security
+Hotlist 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.
-- Mailing lists: Bugtraq, BOS, etc.
+- 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
-
+ &footer
+