Severe Linux Kernel Flaw Found In RDS (sophos.com) 90
jwhyche (Slashdot reader #6,192) shared this article from Sophos:
Linux systems running kernels prior to 5.0.8 require patching after news emerged of a high-severity flaw that could be remotely exploited.
According to the NIST advisory, CVE-2019-1181 is a race condition affecting the kernel's rds_tcp_kill_sock in net/rds/tcp.c "leading to a use-after-free, related to net namespace cleanup." The RDS bit refers to systems running the Reliable Datagram Sockets (RDS) for the TCP module, which means only systems that run applications using this are affected.
The attention-grabbing part is that this opens unpatched systems to remote compromise and denial of service without the need for system privileges or user interaction. On the other hand, the attack complexity is described as 'high', and any such attack would need to be launched from the local network.
According to the NIST advisory, CVE-2019-1181 is a race condition affecting the kernel's rds_tcp_kill_sock in net/rds/tcp.c "leading to a use-after-free, related to net namespace cleanup." The RDS bit refers to systems running the Reliable Datagram Sockets (RDS) for the TCP module, which means only systems that run applications using this are affected.
The attention-grabbing part is that this opens unpatched systems to remote compromise and denial of service without the need for system privileges or user interaction. On the other hand, the attack complexity is described as 'high', and any such attack would need to be launched from the local network.
Re: (Score:1)
and has to download some update with yet another EULA
This is Linux not Windows. The GPL isn't changed with every patch or indeed with any patch.
Can Anybody Provide Examples (Score:1)
...only systems that run applications using this are affected.
Which applications use RDS?
Re: Can Anybody Provide Examples (Score:1)
Mostly Oracle. They contributed the kernel code because their user mode code was having performance issues under heavy load.
Re:B-but... open source... tons of eyes...?! (Score:5, Interesting)
>" I thought the "many eyes" looking at all open source code 24/7 would ensure that there are no bugs?"
I have never seen anyone claim that. What I have seen claimed is that healthy open-source projects tend to produce code in which flaws are found, corrected. and distributed more rapidly than closed-source. And from what I have seen over many years, this appears to be true, as a generality. It is not always true, nor does it apply to all projects.
Even more important, it is far less likely that malware, spyware, and back-doors get inside (or remain inside) major open-source projects- better protecting privacy and security.
Re: (Score:2)
>" I thought the "many eyes" looking at all open source code 24/7 would ensure that there are no bugs?"
I have never seen anyone claim that. What I have seen claimed is that healthy open-source projects tend to produce code in which flaws are found, corrected. and distributed more rapidly than closed-source. And from what I have seen over many years, this appears to be true, as a generality. It is not always true, nor does it apply to all projects.
In addition, many (most?) people are trained and/or learn to program in the same fashion which can lead to similar techniques and solutions as well as oversights and errors -- this can be a problem with n-version fault tolerance (and one way to avoid this is to use different kinds of languages for each version). So even with many people reviewing code, there is a potential to miss things.
As for the 24/7 commentary, whenever I hear this I think of the Steven Wright joke:
A guy walks up to a store as the owner is locking the door:
Owner: Sorry, we're closed.
Guy: The sign says "Open 24 hours".
Owner: Not in a row.
Re: (Score:1)
Then take a walk across the ocean, moron.
Waiting for it to freeze first.
Re:B-but... open source... tons of eyes...?! (Score:4, Interesting)
The correct quote is given enough eyeballs, all bugs are shallow. [wikipedia.org] Rated: mostly true. There have been some really hard ones, even with many eyeballs, many very smart eyeballs. But the typical lifetime of a kernel bug, once observed, is minutes to hours.
Re: (Score:1)
I thought the "many eyes" looking at all open source code 24/7 would ensure that there are no bugs? How can this security hole exist, then? It must be fake! Not real!
Are you so stupid as to not realize you are claiming a bug remains unfound, posting that claim in a threat reporting the bug being found?
Re: (Score:2)
Actual quote: "given enough eyeballs, all bugs are shallow" In practice this means that bugs when found are quickly characterised by a wide group of people and patches distributed.
Re: (Score:2)
Re: A normal/expected bug make a ./ headline why? (Score:2, Funny)
https://nakedsecurity.sophos.com/2019/05/16/severe-linux-kernel-flaw-found-in-rds/
https://security-tracker.debian.org/tracker/CVE-2019-11815
https://oss.oracle.com/pipermail/rds-devel/2007-November/000228.html
Reliable Datagram SocketsÂ(RDS) is a high-performance,Âlow-latency,Âreliable,Âconnectionlessprotocol for deliveringÂdatagrams. It is developed byÂOracle Corporation.
It was included in theÂLinux kernelÂ2.6.30 which was released on 9th of June, 2009. The code was co
Re: (Score:2)
What's an "expected bug"?
Re: A normal/expected bug make a ./ headline why? (Score:2)
Re:A normal/expected bug make a ./ headline why? (Score:4, Interesting)
A bug in an oddball protocol that I have not heard of anybody using. If you are reading this, then certainly not you.
BTW, buggy code from Oracle, thanks a bunch.
In other words, don't panic (Score:2)
Just patch as needed. If you do not use RDS (which will be most cases), no need to do anything urgently.
Re: (Score:1)
My fee is $200 per hour, payable in advance in this case. Are you willing to pay? If not, then STOP TROLLING YOU TWAT AND ASK YOUR DISTRO FOR AN UPDATE!
Re: (Score:1)
Thanks.
Re:In other words, don't panic (Score:4, Informative)
See if rds is loaded:
lsmod | grep -i rds
if you don't see it listed, good, you're not vulnerable at the moment, and if you can't update your kernel you should blacklist the module.
if you do see it listed and can't update your kernel, you can try "rmmod rds" and see if anything breaks. If there are no problems, blacklist the module.
Re: (Score:2)
Hm, which implementations of sudo alter the shell's redirection mechanism? I have learned that this is more effective:
echo "blacklist rds" | sudo tee -a /etc/modprobe.d/blacklist.conf
Re:In other words, don't panic (Score:5, Informative)
>"Just patch as needed. If you do not use RDS (which will be most cases), no need to do anything urgently."
And even then, it is a local-only exploit that also requires a great deal of effort. Not sure I would call it a "severe flaw". Article:
" any such attack would need to be launched from the local network. That explains why itâ(TM)s been given a CVSS 3.0 impact score of 5.9 with an exploitability score of only 2.2."
" I havenâ(TM)t yet seen evidence to support allegations that this is remotely exploitable."
" it requires the attacker to 'manipulate socket state while a network namespace is being torn down.' So, not easy then."
Re: (Score:2)
Indeed.
Re: (Score:2)
To be fair, a large number of computers are behind junk routers/firewalls that can be pwned with kits and then you have LAN. Like a DLink or Cisco.
We must assume all vulnerabilities are in a context of systems now, not isolated.
Re: (Score:2)
Re: (Score:3)
That it is not needed if the designers have a bit more of a clue than you do.
Re: (Score:2)
OP's comment was more or less clueful, to be honest. The current fashion is to roll a new protocol in user space base on straight-up UDP. Various attempts to do something definitive at the official protocol level have mostly not gotten much traction, perhaps these attempts to remedy all the flaws of TCP in one grand all singing all dancing design flourish do not seem to generalize to very many of the situations that need this kind of thing.
Re: (Score:2)
Thanks. Also, it turns our that requirements for reliable datagram services vary widely. The proposals I have seen were a mess of parameters and would probably have been impossible to implement. Doing the reliability type you need yourself over UDP works pretty nicely though.
Re: (Score:2)
ISPs have broken the Internet, which is why new protocols don't work well. They buy crap middleware boxes which only understand IPv4 UDP and TCP, or worse, only HTTP.
In the name of "security" they reject anything they don't understand. And since ISPs are cheap they never update these pieces of junk if they can help it.
And then there's NAT which has to understand the protocol so it can rewrite it.
Since no one can effectively use a new protocol on the Internet, there's no users, so they can point out that the
Re: (Score:2)
The clueless is strong in this one. QUIC is UDP.
Re: (Score:2)
But UDP doesn't guarantee delivery.
There is no protocol that guarantees delivery.
Re: (Score:2)
While technically true, what TCP actually assures is that if it does not give an error message, the data has been delivered. Everybody (including experts) just call that "reliable delivery".
Re: (Score:2)
My new protocol will guarantee delivery, but not necessarily in a finite amount of time. ;)
Re: (Score:2)
So basically nobody besides them uses it? Also no surprise it is crap if it comes from Oracle....
Re: (Score:2)
If you do not use RDS (which will be most cases), no need to do anything urgently.
Let's be clear about it: nonusers of RDS are the _vast_ majority of cases. I've never seen it used at all, actually. I guess there must be some setup that uses it, somewhere.
Re: (Score:2)
My take also. I just removed it from my kernel. No need for it anyways.
This hasn't been posted before? (Score:2)
Because if it hasn't, there is a *big* delay in the posting queue. This was published, what, Monday?
Re: (Score:2)
more secure ... than?
Which way? (Score:2)
# CONFIG_RDS is not set (Score:2)