How to disable vulnerability checking for FreeBSD ports

What do you do when you need to install a port with a reported vulnerability on FreeBSD? Chad Perrin supplies you with the solution.

What do you do when you need to install a port with a reported vulnerability on FreeBSD?

One of the great things about FreeBSD is its security tools, and the fact that some of these tools are designed to keep the user informed. The article, "How FreeBSD makes vulnerability auditing easy: portaudit," explains one of these tools, and how it can help the user maintain a secure system.

Normally, when you encounter a vulnerability reported by the portaudit tool, there is a patch for the reported vulnerability that can be installed to solve the problem. There are occasionally instances where one has to wait a little while for a fix to appear, however.

One's first reaction to this might be to question why vulnerabilities are being left unaddressed when they are reported, but the fact of the matter is that, in some cases, fixing the relevant vulnerability is beyond the control of the FreeBSD core developers. The software in the ports system is primarily a collection of software outside of the FreeBSD base system that can be installed if the user desires it, developed and maintained by independent development projects and made available in the ports system by the efforts of people providing a convenience to FreeBSD users.

Far from being a failure on the part of the FreeBSD project, a port with a reported vulnerability and no available fix is in fact a result of the FreeBSD project's contributors doing what they can to keep the user informed. Of course, a question arises: How should we handle security notifications? Is it better to keep quiet about a vulnerability until it is fixed in the hopes that knowledge of the vulnerability will be kept out of the hands of malicious security crackers, or to tell the people affected by the vulnerability so they can take any necessary measures to protect themselves?

In the case of the FreeBSD ports system, it may be a moot point. The vulnerabilities reported by the portaudit tool tend to be vulnerabilities that are already publicly known, even if some of them may not be widely known. It is a matter of degrees, however; any vulnerability, once it is discovered by a well-meaning security researcher, may already be known by malicious security hackers in any case. With this in mind, and given the situation of a vulnerability in an installed port, the reports offered by the portaudit tool do offer advice on how to deal with them:

Affected package: linux-f10-pango-1.22.3_1

Type of problem: pango -- integer overflow.


1 problem(s) in your installed packages found.

You are advised to update or deinstall the affected package(s) immediately.

The advice in that last line, when it is at all reasonable to do so, is good advice to follow.

Unfortunately, there may be times when it is not such a reasonable choice. The Linux version of the pango library is a particular problem in this area; it seems to develop a new vulnerability every six months, and that vulnerability seems to get ignored all too often by the upstream maintainers at the Fedora project for far too long. Sometimes, it gets ignored indefinitely, when the Fedora project has moved on to a new OS release version and ceased supporting that particular version of the pango library.

In such cases, after reading the news at the reference URL provided for the vulnerability, a user may decide that keeping the library is necessary to ongoing operations and that the vulnerability in question is not a critical one under current usage. There may even be new versions of the library that are desired, but that still do not fix the vulnerability.

Of course, with portaudit on the job, the system will not normally allow the sysadmin to install vulnerable software. This includes updating software from one vulnerable version to another, too. What is a sysadmin to do?

Luckily, there is a solution to the problem -- a way to tell the system to ignore the vulnerability warning and, darnit, do what you want it to do anyway. One should think very carefully before taking this approach, but the option is there if one needs it.

If you use the basic make tools for installing a port, the syntax for disabling the vulnerability check long enough to install a vulnerable version of a port is reasonably simple:

# cd /usr/ports/x11-toolkits/linux-f10-pango


# make install clean

Many prefer to use the portupgrade tool, available in ports, to handle installing and updating software. The same make option can be passed to the portupgrade utility, using the -m command line option for either the portupgrade command (which can be used to update an installed port or, with the -N option, to install a new port) or the portinstall command (which is just syntactic sugar that means the same thing as portupgrade -N):

# portinstall -m DISABLE_VULNERABILITIES=yes linux-f10-pango

Remember, of course, that this should be an act only of the last resort. The preferred option, when faced with a vulnerability in a piece of software, should be one of the following:

  1. Upgrade to a fixed version of the software.
  2. Uninstall or disable the vulnerable software until a fixed version is available.
  3. Uninstall the vulnerable software and install an alternative that does not have known vulnerabilities.

In some cases, it will even be preferable to simply uninstall the software and do without it altogether. The Linux version of the pango library is unfortunately necessary for a stable Flash plugin for the Firefox browser on FreeBSD, but you should ask yourself: Just how necessary is Flash right now? For many of us, it is not nearly as important as our first, knee-jerk reaction might suggest.

Before you point out that you do not have this problem on MS Windows or Apple MacOS X, you should know that you almost certainly do have an unfixed vulnerability problem with Flash on those systems, and probably with several other pieces of software as well. Over the years, Flash has (along with its dependencies) proven to be a common source of vulnerability issues. On systems without tools like portaudit, however, you have an additional problem: you often do not know that you are vulnerable.