Highest impact is on Android: https://source.android.com/security/bulletin/2017-04-01
The debian web page at least lists the exact kernel version they ship where it is confirmed fixed.
> 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.
If so, what is a good firewall frontend for Android?
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.
Relevant Linus quote: "I personally consider security bugs to be just "normal bugs""
Does anyone know what crypto/bio/bss_dgram.c does?
I'd assume it's for use with DTLS, which is a less commonly used part of OpenSSL.
And probably more implicit
> udp.c in the Linux kernel before 4.5 allows remote attackers to execute arbitrary code via UDP traffic....
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 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.
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.
Does anyone know of a simple check to see if your server is affected?
Or unless you have untrusted users on your machine, in which case they can run crazy UDP servers and escalate to root.
 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 12 LTS
Current kernel is 3.2.0-118-generic and fixed in released (3.2.0-99.139) - so NOT 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).
The bug is said to not be exploitable since Al Viro function change. This change happened in 3.19.
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.
Edit: Ubuntu's tracker is at https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2...
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.
Most servers/business run on (not the latest) redhat/suse/debian/ubuntu and derivates. They dont have kernel versions that recent.
- 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.
Apparently xenial 4.4 is not affected.
I mean impact wise, all those routers and cameras got another attack vector?
But given that redhat has so far labelled themselves not vulnerable, I'm guessing there's more to it than the title lets on.
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.
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.
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.
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.