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 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.