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.
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".
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
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.
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).
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.
> 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
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."
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"
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.
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).
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...
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.
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.
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.
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.
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.
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
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.
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.
> 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.
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!
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!
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.