Public-key based signing infrastructure
-
I'm concerned about the lack of a means to establish trust between my pfSense routers and the data retrieved from the pfsense.org servers. From the /etc/rc.update_bogons.sh script that's cron'd right out of the box to packages and firmware updates a MITM could easily exploit this "trusted by default" design and completely compromise our collective routers.
Public-key based signing infrastructure would substantially reduce the attack surface area and benefit us all. Fortunately it's not difficult to implement. It may require additional effort however if, for example, the signing key(s) were to be kept offline and manually introduced at build time. That's certainly not mandatory, as an attacker on a compromised build server would only have to wait until build/sign time to snag the private key(s), but it follows portsnap's precedent.
-
Firmware updates are signed. Packages ideally should be going forward, they're no diff than FreeBSD's pkg_add and pretty much every other similar functionality in any other system.
What's the amount you're offering?
-
@cmb:
Firmware updates are signed.
My mistake. The current firmware update system is however vulnerable to freeze, replay, and endless data attacks.
The update bogons rc script could be MITM'd and replaced with a blank file, opening the door to bogons-based attacks.
@cmb:
Packages ideally should be going forward, they're no diff than FreeBSD's pkg_add and pretty much every other similar functionality in any other system.
It's great to hear that the intentions for future adoption are there. For the record though, FreeBSD's pkgng does–or at least the author intends for it to--support package signing (per the FreeBSD wiki). PCBSD uses signed packages, as do the package managers of the most common Linux flavors: pacman, yum, apt/dpkg, portage/emerge, and on.
@cmb:
What's the amount you're offering?
Apologies, I didn't know whether here was the appropriate forum to post this on. If it belongs on the Development board please feel free to move it there (or I can delete the thread and start a new one there). I think though that the information presented here and the awareness that it raises might motivate others to join in the bidding. Otherwise for compliance sake I could start the bidding at $1.
-
We use PBIs in 2.1 and newer, same as PCBSD, and will eventually implement signing support probably as part of a bigger revamp of the package system (for instance to better classify production grade packages vs. ones for messing around with at most).
For bogons, if someone can MITM your traffic, they can do far worse and far more effective things than attacking your bogons file. No real concern there, but it's something I've considered and we may change.
The current firmware update system is however vulnerable to freeze, replay, and endless data attacks.
None of which impact the integrity of the system. A DoS at most, which can be achieved in other far easier ways, like just bombarding you with crap and filling your Internet connection. There are endless far more interesting and fruitful things to do if you can MITM. That's something that would never actually happen in the real world, but if you're interested in implementing, as always, patches welcome.
-
@cmb:
For bogons, if someone can MITM your traffic, they can do far worse and far more effective things than attacking your bogons file. No real concern there, but it's something I've considered and we may change.
That may or may not be the case. Effectiveness would be dependent entirely on the configuration of the network and systems behind the router. At any rate I appreciate the consideration. For those reading and concerned, manually editing your cron file and ensuring you have an up-to-date bogons file would serve as a stop-gap.
@cmb:
The current firmware update system is however vulnerable to freeze, replay, and endless data attacks.
None of which impact the integrity of the system. A DoS at most, which can be achieved in other far easier ways, like just bombarding you with crap and filling your Internet connection. There are endless far more interesting and fruitful things to do if you can MITM. That's something that would never actually happen in the real world, but if you're interested in implementing, as always, patches welcome.
In this case a freeze attack would involve an attacker intercepting a firmware update and feeding back to the update process the same version of the firmware as existed on the router. If the firmware update was released to patch a significant security hole the system would simply reinstall the unpatched version of pfSense leaving the system still vulnerable to the security hole the update was intended to patch, very much impacting the integrity of the system.
A replay attack would involve an attacker intercepting a firmware update and feeding the system a prior version of the firmware to the one currently on the router, "downgrading" the system to a version vulnerable to attack.
An endless data attack is essentially–as you state--a DoS attack, and I agree with you, it's unlikely to ever occur.
-
In this case a freeze attack would involve an attacker intercepting a firmware update and feeding back to the update process the same version of the firmware as existed on the router. If the firmware update was released to patch a significant security hole the system would simply reinstall the unpatched version of pfSense leaving the system still vulnerable to the security hole the update was intended to patch, very much impacting the integrity of the system.
Which would be noticed by anyone paying any kind of attention, reboot and you're still on the same version. Still has no impact on the integrity, it would only install an official update. Besides if it's so hackable, why would anyone bother just ensuring it stays that way? Own the box and be done with it. In that case you'd likely want to patch it yourself after you owned it. Everything here, short of issues addressed by PBI signing, are way out there. If you care enough to put your time into addressing such things, we'd accept patches, but I'm not going to pay people to address theoretical problems that will never, ever happen because there are a million worse things you could do completely unrelated to the firewall if you were in a position to do those.
We have considered pulling everything via HTTPS at some point in the future and verifying the cert, which would help address all these too.