Release notes for IRRd 4.2.3

IRRd 4.2.3 was released on March 31st, 2022, and fixes a security issue with password hash filtering that occurred in all earlier 4.2 releases. The 4.1.x series is not affected.

Previous IRRd 4.2 versions did not always filter password hashes in mntner objects. This may have allowed adversaries to retrieve some of these hashes, perform a brute-force search for the clear-text passphrase, and use these to make unauthorised changes to affected IRR objects.

This issue only affected instances that process password hashes, which means it is limited to IRRd instances that serve authoritative databases. IRRd instances operating solely as mirrors of other IRR databases are not affected.

Details

In the IRR, authentication for object modification can be done through passwords. Hashes are stored in mntner objects for this purpose. IRRd should filter these hashes from the output before returning results, and replace them with dummy values.

Earlier versions of IRRd 4.2 did not fully filter password hashes when returning some mntner objects in responses to some queries and when creating database exports. This meant that these password hashes could be exposed to anyone with the ability queries or access to the exports. Hash removal was missing in two specific cases, detailed below.

Typically this issue only affects instances that serve authoritative databases, as mirrors already generally do not have password hashes of their mirrored databases.

This issue was initially revealed by a community member in a discussion in the IRRd repository on March 23rd.

Objects where all hash names are lower or mixed case

IRRd 4.2 would not remove the password hashes if all hash names (MD5-PW and/or CRYPT-PW) in a specific object were lower or mixed case. This affected all cases where hashes were part of the response to any query using any method, and exports made with the export_destination setting.

For example, in this object, hash removal would work correctly:

mntner:         TEST-MNT
auth:           CRYPT-PW <hash>
auth:           md5-pw <hash>
source:         TEST

In this object, no hashes would be removed:

mntner:         TEST-MNT
auth:           CRYPT-Pw <hash>
auth:           md5-pw <hash>
source:         TEST

In public well known IRR databases, this is a highly exceptional case, as virtually all mntner objects use hash names entirely in uppercase. To check whether any hashes may have been exposed, you could search your mntner objects for any that contain only lower or mixed case hash names.

This was caused by a performance improvement introduced in November 2020 and included in all 4.2 versions.

GrapQL queries for the auth attribute or journal entries

GraphQL queries can query for specific attributes. Queries for the auth attribute on a mntner, which contains the hashes, were not correctly passed through the password hash removal. The full hash was included in responses to these queries.

The GraphQL interface also allows retrieving journal entries, including historical object texts through the objectText field in a journal. This field was missing password hash removal. Queries for the journal were only allowed where the nrtm_access_list setting permitted them.

Both of these only apply when the GraphQL interface was exposed. If you had this enabled, you can search your logs have any GraphQL queries for the auth field, or the objectText field in a journal to determine whether any hashes may have been exposed.

Long term improvements

While these particular issues are resolved, the root cause is the mixing of public IRR objects with private authentication data. This has a long history in the IRR. In the long term, IRRd will be able to separate this data, reducing the risks of similar issues.

The severity is increased due to IRRd still supporting CRYPT-PW and MD5-PW for password hashes. The next release of IRRd will support newer hash methods and the option to disable older hashes.