Sep 252011
 

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.

Website Pin Facebook Twitter Myspace Friendfeed Technorati del.icio.us Digg Google StumbleUpon Premium Responsive