CVE-2022-2663 defence-in-depth: Specify CTCP PING character limits

[dgl]

I've just released https://dgl.cx/2022/08/nat-again-irc-cve-2022-2663 which affects the Linux kernel. As that document describes there are several mitigations and the best of all is using TLS for IRC, which many IRCv3 standards already encourage 👍 .

I have put a recommendation for client authors that they should consider dropping "^A" within PING responses. I'm opening this issue to potentially consider writing that into a standard; although the primary way to address this is fixing the kernel it is possible there could be future "reflection" style attacks. I don't see any downside to limiting PING's payload to non-control characters as a defence-in-depth measure.

There is also a further attack that I have not explored but may be of interest to some client authors, as I don't believe it is standardised in any way, that is the behaviour of CTCP PING within established DCC CHAT sessions. If a user is tricked into establishing a DCC CHAT with a peer on port 6667, then the NAT helper may treat it like an IRC connection and it may be possible to attack them via that, even if they are using encrypted IRC. I am less concerned by that as it needs user interaction to establish the chat session.

(I don't believe IRCv3 has really considered DCC, one interesting point is many clients implement DCC, but don't necessarily implement encryption for it, so it might be interesting to consider specifying a warning when establishing a plaintext DCC session if the connection to the IRC server itself is encrypted.)

[dgl]

Note I disclosed this in advance to libera.chat and they have implemented network side filtering, so it's worth mentioning it is possible to filter this at the server side too.

[slingamn]

Very cool result, thanks :-)

I have put a recommendation for client authors that they should consider dropping "^A" within PING responses.

What octet(s) is this?

[grawity]

lol it's the linksys bug all over again

I have put a recommendation for client authors that they should consider dropping "^A" within PING responses.

What octet(s) is this?

It's the same 0x01 that begins/terminates a CTCP message, except apparently in this case it shows up in the middle of a response (where Linux mistakenly picks it up as the beginning of a real "DCC" CTCP).

(So you have to be careful to not over-filter it as the 1st or last octet of a message, because that'd break CTCP in general.)

(I don't believe IRCv3 has really considered DCC, one interesting point is many clients implement DCC, but don't necessarily implement encryption for it, so it might be interesting to consider specifying a warning when establishing a plaintext DCC session if the connection to the IRC server itself is encrypted.)

So why is TLS not a thing for DCC yet? Several other systems are successfully using TLS-PSK to bootstrap a new (D)TLS connection without needing certificates on either side – but just generating a cert on the fly and including its fingerprint in the CTCP request would probably work as well (there are again systems which do that, I believe I've seen it in WebRTC).

I mean, client-side warnings are mostly outside of what IRCv3 does, but specifying a new DCC-TLS protocol would work.

[SadieCat]

This is probably more appropriate for Modern IRC's draft CTCP RFC than IRCv3. That said, we should really be pushing to obsolete plaintext IRC. There's just no reason to not use TLS in 2022.

In InspIRCd v4 I have made it mandatory to build with at least one TLS module and TLS will be required to link non-local servers. I'm also considering making it so TLS is required by default for logging into a server operator account. I'd recommend that other server devs do something similar.

Client developers can also move towards TLS as the default by making it so connecting with TLS is the default behaviour (i.e. require -insecure for plaintext instead of -ssl for TLS).