Date: Thu, 1 Sep 2022 13:26:45 +1000 From: David Leadbeater <dgl@....cx> To: oss-security@...ts.openwall.com Subject: Re: CVE-2022-2663: Linux netfilter: nf_conntrack_irc message handling The exploit is an IRC client can be tricked into replying to a CTCP PING message with a crafted payload. The raw IRC command to do this is (sent by the attacker): PRIVMSG victim :^APING ^ADCC CHAT x [ip-as-numeric] [port]^A Which results in the victim's IRC client sending a PING response that is matched by nf_conntrack_irc as if the victim is establishing a DCC connection. In addition to this, there were some bugs in the handling of the IP address and port, rather than the client's IP address the code was matching on the IRC server's address and if a port of 0 was sent it would result in future packets being dropped. This means a remote (on the same IRC network) attacker can force a victim to either: open a port on its host, reveal its (public) IP address or perform a DoS by disconnecting from IRC. This code has been present in Linux since the addition of nf_conntrack_irc, around 16 years ago: https://github.com/torvalds/linux/commit/869f37d8 (this was very closely based on ip_conntrack_irc and from a quick look at the historical code that would have a similar issue). If IRC client authors are reading this, I've opened an issue for IRCv3 to consider a spec for blocking control characters in CTCP PING requests, as a defence-in-depth measure against this and potentially future attacks: https://github.com/ircv3/ircv3-specifications/issues/504 Hopefully it goes without saying to this audience, but using TLS for IRC connections fixes this entirely. I've posted a writeup with more background details here (including a video): https://dgl.cx/2022/08/nat-again-irc-cve-2022-2663 David On Tue, 30 Aug 2022 at 12:27, David Leadbeater <dgl@....cx> wrote: > > Description: > > I've found an issue in nf_conntrack_irc where the message handling can > be confused and it incorrectly matches on the message. > > Impact: > > A firewall may be able to be bypassed when users are using unencrypted > IRC with nf_conntrack_irc configured. > > Mitigations: > > Linux: Disable nf_conntrack_irc (remove any --helper irc rules, and/or > unload the kernel module) > MikroTik: Remove IRC from the service ports list (/ip > firewall/service-port/disable irc) > > Fix is posted here: > https://email@example.com/T/ > It will be making its way into upstream Linux soon. > > I'll update in a couple of days with complete details. > > David
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.