[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
"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.
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.
- 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.
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?
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.
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.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
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 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.
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.
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.
Ubuntu 12 LTS Current kernel is 3.2.0-118-generic and fixed in released (3.2.0-99.139) - so NOT AFFECTED
