[HN Gopher] A Crack in the Linux Firewall
___________________________________________________________________
A Crack in the Linux Firewall
Author : emilburzo
Score : 230 points
Date : 2022-07-21 11:24 UTC (11 hours ago)
(HTM) web link (www.randorisec.fr)
(TXT) w3m dump (www.randorisec.fr)
| claudiojulio wrote:
| Will the fix only be available in kernel 5.19?
| fulafel wrote:
| 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...
| claudiojulio wrote:
| Thanks!
| iam-TJ wrote:
| 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.
| franzIncarnate wrote:
| > [*] 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.
| iam-TJ wrote:
| No; I use namespaces extensively.
| user.max_user_namespaces = 127864
| nuker wrote:
| > This vulnerability could be exploited to get a privilege
| escalation on Ubuntu 22.04.
|
| Nothing else is vulnerable?
| Zenst wrote:
| 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.
| megous wrote:
| The commit references this in the "Fixes" tag: https://github
| .com/torvalds/linux/commit/7d7402642eaf385aef0...
|
| That's a commit from 2015
| zinekeller wrote:
| > 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.wi
| kipedia.org/wiki/Takata_Corporation#Defective_a...)
| execveat wrote:
| 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...
| samus wrote:
| 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!
| badrabbit wrote:
| 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?
| [deleted]
| tommiegannert wrote:
| 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...
| badrabbit wrote:
| I didn't even think if namespaces! Thanks for clarifying.
| tommiegannert wrote:
| 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."
| badrabbit wrote:
| I an sort of learning how to bypass ASLR right now, it is
| a very timely PoC for me.
| raesene9 wrote:
| 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.
| mmis1000 wrote:
| > 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
| majke wrote:
| Here's what my colleagues think about unpriviledged
| namespaces:
|
| https://blog.cloudflare.com/live-patch-security-
| vulnerabilit...
| sharmin123 wrote:
| oaiey wrote:
| 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.
| badrabbit wrote:
| That's my understanding as well.
| ncmncm wrote:
| 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".
| hutrdvnj wrote:
| 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.
| iso1631 wrote:
| 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
| 752963e64 wrote:
| aorth wrote:
| 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
| badrabbit wrote:
| Yup, it is essentially exploiting the subsystem firewalls like
| iptables use under the hood, you can't mess with that remotely.
| Mtinie wrote:
| "...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!
| vaidhy wrote:
| 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.
| execveat wrote:
| 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).
| megous wrote:
| You can look at the code to see to what great lengths it
| goes to exploit this.
| Mtinie wrote:
| 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.
| megous wrote:
| It requires access to netlink socket. These are not
| remotely accessible.
| _wldu wrote:
| That looks like nftables (the successor to iptables).
| anewpersonality wrote:
| A rustOS can't come soon enough!
| anewpersonality wrote:
| A rustOS can't come soon enough!
| jve wrote:
| 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.
| somat wrote:
| 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.
| iso1631 wrote:
| 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
| jve wrote:
| 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.
| iso1631 wrote:
| 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.
| tuxie_ wrote:
| How would you distinguish his/her IP from the list?
| jve wrote:
| Country/time/user agent pair won't leave too much ambiguity.
| I'm talking about persons I know where they live.
| zaik wrote:
| TLS client certificates?
| jve wrote:
| Yeah, try setting up TLS client cert remotely for your
| grandma and few people... manual iptables is easyer, then :)
| jrms wrote:
| 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.
| iso1631 wrote:
| 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
| nullify88 wrote:
| 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.
| grayfaced wrote:
| 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.
| megous wrote:
| Generate random key, put it into URL, and have some reverse
| proxy check it against a list to allow the IP on first access.
| execveat wrote:
| This isn't what you're asking, but you could just implement
| Single Sign-On through a social network (Google, Facebook,
| Twitter).
| O__________O wrote:
| 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.
| trabant00 wrote:
| 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.
| neapolisbeach wrote:
| Port knocking maybe?
|
| https://en.m.wikipedia.org/wiki/Port_knocking
| NavinF wrote:
| 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.
| hatware wrote:
| 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.
| OJFord wrote:
| _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).
| hatware wrote:
| Guess they should use a service like google photos to
| share them with individuals. Nobody is whitelisting
| dynamic IP addresses thinking it's secure.
| yjftsjthsd-h wrote:
| ... 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
| czx4f4bd wrote:
| 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...
| sofixa wrote:
| Why not use presigned single use URLs? Makes more sense because
| you're sending an URL anyways
| brk wrote:
| Try looking up "port knocking", something like this might be a
| start:
|
| https://blog.odoom.net/port-knocking-http/
| linsomniac wrote:
| 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
___________________________________________________________________
(page generated 2022-07-21 23:01 UTC)