A Crack in the Linux Firewall | Hacker News Reader

A Crack in the Linux Firewall

randorisec.fr

264 pointsemilburzo64 comments

The proof of concept (PoC) itself relies on /tmp/ having mount 'exec' permissions. On systems with a separate /tmp/ and mounted with 'noexec' this would fail. This latter is one of a series of hardening steps that are useful in making executing untrusted code more difficult (but not impossible).

Fix is introduced in commit 7e6bc1f6cabcd30aba0b11219d8e01b952eacbb6. On the wider point of kernel corruption it isn't absolutely clear if the PoC relies on specific attributes of the target kernel builds or a suitable .config, and if so which, or very specific kernel versions between v4.1-rc1 and v5.19-rc7.

Article talks specifically about "Ubuntu 22.04" and shows kernel 5.15.0-27-generic in the poc.gif but the github README.md says 5.15.0-39-generic. No mention if this affects the -lowlatency kernels.

Recent Linux stable tree kernels carry the patch (e.g. v5.18.12 commit 6b7488071ea8ed6265a39afebd5a5920f6975d02).

The exploit fails (here) on stable tree v5.18.9 in an interesting way!

  $ ./poc
  [+] Second process currently waiting
  [+] Get CAP_NET_ADMIN capability
  [+] Netlink socket created
  [+] Netlink socket bound
  [+] Table table created
  [+] Set for the leak created
  [+] Set for write primitive created
  [*] Leak in process[-] add_key: Disk quota exceeded

This on an ext4 file-system with no quotas enabled and 9GiB free space.

The message via perror() is of course wrong; in fact during the call via SYSCALL_DEFINES(add_key, ...) in security/keys/keyctl.c a return value of 122 (EDQUOT) is returned. There are 3 call sites in that function that call PTR_ERR() - a function that determines if a pointer value is a valid 'errno' value - so one of strndup_user(), lookup_user_key(), or key_create_or_update() failed.

> [*] Leak in process[-] add_key: Disk quota exceeded

I'm taking an educated guess, try:

    sysctl user.max_user_namespaces

I'm guessing it's "0", which means user namespaces are disabled on your system. This would be an effective mitigation against most of these namespace exploits. If you type "unshare -rT" you'll likely get a "No space left on device" or something instead of a faux-root namespace shell.

No; I use namespaces extensively.

  user.max_user_namespaces = 127864

To my very humble reading you need local system (non-root) access first. So no exploitation over the networking interface themselves.

Disclaimer: Not a hacker, not an Linux pro.

That's my understanding as well.

Yes, I think it's more of a toolkit hack. Given you have many of such hacks, find a way to combine them to make actual use of it.

Most exploited vulnerabilites are a combination - you get a local exploit in wordpress which allows you to run a bash script as the webserver user, but gives you limited control over the machine itself

You then exploit a local privilige escalation vulnerability which gives you full access to the machine, allowing you to install backdoors etc for future access

This used to be half of the two-step about every security hole: (1) this hole can only get you root running as an already authenticated user, or (2) this hole only gets an attacker restricted user-level permissions. Thankfully we don't see this so much lately.

This post illustrates the large amount of extra work still needed to counter the depressingly common "this only corrupts unused memory, so it can't be exploited".

But if you can exploit a script or processes that is network accessible to exec your own code, then you get "local system" access, no?

