Security holes in the Linux kernel

Summary

With grsecurity 2.1.0 in January 2005, Brad Spengler pointed out four local holes in the Linux kernel, and Paul Starzetz reported another in the binary loader. All of them allowed local users to escalate their privileges up to root. Spengler criticised that the holes were still open three weeks after being reported to Torvalds and Morton, despite patches being attached.

Ideas

• Supplied patches did not automatically speed up the fix.
• Local privilege escalation remains critical on multi-user systems.
• External security projects such as grsecurity and PaX find holes in the main kernel.

Insights

• A process for security reports is as important as the fix itself.
• Tensions between security researchers and kernel developers shaped kernel security for years.

Facts

• According to Spengler, Torvalds was informed Torvalds on 15 December 2004.
• The PaX team reported a further hole on 27 December 2004.
• According to Spengler, a small analysis found four more holes in 15 minutes.

References

• g: Security holes in the Linux kernel (German)

Critique

• The report reflects Spengler’s view; a statement from Torvalds or Morton is missing.

Remarks

• The kernel later introduced security@kernel.org as a fixed reporting channel for security holes.

Recommendations

• Report kernel holes via security@kernel.org rather than to individual developers.
• Set up a documented, confidential reporting channel for your own projects.

Read the original article →

Search the Web Archive

Links to the original source and the Web Archive open in a new tab.