Hacker News new | comments | show | ask | jobs | submit login
Udp.c in Linux kernel pre-4.5 allows remote attackers to execute arbitrary code (nist.gov)
233 points by OrangeTux 164 days ago | hide | past | web | 65 comments | favorite

The RHEL web page is singularly unhelpful. Do they mean that is not affected if you update today and reboot, or that they have never shipped a kernel with the affected functionality enabled? I have a server with just over a year's uptime, so I need to know.

The debian web page at least lists the exact kernel version they ship where it is confirmed fixed.

The Statement near the top seems unambiguous:

> This issue does not affect the Linux kernel packages as shipped with Red Hat Enterprise Linux 5, 6, and 7, Red Hat Enterprise MRG 2, and realtime kernels as the code that introduced the flaw is not present in these products.

That statement has been subsequently added. And yes.

Definitely. Thanks.

Thanks, I wrote that statement. I think it might be worth it if the statement text makes its way across to the CVE pages.

Would a kernel-level firewall (iptables) help in this case? Or does the vulnerability happen before the packet can be discarded by iptables?

If so, what is a good firewall frontend for Android?

Given that the PEEK flag is needed, I'd say an application needs to try to use the data first (with that flag). A firewall would do the trick to block that I guess.

Hm, I find it very hard to believe how something would not be affected by this. Did they backport the patch earlier than others? Or is there perhaps some dependency on specific kernel configurations?

Looks like this was patched a while ago in both RedHat and Debian distros.



Always funny to see how banal bug fix commits are in comparison with the severity of the bug itself


I'm not sure how the Linux kernel handles these, but in some projects, this is intentional, the goal being to land the fix and make everyone safe before knowledge of how to exploit the bug is widely known.

Of course, sometimes just fixing up code for stability reasons may close a security hole that isn't really known or understood yet.

Not sure which was happening here.

See http://yarchive.net/comp/linux/security_bugs.html

Relevant Linus quote: "I personally consider security bugs to be just "normal bugs""

I just mean the code delta itself; one line of code can make a lot of difference :)

Sometimes even one character can make a lot of difference: https://en.wikipedia.org/wiki/Mariner_1#.22The_most_expensiv...

This is probably less severe than it sounds like because of the MSG_PEEK option needed in recvfrom(), which is rarely used.

OpenSSL uses the flag in a couple of places: https://github.com/openssl/openssl/search?utf8=%E2%9C%93&q=M...

Does anyone know what crypto/bio/bss_dgram.c does?

That's an abstraction around datagram IO, for use inside other parts of OpenSSL.

I'd assume it's for use with DTLS, which is a less commonly used part of OpenSSL.

Public information is very thin on the exploitability of this. Are you able to elaborate a little bit where MSG_PEEK might be used? Is it used in the kernel? Only in specific applications?

Reading the original link, it looks like the kernel corruption only happens when an user space application uses the recvfrom() syscall using the MSG_PEEK option. MSG_PEEK is only used AFAIK only in specific applications that need to "peek" at the message without consuming it. This is not a very common use case, but some research should be done to understand if there is some popular application using it.

If I've understood this correctly, it turns it into a local privilege escalation opportunity: run a vulnerable application as the user, use the exploit to get code execution in the kernel.

Yes that's my understanding as well, user space code using a given syscall with given parameters triggers the kernel exploit.

Yeah, but there is still a little bit of explicit usage of recvfrom() with MSG_PEEK


And probably more implicit


The use in wget seems a little scary.

I believe you've misread the article, first line:

> udp.c in the Linux kernel before 4.5 allows remote attackers to execute arbitrary code via UDP traffic....

> MSG_PEEK is only used AFAIK only in specific applications that need to "peek" at the message without consuming it

I never used the MSG_PEEK flag, but over 15 years ago (maybe it wasnt implemented yet?) I accomplished a similar task by using the SO_REUSEADDR and SO_REUSEPORT flags which worked nicely on Windows too. The goal was to have several UDP "agents" listening on the same port on the same machine (which would normally raise an EADDRINUSE error), all of them examining a packet and acting upon a header contained in that packet. All them would receive a copy of the packet on their respective socket (that was the flags purpose), so that they could filter it and act only if the header contained data relative to that agent. This allowed a very modular approach where once the protocol was defined I could compile only the agent I needed without touching the others.

This is a flag that the application has to explicitly set when receiving data. Looks like this flag has limited usage based on the description. I've checked with the strace tool few programs that use UDP on my Linux boxes: unbound resolver, ntpd, openvpn. None seems to use it.

MSG_PEEK This flag causes the receive operation to return data from the beginning of the receive queue without removing that data from the queue. Thus, a subsequent receive call will return the same data.

I've managed to find one case, the net-snmp package uses MSG_PEEK in the SMUX subagent system, heaven knows why. But since the smux socket is practically always bound to localhost, that is not a problem.

As far as I can tell, a packet from a non-localhost source may be received, but (obviously) the udp_recvmsg does not get called since the system call is not triggered.

Unfortunately, there is a large amount of devices such as home routers, televisions, phones, etc, that are completely impossible to update. So, being aware of cases of software that actually use MSG_PEEK might be useful.

How do you know it is rarely used? Besides 'rarely' is only slightly better than 'commonly' in this case.

I really wish these announcements would come with a short check to see if you're affected and some example code to test if you're vulnerable.

Does anyone know of a simple check to see if your server is affected?

MSG_PEEK is a pretty obscure feature. I'm not personally aware of any commonly-run UDP code that actually uses it. You'll want to patch your kernel for sure, but unless you're running really crazy UDP servers, you're probably not immediately vulnerable.

> MSG_PEEK is a pretty obscure feature. I'm not personally aware of any commonly-run UDP code that actually uses it. You'll want to patch your kernel for sure, but unless you're running really crazy UDP servers, you're probably not immediately vulnerable.

Or unless you have untrusted users on your machine, in which case they can run crazy UDP servers and escalate to root.

Yes, which is an important point: this serves as a local root escalation to any process which can open a UDP socket.

What about UDP clients? I don't see anything in the CVE to suggest a client vs server distinction in terms of (mis-)behavior.

Clients[1] are absolutely vulnerable too. But again, I'm not aware of any code that actually uses MSG_PEEK.

[1] Really, there isn't any distinction at the kernel level between a UDP "client" and "server". It's the same set of syscalls being used on both sides, the difference is just who speaks first.

Ubuntu 14 LTS Current kernel is 3.13.0-116-generic and issue was fixed in released (3.13.0-79.123)- so NOT AFFECTED

Ubuntu 12 LTS Current kernel is 3.2.0-118-generic and fixed in released (3.2.0-99.139) - so NOT AFFECTED

It seems [1] recent kernels are not affected by this. So if you are running older (hopefully lts kernels), you might need to verify them, otherwise you should be fine (check back with your distro obviously).

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Correction: ALL production OS and kernels are affected.

"udp.c in the Linux kernel before 4.5 allows remote attackers to execute arbitrary code via UDP traffic [...]"

There is barely any OS that are >= 4.5 (only CoreOS on the top of my head).

This doesn't seem true from the commit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

The bug is said to not be exploitable since Al Viro function change. This change happened in 3.19.

The problematic patch only seems to be introduced in mainline 4.2, not 3.19, compare:




I am just trying to completely understand the bug, I wonder if it really was unexploitable before the patch. Got any source for that?

EDIT: sorry, misunderstood your message / mixed up commits, I was looking into when 89c22d8c3b27 hit mainline, which causes the vulnerable code path.

Why "problematic"? The Al Viro change mentioned in the fix is https://github.com/torvalds/linux/commit/227158db160449b6513.... The commit says this makes the bug not exploitable since the new helper function handles correctly the edge case. The fix still needs to be applied to avoid computing the checksum twice.

Is it confirmed that kernels before 3.19 are safe?

Huh? I'm running Arch Linux on kernel 4.8 (latest in repos is 4.10). Ubuntu 16.10 has kernel 4.8.

Servers are usually on LTS versions. Ubuntu 16.04 is on 4.4 last time I checked. My Android 7.0 phone is on 3.10.84, last updated in February.

Edit: Ubuntu's tracker is at https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2...