Wow! If I understand correctly this is a local privilege escalation (the blog post doesn't mention "local" or "remote"). But it seems it could also be used to get remote code execution?

I wish there was a list of distribution kernels that are vulnerable and which have already patched this. Would be valuable to add to the blog post and the GitHub repo. https://github.com/randorisec/CVE-2022-34918-LPE-PoC

Yup, it is essentially exploiting the subsystem firewalls like iptables use under the hood, you can't mess with that remotely.

That looks like nftables (the successor to iptables).

"...you can't mess with that remotely."

I don't know enough about the subject to agree or disagree with this statement but you've got me curious. Is that a:

A. "It's fundamentally impossible to make this change because operating systems cannot be modified in this way by a remote system" (i.e. making a change at this level of the architecture would result in the remote connection being dropped and all of the attackers work becomes moot.)

B. "The code has been reviewed and hardened sufficiently that experts are universally assured that attempting this type of remote change will fail."

...or am I looking at this the wrong way and it's secure for a completely different reason? I've always been taught to be skeptical of any statement of perceived certainty when it involves computer security so I appreciate additional details so I can expand my knowledge.

Thank you in advance!

API used in the PoC is not used during parsing of the traffic. In order to trigger the bug remotely you'd either need to chain it with another exploit or have a way of running arbitrary commands as a local user (e.g. by exploiting webapp).

You can look at the code to see to what great lengths it goes to exploit this.

I looked at the code within the original article, and while I could follow the general flow and function, that's about it.

Thus my question about the OP's (seemingly) confident statement and why they were comfortable making it.

It requires access to netlink socket. These are not remotely accessible.

I think you are looking at it wrong way. A remote exploit is one where the exploit makes use of a vuln over network. The bug/vuln is exposed in either the networking or applications accessible over the net. In this case, you need to use a remote exploit to get local access and then use this to elevate the local access to root access. You can still do it through a remote system, but not without the intermediate step.

My understanding is you need CAP_NET_ADMIN first right? Which is enabled by default for an interactive user on Ubuntu. But is it enabled for say www-data? If I pop a shell on wordpress for example, I would need to compromise another account with that capability right? Or is CAP_NET_ADMIN enabled for non-interactive system users or not required for this LPE?

Looking at the exploit code [1], sadly, you don't...

They're using the fact that you can become "root" in a new namespace. So you need cgroups. After that, you're free to change NFTables in that namespace. I was just playing around with this:

    $ unshare -r --net --user capsh --print

and comparing it to

    $ sudo capsh --print

Both give you all caps. Exploiting a parser bug in NFTables doesn't require access to the main namespace; just something to get past the initial cap checks.

(IIUC.)

Edit: the commands above were run on Ubuntu 21.10.

[1] https://github.com/randorisec/CVE-2022-34918-LPE-PoC/blob/ma...

I didn't even think if namespaces! Thanks for clarifying.

It's worth noting that it is possible to disable unprivileged user namespaces, but the default on several modern linux distros is to have it enabled.

It's indeed a pretty cool combination of ideas to get to the final exploit. I just had a discussion about whether programming is mostly creative or analytical. Seeing this post, the answer (next time) will be "yes."

I an sort of learning how to bypass ASLR right now, it is a very timely PoC for me.

Here's what my colleagues think about unpriviledged namespaces:

https://blog.cloudflare.com/live-patch-security-vulnerabilit...

> They're using the fact that you can become "root" in a new namespace

That privilege can actually be taken away. But probably no one will do that unless you are hardening against specific situation.

The linux caps has many level of access of a certain cap.

For example: is it activated now? can it be activated by me? Will that be inherited by my children process? Can i regain it by su or creating new namespace?

If you take away the last one. Then the process and any child process of specific process won't be able to regain the cap ever again.

See also: capabilities(7) > Capabilities and execution of programs by root

TL;DR: Local privileges escalation in iptables on Ubuntu 22.04 and RHEL 9.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3491...

https://access.redhat.com/security/cve/cve-2022-34918

Speaking about iptables - is there anything in the wild that allows users make request to web port and I can approve/deny particular requests?

For example, 443/TCP is blocked from world. However if someone opens web page, it returns <html><body>Access request from IP xxx.xxx.xxx.xxx has been submitted</body></html> (or maybe a form where you put port number you'd like to access) and from server-side I can somehow see those requests, useragents and accept/deny and just ignore bots.

Use-case: Some photoalbum is locked down, accessed by particular IPs/countries/vpn (to reduce or prevent bruteforcing, automated hacking and such) - however I'd like to give access to someone (who doesn't know his IP) by just giving him a domain name. https://photos.example.com - yeah, he sees that unfriendly page. After a while I call him and say - try again and poof, next time he opens the page, he penetrates the firewall and gets pictures.

The thing is:

- VPN is too much of an ask to a person I want to send a link to some data

- Country block is very rough filter, just helps to reduce some log traffic from uninteresting countries with loads of bots.

- Asking person his IP is very manual: "please open/google up such phrase, send me that address and I'll look up my notes to copy/paste that iptables command and I'll modify it slightly (or add some config entry to .htaccess) to put your IP in and then you'll have access until you reconnect to your mobile network or your ISP gives you new DHCP address and then we'll repeat"

"Knockwall" doesn't return much results, eh.

You'd be running a webserver on your firewall.

If you want that, just run the webserver and base the response on IP address (have your 401 forbidden page say "forbidden", and allow from 1.2.3.4). Or do a username/password, or do something like openauth to integrate with an identity provider

Managing IPs manually is same amount of work as managing iptables - see updated question.

Yeah, integrating identity providers could work, knowing recipient email addresses and that they use particular services. However that has some complexity/libraries and as with that - vulnerabilities all over again. I just don't want to think/expose attack surface and give possibilities for automated attacks to leak personal data.

Or lets say it like that - I trust iptables more than myself integrating identity provider or depending on some library.

Actually this is what onedrive/photo galleries etc. does when you share files/folders - generates some magic link that penetrates auth. However it's the same story - I trust complex system (that may have well known vulnerabilities and I was on a vacation) less than iptables.

Fine, just have your webserver give a 401 to everyone other than the IP address you want to access. If you really want port knocking to get in then have your server listn on port 52485 or whatever and add the IP to the allowed list.

I would rather the server doing any processing of the packets be running as a low privilege user than sitting in the kernel.

How would you distinguish his/her IP from the list?

Country/time/user agent pair won't leave too much ambiguity. I'm talking about persons I know where they live.

TLS client certificates?

Yeah, try setting up TLS client cert remotely for your grandma and few people... manual iptables is easyer, then :)

It's just one click and hopefully a password away. I use "personal CAs" everywhere, if you share the p12 file via a webserver it's installed by the browser when you click on the link, and share the password over phone or another medium.

