diff --git a/en/security/advisories.xml b/en/security/advisories.xml
index f4b2ae2b3b..fe72bf23e0 100644
--- a/en/security/advisories.xml
+++ b/en/security/advisories.xml
@@ -1,847 +1,1750 @@
-
-
-
- %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 the
-following releases of FreeBSD:
-
-
-- The most recent official release of FreeBSD.
-- 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.
-
-
-At this time, security advisories are being released for:
-
-- FreeBSD 4.6-RELEASE
-- FreeBSD 4.7-RELEASE
-- FreeBSD 4.7-STABLE
-- FreeBSD 5.0-RELEASE
-
-
-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
-
-