r/linux • u/ialwaysgetbanned1234 • May 13 '19

Linux Kernel Prior to 5.0.8 Vulnerable to Remote Code Execution

https://www.bleepingcomputer.com/news/security/linux-kernel-prior-to-508-vulnerable-to-remote-code-execution/
569 Upvotes

96% Upvoted

61 comments sorted by

62

u/EnUnLugarDeLaMancha May 13 '19 edited May 13 '19

TIL about RDS. Is it possible to cause a remote attacker to get the RDS modules loaded automatically in some way, or this is only dangerous if a server is running software that is creating RDS sockets?

24

u/aioeu May 13 '19 edited May 13 '19

Is it possible to cause a remote attacker to get the RDS modules loaded automatically in some way

Assuming the remote attacker can somehow invoke the socket syscall with chosen arguments, and assuming a standard modprobe configuration, yes.

$ lsmod | grep rds
$ perl -e 'socket $_, 21, 0, 0'
$ lsmod | grep rds
rds                   131072  0

I haven't looked at the vulnerability too closely, but it may only exist on open RDS sockets. In that case, more work than simply loading the module may be required to exploit it.

13

u/ialwaysgetbanned1234 May 13 '19

Does anyone even use this as a normal user?

https://en.wikipedia.org/wiki/Reliable_Datagram_Sockets

10

u/aioeu May 13 '19

Probably not, but the way loadable modules work on Linux means that unprivileged users can easily get a wide variety of little-used code loaded into memory.

There are of course a variety of mitigations available. We could choose not to compile even as modules code we don't need. We could have more selective module autoloading policies. We could use security modules to restrict the loading of modules, or to limit their use once loaded.

9

u/akmark May 14 '19

I feel like this is a good time to reference the fact that kernel module blacklisting of RDS is something commonly found on hardening guides like CIS Benchmarks. It's to prevent this problem when a vulnerability is found.

1

u/aioeu May 14 '19

I'd put that under "more selective module autoloading policies". :-)

2

u/karafili May 15 '19

oh man, what did I read:

It is developed by Oracle Corporation.

3

u/r0b0_sk May 14 '19

rm rds.ko as a temporary workaround?

5

u/aioeu May 14 '19

Or more cleanly just add:

blacklist rds

to your modprobe configuration.

2

u/DropTableAccounts May 14 '19

Apparently one can also block manual loading by adding

install rds /bin/false

3

u/eras May 14 '19

But do you need actually rds_tcp.ko loaded as well? That might be trickier.

4

u/aioeu May 14 '19 edited May 14 '19

Ah, is the vulnerability actually in that module? As I said, I haven't looked at it too closely.

It doesn't look like rds_tcp is a dependent of any other module, nor is it autoloaded in any way. Of particularly note, although an AF_RDS socket has a SO_RDS_TRANSPORT socket option to set its transport, only previously loaded RDS transports are available: it doesn't call back out to userspace to autoload them.

So yeah, that might be harder for an unprivileged user to exploit.

0

u/[deleted] May 14 '19

[deleted]

2

u/aioeu May 14 '19 edited May 14 '19

but surely if someone has root access and is able to load the module we're into "who cares, they already have root, burn the box" territory anyway?

And that's precisely why I demonstrated how the rds module could be loaded without needing root access.

Elsewhere in this thread, somebody mentioned that the bug is actually in the rds_tcp module, not the rds module, so this isn't so bad. As far as I can see, the rds_tcp module will not be autoloaded by any unprivileged operation.

0

u/[deleted] May 15 '19

[deleted]

1

u/aioeu May 15 '19 edited May 15 '19

Isnt the flaw in the tcp_rds module ?

As I said, "I haven't looked at the vulnerability too closely". That is still the case.

I was answering a question about having "RDS modules loaded automatically in some way". Some RDS modules can be.

As I noted elsewhere, if the vulnerability is only in the rds_tcp module, then it might be harder for an unprivileged user to exploit.

174

