Submitted via IRC for AnonymousLuser:
Linux Kernel Prior to 5.0.8 Vulnerable to Remote Code Execution
Linux machines running distributions powered by kernels prior to 5.0.8 are affected by a race condition vulnerability leading to a use after free, related to net namespace cleanup, exposing vulnerable systems to remote attacks.
Potential attackers could exploit the security flaw found in Linux kernel's rds_tcp_kill_sock TCP/IP implementation in net/rds/tcp.c to trigger denial-of-service (DoS) states and to execute code remotely on vulnerable Linux machines.
The attacks can be launched with the help of specially crafted TCP packets sent to vulnerable Linux boxes which can trigger use-after-free errors and enable the attackers to execute arbitrary code on the target system.
The remotely exploitable vulnerability has been assigned a 8.1 high severity base score by NIST's NVD, it is being tracked as CVE-2019-11815 (Red Hat, Ubuntu, SUSE, and Debian) and it could be abused by unauthenticated attackers without interaction from the user.
Luckily, because the attack complexity is high, the vulnerability received an exploitability score of 2.2 while the impact score is limited to 5.9.
[...] The Linux kernel developers issued a patch for the CVE-2019-11815 issue during late-March and fixed the flaw in the Linux kernel 5.0.8 version released on April 17.
(Score: 2) by JoeMerchant on Tuesday May 14 2019, @04:33PM (9 children)
Any chance this will make it into Ubuntu 18.04.3?
🌻🌻 [google.com]
(Score: 2) by RS3 on Tuesday May 14 2019, @05:35PM (8 children)
Not sure, but sounds like I have to start compiling kernels again. Nobody should be allowed to have that much fun. Oh the library incompatibilities. Update at 5.
(Score: 1, Interesting) by Anonymous Coward on Tuesday May 14 2019, @07:10PM (7 children)
Indeed,
This hits one of my critical older 32 bit boxes.
Turns out I can't compile a 5.x series kernel on one machine as the compiler is old, can't compile a new compiler as some.other.shit is too old, after a happy hour of faffing, turns out the SRPMs for the underlying distro that I based this machine on are now making 64 bit assumptions somewhere (e.g. rather than looking for libraryXXYYZZ they're looking for library64XXYYZZ...if you compile the sources direct, they work....oh, joy!)
Let's try one of kernel 4.9.x series....looks like it will compile...this'll be fun, not done this for a couple of years...no doubt it will do my soul some good...
(Score: 2) by maxwell demon on Tuesday May 14 2019, @07:25PM (1 child)
Could a firewall filter out those specially-crafted TCP packets?
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by PartTimeZombie on Tuesday May 14 2019, @09:47PM
Yup. I am pretty sure that a combination of NAT and Snort or Suricata will help here. I should probably check to make sure though.
The fact my firewall is one of the BSD's might help too.
(Score: 2) by RS3 on Tuesday May 14 2019, @08:02PM
So Gentoo it is...
(Score: 2) by pe1rxq on Tuesday May 14 2019, @09:30PM (1 child)
or apply the patch yourself... its just a oneliner in tcp.c
(Score: 2) by RS3 on Tuesday May 14 2019, @10:21PM
Yes, but then recompile tcp.c and relink the kernel, afaik. Which really isn't all that difficult, so hopefully the patch will be applied to 4.x, 3.x, and 2.x kernels, but not sure who (which distros) will actually do it and make them available.
(Score: 2) by epitaxial on Wednesday May 15 2019, @01:46AM
Switch to FreeBSD, its so much nicer and less bullshit.
(Score: 0) by Anonymous Coward on Wednesday May 15 2019, @02:13AM
Why don't you just blacklist RDS and drop the whole address and protocol family in firewall? You probably aren't using RDS anyway.
(Score: 4, Funny) by Anonymous Coward on Tuesday May 14 2019, @04:35PM (4 children)
Toldja you should be running Windows instead. [ducking head]
(Score: 1, Funny) by Anonymous Coward on Tuesday May 14 2019, @04:42PM (2 children)
Me: watching you get beat..."Look at my Unix based MacOS"
Throw what you want I'm in a walled garden mwahaha
(Score: 3, Informative) by edIII on Tuesday May 14 2019, @07:28PM (1 child)
Why? You're already in the walled garden. Damage done ;)
Technically, lunchtime is at any moment. It's just a wave function.
(Score: 0) by Anonymous Coward on Wednesday May 15 2019, @04:30AM
Yup, pretty sure the last Tron movie showed how that idea goes.
(Score: 2) by bob_super on Tuesday May 14 2019, @09:18PM
> Toldja you should be running Windows instead. [ducking head]
Note to self : if worried I could get cooties from kissing that girl I like, the tradeoff is to pay to fuck the local whore bareback.
(Score: 2) by sshelton76 on Tuesday May 14 2019, @05:05PM (5 children)
uname -r shows I'm on 4.15.0-48-generic this is because I'm on mint.
I don't see an upgrade to the 5.x branch at all, but the ubuntu repos show this is a recent kernel.
Is there a clean way to upgrade, or did I fall behind on distros and not notice?
(Score: 2) by DeVilla on Tuesday May 14 2019, @05:19PM (2 children)
Odds are mint will provide a 4.15.0-???-generic which will have a patch. I was just checking if debian had a patched kernel yet.
(Score: 3, Interesting) by sshelton76 on Tuesday May 14 2019, @05:45PM (1 child)
Ok so I'm looking at the patch and it's description
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/?id=cb66ddd156203daefb8d71158036b27b0e2caf63 [kernel.org]
It seems to me like this is something that would be caught and killed with apparmor or selinux policies in place.
I'm looking for confirmation of my theory, but escalation to kernel mode from user space is one of the things those are designed to catch.
I'm also quite shocked at how tiny this patch is. It's literally just removing one OR comparator from and IF statement along with a total of about 13 bytes.
Considering how tiny this change is, I'm willing to bet the flaw literally dates back to Linus's junior high days.
(Score: 0) by Anonymous Coward on Wednesday May 15 2019, @05:32AM
Why are you speculating about the origin of the code instead of looking at git blame? You bothered to look at the patch itself so I don't get why you didn't just put another ten seconds on analyzing it.
The vulnerability was introduced in commit 467fa15356acfb7b which is Oracle code from 2015 and just concerns using reliable data sockets with network namespaces. You are very likely not using this anyway and you probably don't even have the vulnerable rds_tcp module loaded.
(Score: 1) by maggotbrain on Tuesday May 14 2019, @10:56PM (1 child)
My Mint Xfce system just offered me a 5.x kernel last night. Right now, I am running 5.0.0-15:
Linux wintermute 5.0.0-15-generic #16~18.04.1-Ubuntu SMP Tue May 7 14:17:37 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
I would guess some patches will be arriving shortly and would also be available for 4.18 and 4.15. The 4.15 kernel is an LTS supported until 2023. This might accelerate deprecation of the 4.18 kernel as it was only slate for support until August 2019. YMMV.
(Score: 0) by Anonymous Coward on Wednesday May 15 2019, @12:13AM
What version of mint? I may be on the wrong version because I dont see any options to go to 5.x and it has been my experience that a major change on kernel version typically requires a major change to the rest of the OS.
I thought I was on the most recent, but in retrospect it may have been 6 months or more since I re-installed last.
(Score: 1, Interesting) by Anonymous Coward on Tuesday May 14 2019, @05:10PM (12 children)
They are saying it's affecting all kernel prior to 5.0.8, does it go down to 1.0? Or is it only for the 5.0 serie?
(Score: 2, Funny) by Anonymous Coward on Tuesday May 14 2019, @05:44PM (5 children)
This:
https://www.securityfocus.com/bid/108283 [securityfocus.com]
Will answer your question.
The above was linked from the CVE Entry [mitre.org] linked in TFS.
There's plenty of other information there too. You might want to take a look, as I dropped my spoon and the five second rule has elapsed. As such, I am unable to feed you any more.
(Score: 2) by Freeman on Tuesday May 14 2019, @06:12PM
So, basically anything within the last 2 decades or so.
Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"
(Score: 4, Informative) by janrinok on Tuesday May 14 2019, @06:14PM (3 children)
It goes back to Kernel 2.0.
Just because it exists doesn't mean it has been exploited.
(Score: 2) by Freeman on Tuesday May 14 2019, @08:12PM
True, but it could have been exploited. Given that it's now public knowledge. You're going to want to update everything that matters.
Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"
(Score: 0) by Anonymous Coward on Wednesday May 15 2019, @05:34AM (1 child)
No it doesn't, it was introduced in 2015. It's also in an obscure module you very likely haven't loaded so this is not a big thing. Look at the git log.
(Score: 2) by janrinok on Wednesday May 15 2019, @06:45AM
https://www.securityfocus.com/bid/108283 [securityfocus.com]
This link begs to differ, which lists all the kernel issues since 2.4.
(Score: 0) by Anonymous Coward on Tuesday May 14 2019, @05:48PM
5.x is just a number and way too recent, assume at least 4.x is also vulnerable... better yet, assume way back to v0.x until you get a better range
(Score: 2) by RS3 on Tuesday May 14 2019, @06:05PM (2 children)
Article doesn't say. We'd need to know when the vulnerability was introduced into the kernel tree. More research needed... quick search didn't reveal code history...
(Score: 1, Informative) by Anonymous Coward on Tuesday May 14 2019, @06:32PM (1 child)
A really quick search, since you didn't even include comments to this thread:
https://soylentnews.org/comments.pl?noupdate=1&sid=31600&page=1&cid=843507#commentwrap [soylentnews.org]
relevant link: https://www.securityfocus.com/bid/108283 [securityfocus.com]
(Score: 2, Interesting) by Zappy on Wednesday May 15 2019, @08:24AM
According to RedHat the bug was introduced with commit bdf5bd7f21323493dbe5f2c723dc33f2fbb0241a dated 19 Mar 2018.
So it's introduced in the 4.14/4.15 era and not all the way back in 2.0
(Score: 2) by sshelton76 on Tuesday May 14 2019, @06:07PM
Looking at the diff
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/?id=cb66ddd156203daefb8d71158036b27b0e2caf63 [kernel.org]
That has probably been there since Linus was in Jr High.
(Score: 1) by Zappy on Wednesday May 15 2019, @08:26AM
According to RedHat the bug was introduced with commit bdf5bd7f21323493dbe5f2c723dc33f2fbb0241a dated 19 Mar 2018.
So it's introduced in the 4.14/4.15 era.
(Score: 0) by Anonymous Coward on Tuesday May 14 2019, @05:51PM (2 children)
All my (non-production) Linux boxes are 5.0.9 or later.
Fedora FTW!
(Score: 0) by Anonymous Coward on Tuesday May 14 2019, @09:20PM
5.0.12.a-1-hardened
I use Arch, btw. :)
(Score: 0) by Anonymous Coward on Tuesday May 14 2019, @11:55PM
Indeed. But even for my CentOS boxes, I use ELRepo repositories to keep the kernel up-to-date. Right now they sit at 5.0.10.
(Score: 1, Funny) by Anonymous Coward on Tuesday May 14 2019, @05:56PM (1 child)
If it's compiled as a module then blacklisting should do the trick.
(Score: 0) by Anonymous Coward on Tuesday May 14 2019, @10:55PM
The RDS protocol should never be enabled on any ordinary system.
http://events17.linuxfoundation.org/sites/events/files/slides/rds.pdf [linuxfoundation.org]
(Score: 2) by Gaaark on Tuesday May 14 2019, @06:32PM (1 child)
sudo manjaro-settings-manager
Install 5.09-2
Reboot
Living the dream. It's got the changelog there and all.
--- Please remind me if I haven't been civil to you: I'm channeling MDC. ---Gaaark 2.0 ---
(Score: 1, Interesting) by Anonymous Coward on Tuesday May 14 2019, @09:15PM
I have unstable repos enabled and given them a low pin priority. I'm using testing, which everyone says you shouldn't and I agree (from a security perspective).
The issue is fixed in 4.19.37-1 in Sid, so all I had to do was: apt-get -t unstable install linux-image
(Score: 0) by Anonymous Coward on Tuesday May 14 2019, @07:35PM (2 children)
OpenWrt 18.06.1 is on ... 4.9.120 ?
(Score: 2, Interesting) by Anonymous Coward on Tuesday May 14 2019, @07:38PM
AND all your ... androids?
(Score: 2, Informative) by pTamok on Wednesday May 15 2019, @02:58PM
(Score: 0) by Anonymous Coward on Tuesday May 14 2019, @08:17PM (1 child)
You should be completely unaffected if CONFIG_RDS is disabled in your kernel, "The Reliable Datagram Sockets Protocol"; actually you should be fine if CONFIG_RDS_TCP is disabled, "RDS over TCP".
I don't even know what that protocol is used for, probably some weird cluster storage systems due to it apparently having support for things like RDMA and Infiniband. Probably the vast majority of Linux users have never heard of these things and have no use for this protocol whatsoever.
When you configure your kernels just say no to network protocols (or any other feature, for that matter) you've never heard of.
(Score: 4, Funny) by c0lo on Tuesday May 14 2019, @09:31PM
Hey, what's that TCP I'm seeing thrown around in the comments? Can I trust it?
(large grin)
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 3, Informative) by Anonymous Coward on Tuesday May 14 2019, @10:47PM (2 children)
echo -e "blacklist rds\ninstall rds /bin/false" > /etc/modprobe.d/rds.conf
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928989#12 [debian.org]
(Score: 0) by Anonymous Coward on Wednesday May 15 2019, @08:58AM
The module isn't even loaded in default debian installs.
(Score: 2) by cosurgi on Wednesday May 15 2019, @02:22PM
So, `lsmod | grep -i rds` and we are good to go.
#
#\ @ ? [adom.de] Colonize Mars [kozicki.pl]
#