PDA

View Full Version : Yet another kernel security hole


admin
01-12-2004, 11:03 PM
Approximately a week ago, there was another kernel security vulnerability discovered in the linux kernel. This is the second one announced and patched within the last 30 days. I am happy to report that all servers have been updated to new kernels to prevent this security hole from being exploited.

DetailsThe Linux kernel handles the basic functions of the operating system.

Paul Starzetz discovered a flaw in bounds checking in mremap() in the Linux
kernel versions 2.4.23 and previous which may allow a local attacker to
gain root privileges. No exploit is currently available; however, it is
believed that this issue is exploitable (although not trivially.) The
Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned
the name CAN-2003-0985 to this issue.


There are a couple of items I will mention with regards to these issues.

1. It is critical that these holes be patched as quickly as possible. We try to plug as many holes as we can identify as soon as the patches are deemed stable. However, it should be noted that the amount of time for testing with the new kernels is very limited. The criticality of the holes is, in many cases, so severe that slight instability is prefered over a system compromise.

2. Kernel updates require a reboot.

3. I am sure the next issue is a sore spot with some of our users, however, it is necessary that the holes are patched during "emergency maintenance windows". Specifically these in most cases will be unannounced outages. It would be irresponsible for us to announce to the world that our servers are (were) insecure and the time frame that a hacker would have to make an attempt on the server before the hole was plugged up. We certainly don't like any downtime and realize it concerns our users a great degree whenever there is downtime, however, I am still unsure what other options lie between the 2 alternatives.

bellgamin
01-18-2004, 12:22 AM
...The criticality of the holes is, in many cases, so severe that slight instability is prefered over a system compromise.

...We certainly don't like any downtime and realize it concerns our users a great degree whenever there is downtime, however, I am still unsure what other options lie between the 2 alternatives.

Good judgment. Honest disclosures, even when it hurts. That's why I stick with AOH.

grace & peace to ALL.........bellgamin