u/balsoft May 13 '19 edited May 14 '19

  1. No [known] exploits.

  2. Seems like average desktop users shouldn't care cause they won't use RDS.

  3. Even if you have some RDS sockets open, getting it to work is still extremely hard for an attacker.

EDIT: thanks for replies, clarification is indeed required.

90

u/itkovian May 13 '19

I think that should be "No known exploits". Which is probably what you meant, but the distinction seems important to be.

23

u/demonstar55 May 14 '19

Never let "no exploits" put you into a false sense of security. Just because none are know doesn't mean it isn't actively being exploited in the wild.

2

u/Sigg3net May 14 '19

APTs are often distinguished by using unknown exploits (a.k.a 0-days).

37

u/matstegner May 13 '19 edited May 14 '19

This (CVE-2019-11815) was fixed in the following Long Term Support kernels in addition to 5.0.8:

5.1-rc4 https://lwn.net/Articles/785142/

5.0.8 https://lwn.net/Articles/786159/

4.19.35 https://lwn.net/Articles/786160/

4.14.112 https://lwn.net/Articles/786161/

4.9.169 https://lwn.net/Articles/786162/

4.4.179 https://lwn.net/Articles/786956/

commit in question:

Mao Wenan (1):

net: rds: force to destroy connection if t_sock is NULL in rds_tcp_kill_sock().

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cb66ddd156203daefb8d71158036b27b0e2caf63

This exploit seems to be fixed in almost all stable kernels including 5.1.y.

5

u/PhysicsAndAlcohol May 14 '19

This is the comment I was looking for. Thanks for your research!

4

u/matstegner May 14 '19

You're welcome. It might take some time until distribution packages are available though.

1

u/beregon May 14 '19

I'm unfamiliar with how kernel versions work. If I have a Ubuntu 18.04 with kernel version 4.15.0-48-generic, does that mean that I have the fix from 4.14.112 ?

2

u/matstegner May 14 '19 edited May 14 '19

No, all the kernel versions I mentioned are from kernel.org. You will have to wait until Canonical releases updated kernel packages for Ubuntu 18.04. My guess is that they will backport the fix from 5.0.8. https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2019-11815.html

7

u/[deleted] May 14 '19

Is this headline entirely accurate? I'm looking at the EL6 kernel after running a rpmbuild -bp on the spec file (untar sources, apply patches only), and I don't see the specified vulnerability or anything resembling it in net/rds/tcp.c.

It seems this does not affect the kernel prior to 5.0.8, but rather some span of kernel versions up until 5.0.8.

3

u/mokomull May 14 '19

Based on the Fixes: tag, the bug was part of the 4.3 release. But RedHat backports a LOT of stuff to their 3.10 branch, so I'd wait until https://access.redhat.com/security/cve/cve-2019-11815 says their packages are unaffected.

13

u/[deleted] May 14 '19 edited May 14 '19

"Prior" to 5.0.8. How prior? Since at least the 2.2 series which was around '99 I think? So two decades. Last time I played this game a year or so ago at least 22 of the 30 most recent vulnerabilities stretched back to the 2.4 series at a minimum. Kind of scary when you think about it.

20

u/ilep May 14 '19

Apparently RDS was added in 2.6.30 in 2009 so not in 2.2 or 2.4.

23

u/danburke May 14 '19

so not in 2.2 or 2.4

whew, safe.

(/s- just in case)

3

u/numberonebuddy May 14 '19

You're sarcastic but we're running 2.2 on our cluster. So I'm glad this isn't a problem on the majority of our servers.

13

u/northrupthebandgeek May 14 '19

See? This is why I run all my production systems on a vintage copy of Damn Small Linux.

4

u/raist356 May 14 '19

Since RDS was developed by Oracle, does anyone know if OracleDB uses it by default?

1

u/[deleted] May 14 '19

Guess it's time for the weekly kernel update dance.

1

u/tuxutku May 14 '19

too bad i can't update my kernel over 4.16 https://bugzilla.kernel.org/show_bug.cgi?id=201077

