https://www.securityfocus.com/bid/108410
From the RedHat bug discussion:
https://bugzilla.redhat.com/show_bug.cgi?id=1709180
A flaw was found in the Linux kernels implementation of IPMI (remote baseband access) where an attacker with local access to read /proc/ioports may be able to create a use-after-free condition when the kernel module is unloaded. The use after-free condition may result in privilege escalation. Investigation is ongoing.
See https://security-tracker.debian.org/tracker/CVE-2019-11811 for a lot of other distro links (the Source section at the top).
This discussion has been archived.
No new comments can be posted.
Linux Kernel Hole Reported: CVE-2019-11811
|
Log In/Create an Account
| Top
| 17 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
(1)
(Score: 4, Touché) by The Shire on Monday July 22 2019, @06:22PM (9 children)
Anyone who keeps their kernel up to date is not affected.
Anyone who lets their servers languish unpatched can't be helped.
(Score: 2) by DannyB on Monday July 22 2019, @06:38PM (2 children)
There could come a day when anyone who keeps their kernel up to date could be the only one affected.
It's not an impossible dream. It could be a dream come true. Given the right circumstances.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 3, Interesting) by stormreaver on Monday July 22 2019, @07:18PM (1 child)
It's not an impossible dream, because it's happened in the past. I just don't have the desire to find it.
(Score: 5, Insightful) by The Shire on Monday July 22 2019, @07:51PM
It totally has, no need to look it up. But that's the exception to the rule - it's really rare. And you can manually reverse out a patch like that very quickly.
The difference of course is your exposure time is vastly reduced when you maintain a regular patch schedule. Debian for example is very fast to get security patches out so if you maintain an up to date kernel and ancillary packages your exposure is at most a few hours and that assumes you aren't manually patching even sooner. Your odds of staying "safe" are greatly improved by simply keeping your crap up to date.
By the time that exim zero day made the news all the systems under my control had already self patched. It's the folks who manually patch and subsequently forget to do it that get bitten in the ass. Botnets are made of all the orphaned servers that IT has forgotten about.
So yea, I'm perfectly happy letting everything patch constantly. It's rare that a service needs to be restarted and even more rare that a server itself needs a restart. And in a cluster, having machines performed staggered restarts doesn't even impact the production environment they run in.
Really no good reason not to perform continuous patching.
(Score: 2) by RS3 on Monday July 22 2019, @07:53PM (4 children)
I keep kernels up to date as much as I can.
But remember, bugs are introduced into the code, so you might happen to have an older but bug-free kernel.
(Score: 2) by The Shire on Monday July 22 2019, @08:05PM (3 children)
Most of the time it's a bug that has been in the code for a very long time. Bug free kernels sadly don't exist.
I just sleep better at night with continuous automatic patching.
But I get that some companies won't allow it and instead require significant validation before any patches are released to production. But personally I would rather revert a rare breaking change than get compromised due to an unpatched system.
(Score: 2) by vux984 on Monday July 22 2019, @08:23PM (1 child)
That's been my philosphy too; keep them up to date and deal with the fallout THAT causes. Its a more defensible position than than dealing with the fallout of unpatched systems with known issues. And like you observed -- most breaking changes just cause a crash. Unpatched systems result in compromises. I'd rather deal with a crash than a breach; especially if reverting is all it takes to resolve the crash.
Even with windows updates, where I've been bitten a few times over the years; I still think its been worth staying up to date despite those incidents.
(Score: 0) by Anonymous Coward on Monday July 22 2019, @09:13PM
Like this one ("privilege escalation" through running rmmod of all things? are they for real?) or the previous sound and fury about vulnerable RDS (a protocol that no one uses, compiled into module that never gets loaded).
While bleeding-edge kernels get data loss bugs. I would MUCH rather deal with a fictional "breach" or two that have no chance to affect a real-world system, than with an actual massive loss of data. Not everything is cat pictures, not everything is backed up right on creation, and some data loss bugs can trash your backups just as nicely. Examples abound.
(Score: 2) by RS3 on Tuesday July 23 2019, @12:18AM
Yes, I agree and I do that too, esp. for stable kernel releases. I was just pointing out that sometimes bugs are recent additions.
Can complex code ever be bug-free? Every now and then I read about a "race condition", which I know well in HW, but SW? Hmmm...
(Score: 2) by PartTimeZombie on Monday July 22 2019, @08:35PM
Good policy.
Also, don't give local access to all and sundry:
I am going to assume that local attacker also needs to be part of the sudoers group.
I am not going to worry too much about this one.
(Score: 0) by Anonymous Coward on Monday July 22 2019, @06:22PM (1 child)
https://bugzilla.redhat.com/show_bug.cgi?id=1709180#c11 [redhat.com]
(Score: 0) by Anonymous Coward on Monday July 22 2019, @07:08PM
But don't unload the module if the module is already loaded as it is exploitable only on during the unload
(Score: 2) by sjames on Monday July 22 2019, @10:56PM
Fortunately, this bug is unlikely to be triggered and unlikely to be exploited. Looking at the actual kernel patch, it could only happen iof the module failed to init when loaded, and when the bug is triggered, the kernel oopses.
(Score: 0) by Anonymous Coward on Monday July 22 2019, @11:49PM (1 child)
From Wikipedia:
IPMI - Intelligent Platform Management Interface
The Intelligent Platform Management Interface is a set of computer interface specifications for an autonomous computer subsystem that provides management and monitoring capabilities independently of the host system's CPU, firmware and operating system.
From Common Sense:
This is going to f*** up.
(Score: 0) by Anonymous Coward on Tuesday July 23 2019, @01:04AM
it's another form of "problem is between keyboard and monitor".
recommend having the" remote monitor and keyboard translated thru network "on seperate ethernet cables totally?
note: IPMI DOES save on having to buy one keybaord AND monitor for each computer?
(Score: 2) by boltronics on Tuesday July 23 2019, @02:23AM
I thought we couldn't trust Huawei, but here they are fixing critical issues in the Linux kernel. What gives?
It's GNU/Linux dammit!
(Score: 2) by RamiK on Tuesday July 23 2019, @09:45PM
Although their release logs aren't covering everything, they push out stable releases when serious remote vulnerabilities are discovered.
e.g. the recent https://openwrt.org/releases/18.06/changelog-18.06.4 [openwrt.org] dealt with CVEs that left the kernel vulnerable to DDOSing as well as an integer overflow vulnerability in libcurl.
compiling...