Missing files don't result in a manifest being considered invalid #158
Comments
|
To offer an example: In manifest If an attacker withholds all but and the validator does not consider If the manifest (which references a missing
But until we have more information about other attack vectors, I recommend that a manifest as a whole is considered invalid, when it references a non-existing or wrongly checksummed file. The onus is on the CA publication points to publish correct valid RPKI data, the validator's can't be expected to compensate for CA operator errors (or MITM attacks) |
|
An additional check is needed: if one of the .roa files a manifest references is corrupt (the MITM didn't delete strategically file, but filled some .roa files with garbage), the fix no longer works: corrupting that one .roa file results in an incomplete (operationally problematic) set of VRPs: In the above eaxmple there should be ~ 19 VRPs in total, In summary: If a manifests references a non-existing file, or if there is a checksum mismatch between the hash described in the manifest and the hash as derived from the .roa file, the RP MUST consider the whole manifest invalid and not produce VRPs with the remaining .roa files. |
|
Hi Job, I think it would be much more valuable if you bring these examples back to sidrops@ and we continue discussion there, rather then in this bug report. |
|
@omuravskiy This discussion takes place at multiple levels: I am a user of the RIPE NCC RPKI Cache Validator software, and I am reporting a security issue to my vendor (RIPE NCC) via the usual channel (github issues). Another angle of this discussion is whether the specifications could've been worded differently or improved. To me those discussions are orthogonal. While it is worthwhile to discuss ambiguities of the RFC specifications in the sidrops working group, you as vendor don't need the blessing of the SIDROPS working group whether to publish security patches for the users of your software or not. A result of discussion in sidrops could be "according to the specifications this is perfectly valid", and at the same time a vendor may still choose to implement stricter validation to better protect the users of the software, because even if the input data is valid (for some value of valid), the end result could be a security vulnerability (such as described in this github issue). |
|
I think at this stage it is better to contain the discussion to smaller number of different places. |
Stephen Kent tells us that discussing Monkey-In-The-Middle attacks is a 'distraction'. This makes productive discussion in sidrops slightly harder. I believe this is a security issue that needs to be addressed urgently. |
|
I do not believe missing files listed in a Manifest should invalidate other content validly detected in the system. I do not believe this change should be implemented, and I would like to see further discussion in SIDROPS and amongst validator authors and RPs |
In light of transparency, who are you? Why do you believe listed missing files should not invalidate content at the same level? You offer no motivation and do not provide an alternative solution to mitigate the negative impact of the outlined Money-in-the-middle attack. |
|
I am George Michaelson. I operate a repository, and you are changing the
basis of validation rules regarding my state. Therefore, I am concerned
this is happening as bugfix and not (for transparency reasons) in a
standards forum,
…On Wed, Apr 1, 2020 at 5:31 AM Job Snijders ***@***.***> wrote:
I do not believe missing files listed in a Manifest should invalidate
other content validly detected in the system. I do not believe this change
should be implemented, and I would like to see further discussion in
SIDROPS and amongst validator authors and RPs
In light of transparency, who are you?
Why do you believe listed missing files should not invalidate content at
the same level? You offer no motivation and do not provide an alternative
solution to mitigate the negative impact of the outlined
Money-in-the-middle attack.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#158 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABORQ7CH3NXZWQ2GFKRHG53RKJAJ3ANCNFSM4LSBQAKQ>
.
|
thanks for clarifying! |
|
Addressed by introducing 'strict mode' in |
In a MITM scenario where an attacker intercepts and manipulates the rsync channel (for example strategically withholding certain .roa files from the view of the validator being attacked), the resulting set of VRPs will be incomplete and can cause severe operational issues.
When a manifest is valid (manifest is parsable, CRL exists is valid (also not expired), and manifest is signed with keys not revoked by the CRL), and references files which do not exist in the repository at hand, the publication point should be considered compromised.
So in the case of APNIC where an End User (self-hosted) RPKI publication point misses a few .roa files, the validator can proceed to consider all data from all RPs it could reach eligeble for further validation, except any data from the publication point where files were missing.
In other words: if one or a few files are missing from the repository, the repository should be considered 'down', and no attempt should be made to start guessing what can be salvaged and what not.
The text was updated successfully, but these errors were encountered: