English Norwegian Bokmål
Chapter 12. Security
Security
Why Security is So Important
Bugs are occasionally introduced to the software. Arguably, the most dangerous of them are those opening security vulnerabilities. From the technical viewpoint, such vulnerabilities are to be closed by exterminating the bugs that caused them. However, the policies for handling mere bugs and security vulnerabilities are very different.
A typical small bug affects only those users who have enabled some combination of options triggering the bug. The developer will eventually release a patch followed by a new version of the software, free of the bug, but the majority of users will not take the trouble of upgrading immediately because the bug has never vexed them. A critical bug that may cause data loss represents a graver issue. Nevertheless, prudent users know that a lot of possible accidents, besides software bugs, are likely to lead to data loss, and so they make backups of important data; in addition, a critical bug will be discovered really soon.
A security vulnerability is all different. First, it may remain unnoticed for years because often it does not cause software malfunction. Second, a malicious party can use it to gain unauthorized access to a vulnerable system, to destroy or alter sensitive data; and in the worst case the user will not even notice the harm caused. Third, exposing a vulnerable system often assists attackers to break into other systems that could not be compromised otherwise. Therefore closing a vulnerability alone is not enough: notify the audience of it in the most clear and comprehensive manner, which will allow them to evaluate the danger and take appropriate action.
Fixing Security Vulnerabilities
While on the subject of ports and packages, a security vulnerability may initially appear in the original distribution or in the port files. In the former case, the original software developer is likely to release a patch or a new version instantly. Update the port promptly with respect to the author's fix. If the fix is delayed for some reason, either <<dads-noinstall,mark the port as `FORBIDDEN`>> or introduce a patch file to the port. In the case of a vulnerable port, just fix the port as soon as possible. In either case, follow <<port-upgrading,the standard procedure for submitting changes>> unless having rights to commit it directly to the ports tree.
Being a ports committer is not enough to commit to an arbitrary port. Remember that ports usually have maintainers, must be respected.
Please make sure that the port's revision is bumped as soon as the vulnerability has been closed. That is how the users who upgrade installed packages on a regular basis will see they need to run an update. Besides, a new package will be built and distributed over FTP and WWW mirrors, replacing the vulnerable one. Bump `PORTREVISION` unless `DISTVERSION` has changed in the course of correcting the vulnerability. That is, bump `PORTREVISION` if adding a patch file to the port, but do not bump it if updating the port to the latest software version and thus already touched `DISTVERSION`. Please refer to the <<makefile-naming-revepoch,corresponding section>> for more information.
Keeping the Community Informed
The VuXML Database
A very important and urgent step to take as early after a security vulnerability is discovered as possible is to notify the community of port users about the jeopardy. Such notification serves two purposes. First, if the danger is really severe it will be wise to apply an instant workaround. For example, stop the affected network service or even deinstall the port completely until the vulnerability is closed. Second, a lot of users tend to upgrade installed packages only occasionally. They will know from the notification that they _must_ update the package without delay as soon as a corrected version is available.
Given the huge number of ports in the tree, a security advisory cannot be issued on each incident without creating a flood and losing the attention of the audience when it comes to really serious matters. Therefore security vulnerabilities found in ports are recorded in https://vuxml.freebsd.org/[the FreeBSD VuXML database]. The Security Officer Team members also monitor it for issues requiring their intervention.
Committers can update the VuXML database themselves, assisting the Security Officer Team and delivering crucial information to the community more quickly. Those who are not committers or have discovered an exceptionally severe vulnerability should not hesitate to contact the Security Officer Team directly, as described on the https://www.freebsd.org/security/#how[FreeBSD Security Information] page.
The VuXML database is an XML document. Its source file [.filename]#vuln.xml# is kept right inside the port package:security/vuxml[]. Therefore the file's full pathname will be [.filename]#PORTSDIR/security/vuxml/vuln.xml#. Each time a security vulnerability is discovered in a port, please add an entry for it to that file. Until familiar with VuXML, the best thing to do is to find an existing entry fitting the case at hand, then copy it and use it as a template.
A Short Introduction to VuXML
The full-blown XML format is complex, and far beyond the scope of this book. However, to gain basic insight on the structure of a VuXML entry only the notion of tags is needed. XML tag names are enclosed in angle brackets. Each opening <tag> must have a matching closing </tag>. Tags may be nested. If nesting, the inner tags must be closed before the outer ones. There is a hierarchy of tags, that is, more complex rules of nesting them. This is similar to HTML. The major difference is that XML is e__X__tensible, that is, based on defining custom tags. Due to its intrinsic structure XML puts otherwise amorphous data into shape. VuXML is particularly tailored to mark up descriptions of security vulnerabilities.
Now consider a realistic VuXML entry:
<vuln vid="f4bc80f4-da62-11d8-90ea-0004ac98a7b9"> <.>
<topic>Several vulnerabilities found in Foo</topic> <.>
<affects>
<package>
<name>foo</name> <.>
<name>foo-devel</name>
<name>ja-foo</name>
<range><ge>1.6</ge><lt>1.9</lt></range> <.>
<range><ge>2.*</ge><lt>2.4_1</lt></range>
<range><eq>3.0b1</eq></range>
</package>
<package>
<name>openfoo</name> <.>
<range><lt>1.10_7</lt></range> <.>
<range><ge>1.2,1</ge><lt>1.3_1,1</lt></range>
</package>
</affects>
<description>
<body xmlns="http://www.w3.org/1999/xhtml">
<p>J. Random Hacker reports:</p> <.>
<blockquote
cite="http://j.r.hacker.com/advisories/1">
<p>Several issues in the Foo software may be exploited
via carefully crafted QUUX requests. These requests will
permit the injection of Bar code, mumble theft, and the
readability of the Foo administrator account.</p>
</blockquote>
</body>
</description>
<references> <.>
<freebsdsa>SA-10:75.foo</freebsdsa> <.>
<freebsdpr>ports/987654</freebsdpr> <.>
<cvename>CAN-2010-0201</cvename> <.>
<cvename>CAN-2010-0466</cvename>
<bid>96298</bid> <.>
<certsa>CA-2010-99</certsa> <.>
<certvu>740169</certvu> <.>
<uscertsa>SA10-99A</uscertsa> <.>
<uscertta>SA10-99A</uscertta> <.>
<mlist msgid="201075606@hacker.com">http://marc.theaimsgroup.com/?l=bugtraq&amp;m=203886607825605</mlist> <.>
<url>http://j.r.hacker.com/advisories/1</url> <.>
</references>
<dates>
<discovery>2010-05-25</discovery> <.>
<entry>2010-07-13</entry> <.>
<modified>2010-09-17</modified> <.>
</dates>
</vuln>