nanog mailing list archives

Re: sub $500-750 CPE firewall for voip-centric application


From: amuse <nanog-amuse () foofus com>
Date: Fri, 6 May 2016 09:59:54 -0700

One question I have is:  Is there any reason to believe that the source
code for Sonicwall, Cisco, etc are any better than the PFSense code?  Or
are we just able to see the PFSense code and make unfounded assumptions
that the commercial code is in better shape?

On Fri, May 6, 2016 at 9:39 AM, Mel Beckman <mel () beckman org> wrote:

I, too, was not impressed with PFSense’s code. I’ve had to dig into it a
couple of times to troubleshoot weird failure modes. I finally gave up. My
time is too valuable, and the price of modern firewalls is fair for the
value you get in serious regression testing and support.

Also, I would not characterize PFSense as “reliable”. My PFsense boxes
still require periodic reboots due to memory leaks, and sometimes just lock
up. Yes, that happens with commercial boxen, but those events are far more
rare.

 -mel


On May 6, 2016, at 9:24 AM, Nick Hilliard <nick () foobar org> wrote:

amuse wrote:
+1 to a "Can you substantiate that claim please?" sentiment here.  I've
used it for years and found it to be reliable, flexible, feature-filled.
And having the BSD CLI fully available has been a godsend.

The code quality is terrible in a 1990s sort of way.  I.e. no separation
of code, html, logic, data structure or anything else.  Everything is
jumbled in together using coding methodologies which don't scale and
which make it almost impossible to audit in a meaningful way.

Specific problems:

1. the installation image ships with static dh params files, e.g.


https://github.com/pfsense/pfsense/blob/master/src/etc/dh-parameters.1024

This is a really bad idea and someone should issue a CVE for it.  The
reasons are clearly explained at:

https://weakdh.org/

https://www.schneier.com/blog/archives/2015/05/the_logjam_and_.html

2. http params validation: a cursory glance at the output of "grep -r
_GET pfsense/src" show that the authors did not use any http parameters
validation.  In addition, the output of $_GET is used unsafely in
multiple locations.

3. the output of "grep -wr exec pfsense/src | grep 'rm -rf'" shows what
looks like exploitable problems due to poor shell escaping.

This isn't an audit or anything, btw.  It's the result of a couple of
minutes glancing over the code.  I'm sure an audit would produce a lot
more.

Nick




Current thread: