5 ms·
In the article the author states: > CVE-2017-5123 was published earlier this year on Oct 12 — it was a Linux kernel vulnerability in the waitid() syscall for 4
by cirowrc 9y ago
In the article the author states:
> CVE-2017-5123 was published earlier this year on Oct 12 — it was a Linux kernel vulnerability in the waitid() syscall for 4.12-4.13 kernel versions.
Does this mean that kernel versions prior to 4.12 are not affected? That's what I understood from the related issue in the bug tracker https://bugzilla.redhat.com/show_bug.cgi?id=1500094 https://bugzilla.redhat.com/show_bug.cgi?id=1500094
By the way, this is very important:
> In 2017 alone, 434 linux kernel exploits where found, and as you have seen in this post, kernel exploits can be devastating for containerized environments. This is because containers share the same kernel as the host, thus trusting the built-in protection mechanisms alone isn’t sufficient. Make sure your kernel is always updated on all of your production hosts.
Great article!
- Da5hes 9y agothat's correct, versions prior to 4.12 are not affected
- userbinator 9y agoThis is 4.11: https://elixir.free-electrons.com/linux/v4.11/source/kernel/exit.c https://elixir.free-electrons.com/linux/v4.11/source/kernel/... The code is significantly different but I still see a lack of access_ok(), so was the checking performed somewhere else that I didn't notice (I haven't looked closely at this part of the kernel before)?
- Da5hes 9y agoit is the use of unsafe_put_user without access_ok(), not access_ok() alone
- icebraining 9y agoIIUC, you only need the access_ok() when using the new unsafe_put_user(). That code is still using put_user().
- deleted 9y ago[deleted]
- TheDong 9y agoThat range isn't quite correct. It only impacted 4.13 kernels, and only 4.13.0-4.13.6 (inclusive, distro-dependent due to backports). It was patched in 4.13.7 after being introduced in the 4.13.0 merge window. See https://lwn.net/Articles/736348/ https://lwn.net/Articles/736348/ This issue shouldn't have happened at all, but it was caught and patched very quickly, so relatively few real-world systems are or were affected.
- cirowrc 9y agoThanks!
- Da5hes 9y agoit was introduced by this commmit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4c48abe91be03d191d0c20cc755877da2cb35622 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... which by itself is in a 4.12 vanilla code tree
- TheDong 9y agoThat commit is correct (4c48abe91be03d191d0c20cc755877da2cb35622), but it was not in 4.12 as cut by linus. https://github.com/torvalds/linux/commit/4c48abe91be03d191d0c20cc755877da2cb35622 https://github.com/torvalds/linux/commit/4c48abe91be03d191d0... (click the little '...' to expand tags it's in) or: $ git tag --contains 4c48abe91be03d191d0c20cc755877da2cb35622 v4.13 What is your methodology that gets that it is in the 4.12 tree?
- Da5hes 9y agoyou are right, i actually didn't check on git, my bad
- benevol 9y ago> Make sure your kernel is always updated on all of your production hosts. And in order to avoid any zero-day exploits, always use dedicated machines, never use a VPS server.
- oblio 9y agoI'm not sure I get this - are you saying that you are more at risk due to the VM host layer?
- openasocket 9y agoPersonally, I'd reasonably trust Xen or KVM or something else with hardware-based virtualization and the like to protect me in an multi-tenancy scenario. Much less so in the case of Docker. Sharing a full kernel with potentially malicious actors is more risky than sharing a hypervisor, much more surface area for attack.