If you have not installed portaudit, you should. It will save you time. A little bit of work by those that maintain the FreeBSD vulnerability database saves a great deal of time for all the sysadmins out there. For example, this morning, I got this email:
To: root@dfc.example.org Subject: dfc.example.org security run output Message-Id: <20060914070411.ED31611439@dfc.example.org> Date: Thu, 14 Sep 2006 03:04:11 -0400 (EDT) From: root@dfc.example.org (Charlie Root) Status: U X-PM-PLACEHOLDER: . Checking setuid files and devices: Checking for uids of 0: root 0 toor 0 Checking for passwordless accounts: dfc.example.org login failures: dfc.example.org refused connections: Checking for a current audit database: Downloading fresh database. auditfile.tbz 37 kB 116 kBps New database installed. Database created: Thu Sep 14 02:40:21 EDT 2006 Checking for packages with security vulnerabilities: Affected package: php4-4.4.1_3 Type of problem: php -- multiple vulnerabilities. Reference: <http://www.FreeBSD.org/ports/portaudit/ea09c5df-4362-11db-81e1-000e0c2e438a.html> 1 problem(s) in your installed packages found. You are advised to update or deinstall the affected package(s) immediately. -- End of security output --
You do read your daily security messages don’t you? Shortly after this, I started upgrading the machines in question (the portaudit message appeared in multiple emails I got that day). I wondered why one older machine had not been affected. I investigated and found it had mod_php installed, not php4.
The vulnerability in question lists mod-php4 and mod-php5. The names listed under the Affects section refer to the package names. Under FreeBSD, the package name for the www/mod_php4 port is mod_php4. Note the underscore (_) not a hypen (-). You will also see that the port is no longer in the ports tree. And you may wonder: why worry about deleted ports? Well, I’m quite sure there will be installations other than mine still using this port. Marking it as vulnerable will prompt them to upgrade.
I did a quick check to find any affected names that did not match up with package names. Here is the query I used:
SELECT ‘<li><a href=”http://www.vuxml.org/freebsd/’ || V.vid || ‘”>’ || V.vid || ‘</a>’ || ‘ ‘ || VN.name || ‘</li>’
FROM vuxml_names VN, vuxml_affected VA, vuxml V
WHERE VN.vuxml_affected_id = VA.id
AND VA.vuxml_id = V.id
AND NOT EXISTS (SELECT id FROM ports P where P.package_name = VN.name)
ORDER BY VN.name
The result is 139 vuxml entries. Here is the complete list. Many of these are false positives. These are often the result of ports that play around with PKGNAMESUFFIX.
In my not so humble opinion, we should always be able to determine the package name via make -V. Without this basic strategy in place it becomes a nightmare to figure out what packages must be tagged as vulnerable.
