Krill

Krill users restricted to one CA can make any other CA delegate its prefixes and publish ROAs for them via bulk import

The vulnerability gives a role that is restricted to a list of CAs (cas = [...]) its full permission set for every request that is not tied to a CA, including the bulk import endpoint POST /api/v1/bulk/cas/import. It adds a new child CA under any existing CA, gives the child any of that CA's resources, and creates the ROAs given in the request

Krill login-session tokens reuse their encryption nonce across restarts, so any user who can log in can forge an "admin" token

The vulnerability is that Krill encrypts every login-session token with a nonce built from a counter that is reset to 0 on every Krill restart, so the same (key, nonce) pair is used again after each restart.

Krill treats a "local parent" as already-authenticated, letting a CA operator act as any child of any CA on the same server

When a CA's parent lives on the same Krill server: instead of building and verifying a signed CMS message, it runs the RFC 6492 provisioning exchange in- process and trusts the child identity (child_handle) that the caller put in the parent contact. Nothing checks that this child identity actually belongs to the CA making the request.

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.