oss-sec mailing list archives

Re: CVE-2022-2663: Linux netfilter: nf_conntrack_irc message handling


From: David Leadbeater <dgl () dgl cx>
Date: Thu, 1 Sep 2022 13:26:45 +1000

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 () 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://lore.kernel.org/netfilter-devel/20220826045658.100360-1-dgl () dgl cx/T/
It will be making its way into upstream Linux soon.

I'll update in a couple of days with complete details.

David


Current thread: