Press J to jump to the feed. Press question mark to learn the rest of the keyboard shortcuts

Linux Kernel Prior to 5.0.8 Vulnerable to Remote Code Execution

94% Upvoted
What are your thoughts? Log in or Sign uplog insign up
level 1
62 points · 1 day ago

Sorry, every kernel prior to 5.0.8? A difficult to exploit but totally exploitable root RCE over TCP?

Like every embedded system out there? Every android? Everything?

level 2
259 points · 1 day ago · edited 1 day ago

Sorry, every kernel prior to 5.0.8? A difficult to exploit but totally exploitable root RCE over TCP?

Welcome to the wonderful world of open-source freedom fighters and remote kernel memory corruption, where every vulnerability is (a) silently fixed; (b) announced in a security advisory as DoS-only; (c) announced in a security advisory as LAN-only; (d) announced in an erratum or reliability fix instead of in a security advisory; or (e) announced in a security advisory (before or after a news article) as remote code execution but requiring users to spend at least half an hour digging through source trees to ascertain actual impact.

It's (e) day today.

This bug is in the rds_tcp module, not the TCP/IP stack proper. The call paths are perfectly contained within the module_init() and module_exit() boundaries. The vulnerability therefore requires the rds_tcp module to be loaded. As you can see in net/rds/Kconfig, the kernel configuration option is RDS_TCP and is implicitly disabled by default, so you'd have to go out of your way to have the rds_tcp module statically compiled into the kernel. Some default build configurations for some architectures will override this and compile the rds_tcp module as an LKM (tristate 'm' option instead of the default 'n'), but that still has to be loaded by modprobe or friends. Running modprobe rds_tcp is an extremely rare thing to do.

level 3
46 points · 1 day ago · edited 1 day ago

We were just coming to this conclusion ourselves. It also appears that the bug was introduced in 2015 and does not go back 20+ years as had been indicated in other places.

EDIT: to prevent accidental or malicious loading we are blacklisting it. You can feel free to steal.

    - name: Blacklist rds_tcp
        content: |
          # rds_tcp is potental security issue, blacklisting to prevent accidental
          # loading. CVE-2019-11815
          blacklist rds_tcp
          install rds_tcp /bin/true
        dest: /etc/modprobe.d/rds-tcp-blacklist.conf
level 4
Comment removed by moderator1 day ago(1 child)
level 5
-1 points · 1 day ago

What is the reason I am being downvoted?

level 3

This is the comment we needed.

level 3
18 points · 1 day ago · edited 1 day ago

Between these commands you should know for sure if rds_tcp is loaded;
lsmod | grep rds

For this one you want to see '0' for disabled.
modinfo rds_tcp
echo $?

grep -r rds /etc/modprobe.conf /etc/modprobe.d/

And another;
cat /proc/modules | grep rds

modinfo rds_tcp

author: Oracle Corporation

level 3
5 points · 1 day ago

Fucking thank you.

I was trying to figure out how much I needed to be freaking out. There's a huge difference in "exploit in module that's not loaded by default in any distro" or "remote exploit for Linux kernel pre-firewall network stack". Every single shitty IoT box and phone would be forever compromised.

level 3

Good job!

level 3

We are noticing that current AWS Linux and some of our older RHEL boxes have the module enabled, seemingly by default since we didn't do it during install and config stages.

level 3

So even *if* you have the RDS-TCP module enabled, the conditions are incredibly ridiculous to be able to trigger this "remotely". This is verbatim what I posted on Twitter about it (because I'm too lazy to re-type it all):

So effectively what's required to hit the race condition is that an RDS over TCP client socket *in a network namespace* has the underlying TCP connection fail and attempts to reconnect. At the same time the network namespace needs to be cleared. Can't see how that would be remote.

I should also add that the attempted reconnect(s) of the underlying TCP transport need to fail in order for that one pointer to wind up null, which leads to the worker not being stopped, and using that "net" pointer after it's freed.

Basically there's two *big* conditions. A network namespace cleanup would somehow have to be triggered by an attacker and they'd have to entice the target to connect to an RDS-TCP socket. And that's ignoring what @grsecurity mentioned about the RDS module being blacklisted for a long time in most distros.

level 2
Original Poster17 points · 1 day ago · edited 1 day ago

There's a list of affected versions there:

Not sure how accurate it is though

level 3
22 points · 1 day ago

That kinda looks like every fucking thing.

level 4
8 points · 1 day ago

They mention namespace cleanup both in the article and in the stack trace. It looks like it may have a lower bound on whenever CONFIG_NET_NS was introduced (and actually enabled). I have no way to verify though.

Sounds like if anyone comes up with an exploitable scenario, it may be reckoning for all the crappy router / media device / iot / phone vendors out there without a clear upgrade path.

level 5
8 points · 1 day ago · edited 1 day ago

Network namespaces have been around for a VERY long time, this is effectively every Linux kernel being affected. The report lists kernels back to 2.0 and 2.5.1 was release in 2001. Let's be thankful this is a one-liner, it's likely to be back-ported quickly but patching is going to be a nightmare.

Appears to be limited to a not-loaded-by-default kernel module rds_tcp where bug was introduced in 2015, not 20+ years ago.

level 4
7 points · 1 day ago

Well, no... Linux Kernel 1.x is safe. Rejoice!

level 5
7 points · 1 day ago

Haven't updated since 1995 and it finally pays off.

level 2
3 points · 1 day ago

Yeah that would be a doomsday scenario. Title is clickbait.

level 2

I'd give it minus 2 points for not having a cutesy name, so that makes a base score of 6.1 (Meh-dium).

level 1
6 points · 1 day ago · edited 1 hour ago
$ modinfo rds_tcp |grep ^author
author: Oracle Corporation <...>
level 1
level 1

What’s the exploit vector for RCE? I’m assuming a Linux server with no open ports would be okay?

level 1

So... why is this issue not discussed enough? This makes the entire internet vulnerable, no? Guess i'm going to upgrade my PC to ubuntu 19.04.

level 2

The bug is in the RDS implementation. To my knowledge, it's not very widely used.

Most distros that provide it only do so as an unloaded kernel module. That's certainly the case with RHEL 6, RHEL 7, and Debian Stretch.

level 2
3 points · 1 day ago

Most distros should have a patch out soon.

More posts from the netsec community
Continue browsing in r/netsec
Community Details





A community for technical news and discussion of information security and closely related topics.

r/netsec Rules
Always link to the original source.
Titles should provide context.
Check the new queue for duplicates.
Commercial advertisement is discouraged.
Don't create unnecessary conflict
No prohibited content or sources
No low-quality or political posts