Hardening Guide for phpList

phpList Hardening Guide Featured Image

This post will outline recommended steps to harden phpList after install to make it reasonably secure.

phpList is the most popular open-source software for managing mailing lists. Like wordpress, they have a phplist.com for paid hosting services and phplist.org for free self-hosting.

Earlier this week, it was announced that phpList had a critical security vulnerability permitting an attacker to bypass authentication and login as an administrator using an incorrect & carefully-crafted password in some cases. This bug is a result of the fact that [a] PHP is a loosely typed language and [b] the phpList team was using the '==' operator to test for equality of the user's hashed password against the DB. This security pitfall has been known in PHP since at least 2010 (a decade ago!), but I'm sure the same mistake will be made again..

Indeed, security is porous. There's no such thing as 100% vulnerability-free code, and phpList is no exception. But if we're careful in adding layers of security to our infrastructure, then we might be able to protect ourselves from certain 0-days.

That said, here's my recommended steps to making your phpList install reasonably secure.


. . . → Read More: Hardening Guide for phpList

FreeBSD Perils

As stated in my last post, my server died several months ago, and I decided to take that unfortunate opportunity to gain some Unix experience by installing FreeBSD on its replacement. Although this server has been installed for several months, the main reason that this weblog has been down is because of multiple configuration issues with FreeBSD that, frankly, I think should have worked Out Of The Box.

A friend of mine who is adamant about FreeBSD told me to name this inevitable post "FreeBSD from a gentoo user's perspective." It's true that my desktop's distro of choice has been gentoo for several years, but I'm no ricer. I love gentoo because I love portage--the gentoo package manager which is, in fact, a derivative of FreeBSD's ports package manager. I don't care much for any package manager that doesn't give you the option to change compile-time options. Anyway, I'm going to try my best to leave any bias-ness I may have behind me as I work through the multitude of flaws that I encountered with setting up a FreeBSD webserver.

As a gentoo user, I can understand the expected perils of using a system that is designed to have both
. . . → Read More: FreeBSD Perils

`ps` fail with sys-process/procps

Today, I ran an `emerge -uDN world`, and mysql kept failing on the ./configure step because it couldn't properly execute `ps`.

For as long as I can remember, my gentoo box has been unable to run `ps`. Every time I did, I'd get a "No such file or directory" error regarding /lib64/libproc-3.2.6.so

Upon further investigation, I found that an `ls /lib64/libproc*` showed two files:

/lib64/libproc-3.2.7.so /lib64/libproc.so

...so, `ps` was trying to access 3.2.6, and I had 3.2.7. Obviously something was out of whack--probably an environment variable. I tried creating a /lib64/libproc-3.2.6.so symlink back to the /lib64/libproc-3.2.7, but `ps` only failed with a different error.

So, naturally, I figured I would simply unmerge and re-emerge the package. An `emerge --search libproc` reveled only one package: dev-libs/libproccpuinfo. After unmerging and re-emerging this package a dozen times, I fell back to google. Turns out that the REAL package for the libproc.so file is sys-process/procps. When I got the...

!!! 'sys-process/procps' is part of your system profile. !!! Unmerging it may be damaging to your system.

>>> Waiting 10 seconds before starting...

...message, I was sure that I'd break my system, but I continued, finished the unmerge, re-emerged the package, crossed my fingers, and
. . . → Read More: `ps` fail with sys-process/procps