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 <n...@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