I'm a big fan of them, sadly there are a few issues, other than certificate management - safari doesn't handle them well at all in my experience for example

Block 8443 on public interface. DNAT your whitelisted IPs to 127.0.0.1:8443 where you're hosting your real page. Put another page on 443 that serves your access request and notifies you.

But honestly you should just do the access list in nginx itself.

Generate random key, put it into URL, and have some reverse proxy check it against a list to allow the IP on first access.

This isn't what you're asking, but you could just implement Single Sign-On through a social network (Google, Facebook, Twitter).

Iptables: How to allow only one ip through specific port?

https://serverfault.com/questions/146569/iptables-how-to-all...

Found that by Googling [iptables whitelist by IP and port]. ___

Another approach is Port Knocking:

https://en.m.wikipedia.org/wiki/Port_knocking

That said, likely more complex than the solution you’re looking for; also worth mentioning that unless you use the variant called single packet authorization (SPA), where only a single "knock" is needed, consisting of an encrypted packet — the port knocking sequence in theory is observable and reproducible by an attacker.

You got it a little mixed up. If the web port rejects connections there is no way you cand serve a web page to them, they cannot get to the web server.

Th term that you shoud be searching is "port knocking" though I don't know how easy is to do from a mobile phone, it's not exactly a nice user experience. And then you have to decide how long to keep an IP whitelisted and other inconveniences.

In the end there's real reasons everybody relies on web auth.

This is so jank. Why not just text them a password and use HTTP basic auth. It’s built-in on most webservers like nginx.

Why are we putting generic pictures behind auth?

I get paranoia, but come on. I'd rather open it, and monitor for strange activity/fail2ban to automate banning malicious actors.

Don't overthink it. We're sharing pictures, not government secrets.

You introduced 'generic', as far as I can tell? Maybe they're personal, family, including children, etc. all sorts of things perfectly reasonable not to want 'on the internet' but to share with somebody else specific (by using the internet, sure).

Guess they should use a service like google photos to share them with individuals. Nobody is whitelisting dynamic IP addresses thinking it's secure.

... Or, they could use a private server with http simple auth, and be perfectly secure without having to give all their personal photos to Google

Right? There are a lot of very complex suggestions for this simple problem.

To simplify even more, based on the use case, it would probably be fine to just share an inline user:pass@site.com link. That would avoid even needing the user to fill a basic auth form.

If you're using a web server like Apache, that functionality is probably built in. Otherwise, you probably want something like Nginx or HAProxy. You can configure rules based on IP and use the logs to check the person's IP.

That said IP addresses are generally not static so you would probably be much better off just configuring HTTP basic authentication and giving the password to people to whom you want to grant access. Here's an example if you were to use Nginx as a reverse proxy: https://medium.com/pernod-ricard-tech/adding-basic-authentic...

not what you want at all, but it came to mind. openbsd has it's authpf system, where you ssh in, and the system installs firewall rules.

http://man.openbsd.org/authpf

Something similar probably exists for linux as well.

Some days what I really want is shttp, http over ssh.

I can't think of anything in the wild. You could get far with setting up some webhooks and sending events to IFTTT.

Having it self hosted, in the end its a matter of logging some information about users requesting access in to a database, having a UI to display data from said database and having some small automation to add the IP to a whitelist / blacklist.

Port knocking maybe?

https://en.m.wikipedia.org/wiki/Port_knocking

Why not use presigned single use URLs? Makes more sense because you're sending an URL anyways

Try looking up "port knocking", something like this might be a start:

https://blog.odoom.net/port-knocking-http/

> This vulnerability could be exploited to get a privilege escalation on Ubuntu 22.04.

Nothing else is vulnerable?

As this was a linux kernal subsystem "netfilter subsystem of the Linux kernel" then I would presume not, and any kernel with the impacted subsystem present and equally exposed would be equally at risk.

A bit like finding a flaw in a steering wheel used in a particular model of car when other car makes use that same steering wheel, yet were not tested in the findings.

At least that is my interpretation of all this.

The commit references this in the "Fixes" tag: https://github.com/torvalds/linux/commit/7d7402642eaf385aef0...

That's a commit from 2015

> A bit like finding a flaw in a steering wheel used in a particular model of car when other car makes use that same steering wheel, yet were not tested in the findings.

I kinda hoped you've reference airbags instead (https://en.wikipedia.org/wiki/Takata_Corporation#Defective_a...)

RHEL 9 (and likely many other distros with same kernel version) is vulnerable as well: https://access.redhat.com/security/cve/cve-2022-34918#cve-fa...

This is stated to make independent verification of the exploit easier. It might or might not work on other systems, but security researchers and maintainers should waste as little time as possible to reproduce it!

Will the fix only be available in kernel 5.19?

These generally get backported when needed, check your distribution's kernel updates and the stable / longterm kernel.org trains. Here's eg the fix in the 5.18.12 tree: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...

Thanks!

A rustOS can't come soon enough!

Reply on news.ycombinator.com