Report picks holes in the Linux kernel release signing process

June 24, 2021 TH Author

A report looking into the security of the Linux kernel’s release signing process has highlighted a range of areas for improvement, from failing to mandate the use of hardware security keys for authentication to use of static keys for SSH access.

The Linux kernel is at the heart of a wealth of modern technology, from embedded gadgets and network equipment all the way up to supercomputers. Its broad deployment makes it a tempting target for ne’er-do-wells, as was made all-too-obvious in 2011 when attackers gained root access to key servers used in its development and distribution.

In response to that breach, traced back to a Trojan installed on a developer’s personal machine which gave the attackers complete control over the affected servers for the 17 days before it was detected, a new release signing process was introduced. The idea: to minimise the trust placed in any given part of the Linux development infrastructure.

Earlier this year cybersecurity research and consulting firm Trail of Bits was commissioned by the Open Source Technology Improvement Fund (OSTIF) to analyse the process for vulnerabilities – and analyse it did, finding several key areas where improvement is recommended.

The report, however, is admittedly incomplete. “The documentation supplied to Trail of Bits was informative but outdated,” the researchers noted in the report’s introduction. “A current, comprehensive description of the process would make it easier to enforce compliance and identify any weaknesses.”

That, in turn, became one of the weaknesses identified in the report: “lack of documented key management policies and procedures.”

One of several low-severity issues noted in the findings, the report warns that a lack of “centralised, authoritative documentation laying out policies and procedures for key revocation, generation, or rotation or other key management tasks” means that “users and administrators are more likely to make serious errors.”

The most severe issue noted, though only rated as a medium on a scale from informational at the bottom to high at the top, was that developers who are able to commit code directly to the Linux kernel repositories were not mandated to use hardware security keys – making any breach of their personal systems, as in the 2011 attack, considerably more serious.

“Alice is a Linux kernel maintainer who stores private key material on a user-accessible block device,” the report explained as an example of how the issue could be exploited. “Eve, an attacker, is able to install malware on Alice’s workstation.

Developers who are able to commit code directly to the Linux kernel repositories were not mandated to use hardware security keys – making any breach of their personal systems, as in the 2011 attack, considerably more serious

“Eve is able to exfiltrate private key material from Alice’s workstation and could attempt to brute-force passphrases or to install a keylogger to record passphrase entry. Eve could then create valid signatures and authenticate to some kernel.org services using the stolen key material.”

Even those who have adopted hardware security devices may not be fully protected, however. “The Linux Foundation recommends that kernel developers use smart cards, specifically Nitrokeys, to secure their private key material,” the report found. “Linux Foundation-issued Nitrokeys do not require users to perform any physical actions when using smart card functions.

“Other devices can be configured to require the user to touch the device before the smart card operations occur. As a result, the Nitrokey is protected only by a passphrase while inserted into a workstation.”

Recommendations made in the report include: updating and improving the documentation; mandating the use of smart cards which require physical interaction in order to validate each operation; the development and release of tooling for comparing kernel releases with the content of a tagged GitHub release as a means of checking for unauthorised changes; and adding a means of enforcing expected-identity signatures on commits to key repositories.

Another key recommendation: switching out the currently static keys used to grant SSH access to kernel.org servers with finite-lifespan versions, as part of a formal key rotation schedule. “Because SSH keys can often be leveraged to access additional systems,” the report warned, “they are frequently targeted by attackers. Under the current setup, recovery of a single developer’s SSH key could allow indefinite access to kernel.org resources.”

Infosec specialist Sean Wright said, “It’s fantastic to see that this audit was carried out. This helps to show maturity on the behalf of The Linux Foundation,” he told us. “It’s rare that an organisation will get a clean bill of health, i.e. no findings during an audit).

“The power that some individuals have, in terms of the impact of the changes which they carry out, certainly make them lucrative targets for potential criminals. The proposed recommendation align to this, and help significantly raise the complexity which an attacker would have to go through in order to be able to get this level of access. But, having said this, even today the level of complexity is pretty high and it would likely still require a very well resourced criminal group or nation state group to be able to carry out a successful attack.”

Wright added: “In light of the SolarWinds incident, we’ve seen the potential dangers of an attacker having access to modify code and software. If an attacker were able to gain this level of access to certain individual accounts on the Linux Foundation team, it would likely make SolarWinds look like a walk in the park. As with SolarWinds we also learnt not only does the code, and changes to that code, need protecting; the build process and systems need as much scrutiny.”

Full details of the report’s findings are available on the OSTIF website. ®