Mr Thomas wrote me regarding mail/horde4-imp and a particular vulnerability. Specifically, he figured that a recent commit (link to mail archives) fixed a bad entry in vuxml. Let’s look into that now.
I first compared dev, beta, and production. All three had the port flagged as vulnerable. This situation is indicated by a skull at the top of the page, in the ‘Port details’ section. However, only production listed any particular revisions/commits as being vulnerable. This is indicated by skull beside the commit date / revision number. Production also listed versions > 5.0.3 as vulnerable. None of this matches the definition of the vulnerability at the vuxml site, which clearly states:
- 4.2,1 < horde-imp < 4.3.8,1
- horde-imp < 4.3.8
Let’s look at vuln.xml:
<name>horde-imp</name> <range><gt>4.2,1</gt><lt>4.3.8,1</lt></range> <range><lt>4.3.8</lt></range>
The next check: has FreshPorts processed the latest vuxml file?
Clicking on the skull takes us to http://www.freshports.org/vuxml.php?package=horde-imp, where you can see:
The last vuln.xml file processed by FreshPorts is:
Revision: 1.2451
Date: 2011/09/23
Time: 20:02:19
Committer: delphij
If we compare that to the most recent commit for security/vuxml, we can confirm the revision number. Yes, that matches up.
That looks right.
OK, what ports have a package name of horde-imp?
freshports.org=# select id, category || '/' || name as port from ports_active where package_name = 'horde-imp'; id | port -------+----------------- 21107 | mail/horde-imp 28743 | mail/horde4-imp (2 rows) freshports.org=#
This confirms that this vuxml entry affects both horde4-imp and horde-imp. However, we are only interested in id = 28743.
Looking in the log for the vuxml processing, I found nothing to indicate that 28743 is vulnerable to anything. Up to this point, I was doing everything on the dev server. Next, I went to the production server and checked the vuxml log. Nothing there either. OK, so perhaps this is something else entirely.
Next, I went to production and cleared the cache for all mail/horde* ports. Ahah! Now prod, dev, and test are in agreement.
The only issue now is the vulnerability skull at the top of the page. This usually indicates that a vulnerability affects the latest revision of the port. Hmmm, this needs further investigation.
This query shows that FreshPorts thinks there is a current vulnerability:
freshports.org=# select * from ports_vulnerable where port_id = 28743; port_id | current | past ---------+---------+------ 28743 | 1 | 0 (1 row) freshports.org=#
As a test, I reran, with a commit, the adjusting function:
freshports.org=# select * from ports_vulnerable where port_id = 28743;
port_id | current | past
---------+---------+------
28743 | 1 | 0
(1 row)
freshports.org=# begin;
BEGIN
freshports.org=# select PortsVulnerabilityCountAdjust(28743);
portsvulnerabilitycountadjust
-------------------------------
0
(1 row)
freshports.org=# select * from ports_vulnerable where port_id = 28743;
port_id | current | past
---------+---------+------
(0 rows)
freshports.org=# rollback;
ROLLBACK
freshports.org=# select * from ports_vulnerable where port_id = 28743;
port_id | current | past
---------+---------+------
28743 | 1 | 0
(1 row)
freshports.org=#
My conclusion: PortsVulnerabilityCountAdjust() was not invoked for this port.
The vuxml log confirms this.
Offhand, I think the solution is to delete everything from ports_vulnerable each time we process a new vuxml file.
That’s all for tonight. I want to think about this for a while longer.
