ROUTING TOOLS

Routinator terminates when RTR connection is reset too quickly after opening

Due to a mistake in error checking, Routinator will terminate when an incoming RTR connection is reset by the peer too quickly after opening.

Since an attacker needs to be able to connect to Routinator’s RTR server, this issue only affects operators that provide a public RTR service.

Routinator 0.13.2 correctly handles this condition.

Crashes on parsing certain invalid RPKI objects

Due to insufficient checking of input data in the decoding library bcder used by Routinator, RPKI objects can be crafted that cause Routinator to crash. See CVE-2023-39914 for these issues.

Routinator 0.12.2 has been released that depends on a fixed version of the library.

Possible path traversal when storing RRDP responses

The keep-rrdp-responses feature introduced in Routinator 0.9.0 allows a user to store the content of responses received for RRDP requests. The location of these stored responses is constructed from the URL of the request. Due to insufficient sanitation of the URL, it is possible for an attacker to craft a URL that results in the response being stored outside of the directory specified for it.

Since the feature is disabled by default, this issue only affects users that have enabled the keep-rrdp-responses setting either in the config file or via the command line.

Routinator 0.12.2 properly vets the URI when creating a path and does not store the response if a proper path cannot be determined.

Triggered Krill crash on direct RRDP access

Krill can be used to operate an RPKI Publication Server. If used in this way, it is recommended that the RPKI repository "RRDP" (RFC 8182) content is served using a separate and dedicated web server. See documentation for Krill 0.12.0.

However, Krill also supports direct access to this repository content through its built-in web server at the "/rrdp" endpoint. It was discovered that a direct query for any existing directory under "/rrdp/", rather than an RRDP file such as "/rrdp/notification.xml" as would be expected, causes Krill to crash.

If the built-in "/rrdp" endpoint is exposed directly to the internet, then malicious remote parties can cause the publication server to crash. The repository content is not affected by this, but the availability of the server and repository can cause issues if this attack is persistent and is not mitigated.

The preferred solution is to follow the documented recommendation to use a separate web server for the RRDP content, and disable direct access to the "/rrdp" endpoint. This solution is (and was) preferred because dedicated web servers are much better suited to handle high load HTTP traffic compared to the built-in HTTP application server.

Krill 0.12.1 also ensures that direct queries to the "/rrdp" endpoint will no longer result in a crash.

Fatal error on incorrect base64 data in RRDP

Due to a mistake in error handling, data in RRDP snapshot and delta files that isn’t correctly base 64 encoded is treated as a fatal error and causes Routinator to exit.

Worst case impact of this vulnerability is denial of service for the RPKI data that Routinator provides to routers. This may stop your network from validating route origins based on RPKI data. This vulnerability does not allow an attacker to manipulate RPKI data. We are not aware of exploitation of this vulnerability at this point in time.

Routinator 0.11.3 handles encoding errors by rejecting the snapshot or delta file and continuing with validation. In case of an invalid delta file, it will try using the snapshot instead. If a snapshot file is invalid, the update of the repository will fail and an update through rsync is attempted.

Infinite length chain of RRDP repositories

Routinator prior to 0.10.2 happily processes a chain of RRDP repositories of infinite length causing it to never finish a validation run.

In RPKI, a CA can choose the RRDP repository it wishes to publish its data in. By continuously generating a new child CA that only consists of another CA using a different RRDP repository, a malicious CA can create a chain of CAs of de-facto infinite length. Routinator prior to version 0.10.2 did not contain a limit on the length of such a chain and will therefore continue to process this chain forever. As a result, the validation run will never finish, leading to Routinator continuing to serve the old data set or, if in the initial validation run directly after starting, never serve any data at all.

Routinator 0.10.2 limits the maximum distance a CA may have from a trust anchor certificate via the new max-ca-depth config variable which defaults to 32 and thereby implicitly limits the length of the repository chain.

Hanging RRDP request

In Routinator prior to 0.10.2, a validation run can be delayed significantly by an RRDP repository by not answering but slowly drip-feeding bytes to keep the connection alive. This can be used to effectively stall validation.

While Routinator has a configurable time-out value for RRDP connections, this time-out was only applied to individual read or write operations rather than the complete request. Thus, if an RRDP repository sends a little bit of data before that time-out expired, it can continuously extend the time it takes for the request to finish. Since validation will only continue once the update of an RRDP repository has concluded, this delay will cause validation to stall, leading to Routinator continuing to serve the old data set or, if in the initial validation run directly after starting, never serve any data at all.

Routinator 0.10.2 applies the existing rrdp-timeout configuration option to a full RRDP request.

gzip transfer encoding caused out-of-memory crash

Routinator versions 0.9.0 up to and including 0.10.1, support the gzip transfer encoding when querying RRDP repositories. This encoding can be used by an RRDP repository to cause an out-of-memory crash in these versions of Routinator.

RRDP uses XML which allows arbitrary amounts of white space in the encoded data. The gzip scheme compresses such white space extremely well, leading to very small compressed files that become huge when being decompressed for further processing, big enough that Routinator runs out of memory when parsing input data waiting for the next XML element.

Routinator 0.10.2 disables support for the gzip transfer encoding.

While it would have been possible to fix the out-of-memory condition, the large amount of data still needs to be handled, leading to a severe delay in validation runs. We have therefore decided to disable the gzip encoding completely.

Invalid RPKI data could disable Route Origin Validation on RTR clients

Routinator prior to 0.10.0 produces invalid RTR payload if an RPKI CA uses too large values in the max-length parameter in a ROA. This will lead to RTR clients such as routers to reject the RPKI data set, effectively disabling Route Origin Validation.

Due to lack of checking of ROA object content, Routinator will simply pass through any max-length value provided in the ROA. However, a max-length value must never be larger than the maximum prefix length of the address family. Data with larger values will be considered invalid by any RTR client leading to a rejection of the entire data set.

Routinator 0.10.0 ensures that any ROA objects containing max-length values larger than the maximum prefix length of a prefix’ address family are rejected.

Missing files should result in entire CA being considered invalid

An issue was discovered in NLnet Labs Routinator 0.1.0 through 0.7.1. It allows remote attackers to bypass intended access restrictions or to cause a denial of service on dependent routing systems by strategically withholding RPKI Route Origin Authorisation ".roa" files or X.509 Certificate Revocation List files from the RPKI relying party's view.

Routinator 0.8.0 follows the rules proposed by draft-ietf-sidrops-6486bis. It ensures that if any object published by a CA is found to be invalid, the entire CA – including all its objects – is rejected. This means that none of its ROAs are included nor are any of its child CAs even being looked at. This avoids a possible situation where a legitimate route is being marked as RPKI invalid because only a subset of the ROAs covering its prefix were considered valid and used.