rsync CVE-2022-29154 and RPKI Validation
Has anyone done an analysis of the rsync CVE-2022-29154 (which "allows malicious remote servers to write arbitrary files inside the directories of connecting peers") and its potential impact on RPKI validators? It looks like both Debian [1] and Ubuntu [2] opted *not* to patch rsync in their release/security package streams. Are rsync-based (or rsync-fallback, which I believe is still required for all RPKI validators?) RPKI validators all vulnerable to takeover from this, or is there some reason why this doesn't apply to RPKI validation? Thanks, Matt [1] https://security-tracker.debian.org/tracker/CVE-2022-29154 [2] https://ubuntu.com/security/CVE-2022-29154
On 2022-09-09 04:56, Matt Corallo wrote:
Has anyone done an analysis of the rsync CVE-2022-29154 (which "allows malicious remote servers to write arbitrary files inside the directories of connecting peers") and its potential impact on RPKI validators? It looks like both Debian [1] and Ubuntu [2] opted *not* to patch rsync in their release/security package streams.
Are rsync-based (or rsync-fallback, which I believe is still required for all RPKI validators?) RPKI validators all vulnerable to takeover from this, or is there some reason why this doesn't apply to RPKI validation?
The attacker is still limited to the target directory. The attacker can send files that were excluded or not requested, but they still end up in the target directory. RPKI validators download stuff in a dedicated download directory (but it may be shared with several peers), so they should be safe.
On 9/9/22 2:36 AM, Vincent Bernat wrote:
The attacker is still limited to the target directory. The attacker can send files that were excluded or not requested, but they still end up in the target directory. RPKI validators download stuff in a dedicated download directory
Ah, okay, thanks, its a shame that wasn't included in any of the disclosure posts I managed to find :(
(but it may be shared with several peers)
I assume I'm mis-reading this - RPKI servers aren't able to overwrite output from other RPKI servers, so it shouldn't be shared, no? Thanks, Matt
On 2022-09-09 19:36, Matt Corallo wrote:
The attacker is still limited to the target directory. The attacker can send files that were excluded or not requested, but they still end up in the target directory. RPKI validators download stuff in a dedicated download directory
Ah, okay, thanks, its a shame that wasn't included in any of the disclosure posts I managed to find :(
It's explained in the manual page: https://manpages.debian.org/unstable/rsync/rsync.1.en.html#MULTI-HOST_SECURI...
(but it may be shared with several peers)
I assume I'm mis-reading this - RPKI servers aren't able to overwrite output from other RPKI servers, so it shouldn't be shared, no?
Yes, it shouldn't, but maybe RPKI servers are still downloading all of them in a single directory. Looking at cfrpki, it looks like it works this way (didn't test).
On 9/9/22 1:58 PM, Vincent Bernat wrote:
On 2022-09-09 19:36, Matt Corallo wrote:
The attacker is still limited to the target directory. The attacker can send files that were excluded or not requested, but they still end up in the target directory. RPKI validators download stuff in a dedicated download directory
Ah, okay, thanks, its a shame that wasn't included in any of the disclosure posts I managed to find :(
It's explained in the manual page: https://manpages.debian.org/unstable/rsync/rsync.1.en.html#MULTI-HOST_SECURI...
Heh, right, so not in any of the disclosure posts :p
(but it may be shared with several peers)
I assume I'm mis-reading this - RPKI servers aren't able to overwrite output from other RPKI servers, so it shouldn't be shared, no?
Yes, it shouldn't, but maybe RPKI servers are still downloading all of them in a single directory. Looking at cfrpki, it looks like it works this way (didn't test).
Hmm, ouch, is there a corresponding security disclosure from cfrpki? I guess cfrpki sees pretty limited use these days. Thanks, Matt
On 9 Sep 2022, at 4:36 pm, Vincent Bernat <bernat@luffy.cx> wrote:
On 2022-09-09 04:56, Matt Corallo wrote:
Has anyone done an analysis of the rsync CVE-2022-29154 (which "allows malicious remote servers to write arbitrary files inside the directories of connecting peers") and its potential impact on RPKI validators? It looks like both Debian [1] and Ubuntu [2] opted *not* to patch rsync in their release/security package streams. Are rsync-based (or rsync-fallback, which I believe is still required for all RPKI validators?) RPKI validators all vulnerable to takeover from this, or is there some reason why this doesn't apply to RPKI validation?
The attacker is still limited to the target directory. The attacker can send files that were excluded or not requested, but they still end up in the target directory. RPKI validators download stuff in a dedicated download directory (but it may be shared with several peers), so they should be safe.
If the topic is whether rsync is fit for purpose for the RPKI I’d like to reference a still relevant presentation from IETF 89: https://www.ietf.org/proceedings/89/slides/slides-89-sidr-6.pdf As far as I am aware the issues raised in this presentation remain current. My takeaway from that presentation is that there is some simple advice about using rsync in the context of the RPKI cache sync operation: don’t. thanks, Geoff
participants (3)
-
Geoff Huston -
Matt Corallo -
Vincent Bernat