Patches from upstream are regularly backported by distribution vendors, including Redhat, Debian, Ubuntu (though I don't know if Ubuntu do this themselves or base on Debian). Anyway, looking at the version number is not enough, you should refer your vendor security advisories.

> Correction: ALL production OS and kernels are affected.

No, ALL production OS backport security patches to their kernels. This bug was fixed in Debian 15 months ago and Debian stable kernel is way older than 4.5.

> "udp.c in the Linux kernel before 4.5 allows remote attackers to execute arbitrary code via UDP traffic [...]" > There is barely any OS that are >= 4.5 (only CoreOS on the top of my head).

Kernel version is meaningless, see above.

Arch is on 4.10.9

Yes but arch is not a serious production/server os. Although some of you may do it.

Most servers/business run on (not the latest) redhat/suse/debian/ubuntu and derivates. They dont have kernel versions that recent.

That just goes to show that Ubuntu and friends are not serious production OS. In what world is extended vulnerability to months-old bugs a legitimate prerequisite for production viability?

which is not really cool I mean I at least need to check two kernels:

- Linux git 4.4.0-72-generic #93-Ubuntu SMP Fri Mar 31 14:07:41 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux (Ubuntu 16.04, but I can probably switch to HWE) - Linux censored 3.10.0-514.6.1.el7.x86_64 #1 SMP Wed Jan 18 13:06:36 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux (CentOS 7.3.1611)

not really cool :/

happily I have no udp traffic and the AWS/internal firewall blocks all udp traffic by default.

The wording makes it sound like Hertbleed/Cloudbleed level vulnerability.

I mean impact wise, all those routers and cameras got another attack vector?

This would make heartbleed and similar look like childsplay - this is a worm level attack if it's as bad as the title sounds.

But given that redhat has so far labelled themselves not vulnerable, I'm guessing there's more to it than the title lets on.

What does worm level mean? I heard it in relation to heartbleed [or something] but couldn't figure out why it's worse than non-wormable.

By worm level I mean it's a remote code execution attack which can be propagated over the internet.

Someone can write a little piece of code that scans for random hosts, runs the attack and installs itself on the target system which then does the same until it's taken over all vulnerable hosts. It can self-replicate extremely fast.

This was a huge issue back in the Blaster/Sasser days of early Windows XP when plugging in a machine to the internet directly was common.

Servers and home routers are often plugged into the internet directly and often run Linux. So if this is easily exploitable it could turn into a real disaster.

Heartbleed can't be turned into a worm because there's no code execution, just information disclosure, with this there is.

Worms are viruses that worm their way in to connected computers through the network without any action on the user's part, and then use newly-infected computers to worm through to others.

Unlike many other viruses, you don't have to visit a page that runs an exploit, download a trojan, open an attachment, or do anything else to trigger it. Any computer that can contact the exploitable service can infect you (and will, if it has the worm too).

"Worm-level" would call back to classic worm attacks where any computer connected to the internet and running Windows 2000/XP was at real risk of infection just by being connected. LAN/corporate networks could be infected if someone plugged an infected computer into the LAN, or if it spread through the DMZ.

This type of attack doesn't happen very often anymore, as almost all home connections are firewalled by default, vendors have become more careful with security, etc.

From what I can tell this is a local privilege escalation bug, not a "worm level" attack.

This vulnerability has already been disclosed and fixed in mainline, upstream longterm releases and major distribution kernels last year, I don't understand why it made the news today, am I missing something, is it slow news day or is it fear mongering?

I flagged the thread because it is harmful (or time waster at best). From the comments I can see people are worried and unknowingly wasting their time checking their kernels to see if they are affected from a vulnerability that has already been fixed more than a year ago. Damn, I wasted half an hour of my time to see what really the situation is about.

Android patches were released a week or so ago that fixed this vulnerability. [https://source.android.com/security/bulletin/2017-04-01] That probably explains why it is bubbling up now. Many phones and routers will remain unpatched.

The CVE was marked as highly critical and the kernel patche comments are vague at best as to the risks.

The issue is not with this being on HN, the issue is with the lack of clarity about the scope and severity of the vulnerability.

Does anyone have an explanation for how this exploit works?

You're not the only one confused here. Tavis isn't sure what's going on either:


Why is this bubbling up again?

this is soo confusing...

Applications are open for YC Winter 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact