Report picks holes in the Linux kernel release signing process
- Reference: 1624552085
- News link: https://www.theregister.co.uk/2021/06/24/report_picks_holes_in_the/
- Source link:
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 [1]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.
[2]
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.
[3]
[4]
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."
[5]
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.
[6]
"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).
[7]SEC still digging into SolarWinds fallout, nudges undeclared victims
[8]Google pushes bug databases to get on the same page for open-source security
[9]The Linux Foundation dives into machine learning with Open Voice Network, dataset licence launches
[10]Boffins promise protection and perfect performance with new ZeRØ, No-FAT memory safety techniques
“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 [11]OSTIF website . ®
Get our [12]Tech Resources
[1] https://www.theregister.com/2011/08/31/linux_kernel_security_breach/
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YNUAe2Fnq@FaPBkS8FTbqgAAAAE&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YNUAe2Fnq@FaPBkS8FTbqgAAAAE&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YNUAe2Fnq@FaPBkS8FTbqgAAAAE&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YNUAe2Fnq@FaPBkS8FTbqgAAAAE&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YNUAe2Fnq@FaPBkS8FTbqgAAAAE&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[7] https://www.theregister.com/2021/06/22/sec_continues_to_probe_solarwinds/
[8] https://www.theregister.com/2021/06/24/google_security_fix/
[9] https://www.theregister.com/2021/06/23/linux_foundation_machine_learning_voice/
[10] https://www.theregister.com/2021/06/23/zero_no_fat_memory_safety/
[11] https://ostif.org/a-review-of-the-linux-kernels-release-signing-and-key-management-policies/
[12] https://whitepapers.theregister.com/
I assume the recommendation to change SSH keys is due to the possibility of brute force attacks if a weakness in DSA (or whatever type of key is being used) is found that reduces its effectively length.
Seems a bit silly though, even if a weakness was found that would allow cracking someone's DSA you'd invest a ton of time and money in the cracking. There are a lot of options if you are willing to invest that much, including the simpler (but more risky as far as jail) breaking into their house and threatening them with a $5 wrench.
Threatening with a $5 wrench is effective in the short term but will be reported within minutes to weeks, at which point the team will take countermeasures.
That's not what most people who are interested in hacking the Linux kernel are after. They want to be an advanced, persistent threat.
Threatening with a $5 wrench is effective in the short term but will be reported within minutes to weeks
Depends on whether there is a credible threat of returning, or visiting their daughter's school. The people using $5 wrenches are going to be prepared for the possibility the victim might consider reporting it.
There are also a range of possibilities between $5 wrench and tens of millions of dollars worth of CPU time to crack an SSH key (which itself still relies finding a weakness in DSA or whatever first)
I mean, sure it is cheap and easy to replace SSH keys on a regular schedule, but that's so far above the low hanging fruit if that's really the biggest potential hole you have exposed you are more secure than anyone else on the planet.
Well done to the Linux Foundation
It's never much fun to invite independent auditors in who you know will publish their findings openly. The first time you do that, you *know* there's going to be stuff you hadn't seen hauled out into the open, and a certain amount of egg on face as a result.
Much kudos to the folks who chose this approach, and co-operated with it, despite the inevitable findings.
force majeure
I wonder what protection the Linux kernel master source has from interference by "higher powers" such as Tech Giants or authoritarian states?
Re: force majeure
At the moment, on top of multiple levels of code review, it has Linus telling them to get stuffed and not being afraid to do so at length. There's a reason people have been trying to compromise him for years.
Honest question. Why is SSH key rotation any better than, say, having to change passwords periodically? Cannot an intruder with one key leverage it to get the next one and keep going?
As for requiring physical interaction to smart cards, has consideration been made to the frequency by which these interactions would be necessary, to probe at the risk of click fatigue resulting in the development of bypasses?