# ports tree and out of date vulnerable ports



## chrcol (Mar 18, 2010)

Ok so freebsd itself is regurly maintained and updated however I am concerned about how various internet facing apps in the port tree are often out of date for a period of time in a vulnerable state.

We still have php on a vulnerable version with it seems noone too bothered (is everyone just running freebsd on the desktop now days?).  We also now have apache in a vulnerable state, in the past I have seen various other apps take a while for updates to be commited, and of course around every 6 months and sometimes even less the ports tree gets frozen for many weeks.

Right now there is 5 security CVE against apache22 and I have been told due to port slush and to do with devel/apr I will likely be waiting until end of march to mid april for an update.
I submitted the information so portaudit would list 2.2.14 of apache22 as vulnerable but have not even had a auto response after many days.

Is freebsd no longer a security aware operating system? the ports tree is part of freebsd and its wrong to let it rot.

It seems to upgrade php to the new version I had to edit a total of 7 lines, and the port still awaits this change.


----------



## SirDice (Mar 18, 2010)

chrcol said:
			
		

> Right now there is 5 security CVE against apache22 and I have been told due to port slush and to do with devel/apr I will likely be waiting until end of march to mid april for an update.


One is SSL/TLS related, if you don't use it you're not vulnerable.
There's also mod_proxy_ajp, mod_isapi and mod_headers. Mod_isapi is Windows only. And if you don't use the other modules, you're not vulnerable.

Patching a vulnerable system is advised of course but you can also take mitigating actions instead of patching. Mitigating actions would include disabling those vulnerable modules.


----------



## DutchDaemon (Mar 18, 2010)

What are the 5 CVEs?

E.g. when Apache was updated to 2.2.14, this was the comment:


```
- Update to 2.2.14
- With hat apache@

Note: [B]The 3 CVE's are a no-op for the FreeBSD port[/B] --

date: 2009/08/25 05:33:03;  author: kuriyama;  state: Exp;  lines: +0 -0
(Forced commit)

- 2.2.13 (acutally 2.2.12) includes fixes for several CVEs. [1]
  but in our ports tree, APR related ones (CVE-2009-0023,
  CVE-2009-1955, CVE-2009-1956) were already backported in 2.2.11_5.
```

For 2.2.14, I see three CVEs on the Apache site (listed as "Fixed in Apache httpd 2.2.15"), one of which is for Windows only, and all of them are still 'under review', i.e. not confirmed/official. And they may still be a no-op for the FreeBSD port (which may be why VuXML doesn't mention them).


----------



## SirDice (Mar 18, 2010)

2.2.15 fixes 4 CVEs


----------



## DutchDaemon (Mar 18, 2010)

Oh. Well, http://httpd.apache.org/security/vulnerabilities_22.html shows three, all "(under review)".


----------



## SirDice (Mar 18, 2010)

DutchDaemon said:
			
		

> Oh. Well, http://httpd.apache.org/security/vulnerabilities_22.html shows three, all "(under review)".



Strictly speaking the other CVE is openssl related


----------



## chrcol (Mar 20, 2010)

5 listed here.

http://www.apache.org/dist/httpd/CHANGES_2.2

I do use ssl/tls and I dont know how to manually fix this without patching apache.


----------



## gilinko (Mar 20, 2010)

chrcol said:
			
		

> 5 listed here.
> 
> http://www.apache.org/dist/httpd/CHANGES_2.2
> 
> I do use ssl/tls and I dont know how to manually fix this without patching apache.



And the two first ones are the same CVE(CVE-2009-3555) one is the first partial fix, one is the comprehensive fix for the mod_ssl module. So if you aren't using mod_ssl it will not affect you. 

The forth one is only for windows. The third one is for the mod_proxy module, it is the same as the mod_ssl. If you don't use it, you aren't vulnerable. The last one is only for threaded MPM's, and not the default prefork MPM. 

As you say that you are using the mod_ssl apache module, and you will just have to wait until the port is updated and open a PR so that the port maintainer is made aware of the new version if it has been missed. It has only been about 10 days since the release of 2.2.15...

If they are holding of an update it is for good reasons, as is the same for the php version. There are a LOT of software that depends on apache/apr and php in the ports tree and all of them has to be checked so that nothing get messed up on the way.


----------



## chrcol (Mar 21, 2010)

the maintainer is aware and told me it could be the middle of april it will be updated as he is away from home.

10days is already a moderate amount of time, the php update is defenitly considered a long time.  Once something is disclosed then anything over a week is considered a long time.

As I am asking in my original post if people think 10 days (and counting) is nothing to be worried about it maybe does answer my question that freebsd is no longer security aware.  PHP has even had a patch submitted weeks ago and is still not commited.  All operating systems have the same problem with checking but debian and centos managed to upgrade within a few days of the src been updated.

I myself am happy to help with testing etc. but if I have to wait weeks for commits is there a point or can multiple people be committers for the same ports?


----------



## graudeejs (Mar 21, 2010)

become committer and maintainer of php port


----------



## SirDice (Mar 22, 2010)

Turn off renegotiation.


----------



## gcooper@ (Mar 22, 2010)

Or just manually roll your own port after discussing it with portmgr@ / the maintainer, and keep it in-house until the time comes where the official update has been committed back?

You can always commit the change locally, thoroughly test it out, then contribute back the patch. This is an opensource community so no one is blocking you from doing that ...


----------



## chrcol (Mar 23, 2010)

SirDice said:
			
		

> Turn off renegotiation.



how to do this in apache?


----------



## chrcol (Mar 23, 2010)

gcooper@ said:
			
		

> Or just manually roll your own port after discussing it with portmgr@ / the maintainer, and keep it in-house until the time comes where the official update has been committed back?
> 
> You can always commit the change locally, thoroughly test it out, then contribute back the patch. This is an opensource community so no one is blocking you from doing that ...



this is already planned, but what can I do for others if I submit a patch but it then doesnt get commited? which seems to be the problem on php at the moment, a patch has been sitting there for weeks.


----------