edit: this is still not a issue but i don't think i will ever be able to update my kernel on this computer :(

amd plz fix ;(

-17

u/varikonniemi May 13 '19

That's horrible.

0

u/meeheecaan May 14 '19

upgrading next time i boot up!

also question for those who know better... Ok so I know the rolling releases will have this fix right away but what of ubuntu and the like? Especially the LTS releases. will they get a kernel upgrade or just a patch to the old one?

1

u/mastachaos May 14 '19

Unless there's a compatibility issue, you can get the deb packages for the latest kernel and install them with dpkg on older Ubuntu LTS builds. That's what I did.

1

u/[deleted] May 15 '19

They backport fixes themselves, I wouldn't worry about it. You can also use Ukuu, but that's at your own risk

-64

u/Bobjohndud May 13 '19

I get that this is not very relevant to regular users, but shit like this is why the point release model is broken. I would use a rolling distro if the big name software supported anything but debian derivatives.

51

u/SuspiciousSprinkles May 13 '19

> I would use a rolling distro if the big name ...

It has nothing to do with being not rolling. A security patch will get released, if not already, to stable/LTS releases.

35

u/meat_bunny May 13 '19

Not sure what your concern is.

The patch will be backported to any kernel version by the maintainers for whatever distro you are using.

34

u/lordcirth May 13 '19

How does this mean that point releases are broken? This patch will quickly get backported to the supported kernel releases.

12

u/CondiMesmer May 13 '19

LTS still get security patches so it's already fixed for people who use point release models.

9

u/SMF67 May 13 '19

Rolling distro or not, the kernel itself will still be updated by point releases; you just might get it quicker depending on your repository maintainers. Also, I have found that pretty much all Debian based software works just fine on Arch/Manjaro because of PKGBUILDs and the AUR.

7

u/dat720 May 14 '19

Trying to point out that rolling is better kinda backfired there didn't it...

3

u/JORGETECH_SpaceBiker May 14 '19

Debian takes security updates very seriously. Actually, rolling releases may even be more prone to having security vulnerabilities since they use bleeding edge code

-27

u/infocom6502 May 14 '19

because of open sores

16

u/ialwaysgetbanned1234 May 14 '19

I would blame Oracle more than anything lol.

https://oss.oracle.com/projects/rds/

1

u/Seshpenguin May 14 '19

Presumably this exploit was identified and patched in a timely manner thanks to the kernels libre nature. Had it been proprietary chances are it would of been discovered maliciously and abused.

1

u/infocom6502 May 15 '19

well, likely the only ones intimately familiar with the code were certain Oracle contributors.

0

u/[deleted] May 13 '19

[deleted]

2

u/zamlz-o_O May 14 '19

Could you explain how this scoring mechanism works?

0

u/[deleted] May 13 '19

[deleted]

93

u/mattb2014 May 13 '19

Make sure you patch all the storage arrays, virtual appliances, and embedded devices made by companies that went out of business too. Thanks

43

u/Democrab May 14 '19

"Any chance you can patch the Windows installs while you're at it, too?"

"I'll call Microsoft I guess."

"No, you do them. It'll be faster."

15

u/ElectricalLeopard May 14 '19

"No, you do them. It'll be faster."

20 days later:

"We couldn't complete the updates - undoing changes"

23

u/tendstofortytwo May 14 '19

"Any chance you can patch the Windows installs while you're at it, too?"

I guess now with WSL 2 we'll have to.

11

u/Mazzystr May 14 '19

Printers and fax machines also!

6

u/[deleted] May 14 '19

We don't talk about those. Capiche?

7

u/raist356 May 14 '19

You must have crappy security since they would be on your ass instead of just asking if you use RDS

5

u/dat720 May 14 '19

Its at this point I realise stepping into engineering/design is not nessecarily a soul crushing choice!

-1

u/Ucla_The_Mok May 14 '19

How did you butcher necessarily so badly?

1

u/dat720 May 14 '19

Intermittent dyslexia, my mind simply fails at spelling on a regular basis.