
Udp.c in Linux kernel pre-4.5 allows remote attackers to execute arbitrary code - OrangeTux
https://nvd.nist.gov/vuln/detail/CVE-2016-10229#vulnDescriptionTitle
======
cyann
Red Hat (RHEL 5/6/7) not affected:
[https://access.redhat.com/security/cve/CVE-2016-10229](https://access.redhat.com/security/cve/CVE-2016-10229)

Highest impact is on Android:
[https://source.android.com/security/bulletin/2017-04-01](https://source.android.com/security/bulletin/2017-04-01)

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

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

~~~
mnw21cam
That statement has been subsequently added. And yes.

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

[https://access.redhat.com/security/cve/cve-2016-10229](https://access.redhat.com/security/cve/cve-2016-10229)

[https://security-tracker.debian.org/tracker/CVE-2016-10229](https://security-
tracker.debian.org/tracker/CVE-2016-10229)

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

[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=197c949e7798fbf28cfadc69d9ca0c2abbf93191)

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

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

~~~
hdhzy
Sometimes even one character can make a lot of difference:
[https://en.wikipedia.org/wiki/Mariner_1#.22The_most_expensiv...](https://en.wikipedia.org/wiki/Mariner_1#.22The_most_expensive_hyphen_in_history.22)

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

~~~
kuizu
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?

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

~~~
pjc50
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_.

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

[https://codesearch.debian.net/search?q=recvfrom+.*+MSG_PEEK](https://codesearch.debian.net/search?q=recvfrom+.*+MSG_PEEK)

And probably more implicit

[https://codesearch.debian.net/search?q=recv+.*+MSG_PEEK](https://codesearch.debian.net/search?q=recv+.*+MSG_PEEK)

~~~
ryan-c
The use in wget seems a little scary.

------
abetusk
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?

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

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

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

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

------
bipson
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...](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=197c949e7798fbf28cfadc69d9ca0c2abbf93191)

~~~
user5994461
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).

~~~
vbernat
This doesn't seem true from the commit:
[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=197c949e7798fbf28cfadc69d9ca0c2abbf93191)

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

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

[http://lxr.free-
electrons.com/source/net/core/datagram.c?v=3...](http://lxr.free-
electrons.com/source/net/core/datagram.c?v=3.19#L645)

[http://lxr.free-
electrons.com/source/net/core/datagram.c?v=4...](http://lxr.free-
electrons.com/source/net/core/datagram.c?v=4.1#L645)

[http://lxr.free-
electrons.com/source/net/core/datagram.c?v=4...](http://lxr.free-
electrons.com/source/net/core/datagram.c?v=4.2#L682)

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.

~~~
vbernat
Why "problematic"? The Al Viro change mentioned in the fix is
[https://github.com/torvalds/linux/commit/227158db160449b6513...](https://github.com/torvalds/linux/commit/227158db160449b6513d2e31894a135104b90e90).
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.

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

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

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

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

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

~~~
baq
The original worm:
[https://en.m.wikipedia.org/wiki/Morris_worm](https://en.m.wikipedia.org/wiki/Morris_worm)

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

~~~
matheweis
Android patches were released a week or so ago that fixed this vulnerability.
[[https://source.android.com/security/bulletin/2017-04-01](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.

------
Meegul
Does anyone have an explanation for how this exploit works?

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

[https://twitter.com/taviso/status/852571815079591936](https://twitter.com/taviso/status/852571815079591936)

------
dom0
Why is this bubbling up again?

------
BiohaZd
this is soo confusing...

