This morning during my usual scan of the infosec news I hit upon PwnKit, a Linux privilege escalation bug that I wanted to spend a few minutes blogging about. This blog caught my eye because it directly affects the security model that some (but not all!) folks use when configuring Linux machines. Plus this exploit has a few other interesting features that I’ll explain below.
TLDR; PwnKit allows someone with access to a Linux machine to escalate their privileges to root.
How serious? This bug is likely only a risk for environments that rely strongly on Linux permissions — where certain Linux accounts have more privilege than others. That said, if the attacker has no way to get onto your Linux machine, she can’t exploit the bug. So, while you should probably patch this, it is nowhere near as risky as the log4j vulnerability that came out last month.
A couple of other interesting things:
This bug has been there forever. This bug was likely present in the Linux kernel for 12 years. This has resulted in some screamy headlines, but I’m fairly unsurprised. Lots of these subtle bugs live in OSS code for years, where no one bothers to look, until they eventually get found by someone and then patched. This is what happened with Heartbleed (found 2014, present in the code since 2011) and with log4j (found December 2021, present in the code since 2013.) In fact, back at Boston University in 2015 my team found a bug just like that in the NTP (Network Time Protocol) The “Kiss of Death” bug we found was present in the codebase for almost a decade when we found it.
So this all brings to mind a favorite xkcd. Critical parts of our modern software stack are maintained by some guy that no one knows, or is paying, to maintain the code.
It is reliably exploitable. It looks like this bug is not part of a Rube Goldberg machine, where everything needs to go exactly right before it can be exploited. Rather, there are claims that this bug is reliably exploitable.
How to think about privilege on Linux. There are lots of different ways to think about Linux permissions. My team at BastionZero has probably paid an outsized amount of attention to this issue, because BastionZero can be used to set policy-based access control that maps users (e.g. email@example.com) to Linux accounts (e.g. centos, root, readonly).
Here’s a picture of how the policy-based mapping looks in BastionZero — I’ve circled the mapping from user to Linux account in the policy manager, to ensure that when I log into this set of Linux targets, I do so as the centos user, rather than as a more privileged user (e.g. root).
This is classic privilege access management, where BastionZero controls what account a given user can access. (By the way, BastionZero makes this passwordless — so that your users don’t have to remember passwords for each Linux machine they log into.)
So, in sum, if you are relying on using different accounts on Linux machines as part of your security strategy, you should patch PwnKit immediately to avoid falling victim to the new Linux exploit. And for those of you who aren’t, you probably need to patch anyway as part of your SOC2 strategy. So happy patching!
See BastionZero in Action
BastionZero connects teams to resources and requires no additional infrastructure to deploy or manage. It is the first—and only—cloud-native solution for trustless access providing multi-root authentication while maintaining zero entitlements to your systems.
With BastionZero, you can reclaim your architecture from over-privileged third parties and ensure that the right people have access to the right resources at just the right time—every time.
Schedule a demo now to see how you can trust less and access more with BastionZero.