161–170 of 218 posts
Seems to be fixed by this commit (in 4.8.3). commit 89eeba1594ac641a30b91942961e80fae978f839 Author: Linus Torvalds Date: Thu Oct 13 13:07:36 2016 -0700 mm: remove gup_flags FOLL_WRITE games from __get_user_pages() commit 19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619 upstream. This is an ancient bug that was actually attempted to be fixed once (badly) by me eleven years ago in commit 4ceb5db9757a ("Fix get_user_pages() ra…
So it's been a known bug for 11 years? That sounds like a pretty serious issue with the QA and or bug tracking process.
So the escalation is rw access to privileged files, are LXC and Docker container breakouts prevented then? Also does /proc access through lxcfs or Docker's handling of /proc make any difference?
Theoretically, no. LXC or docker will not help against this. Not even against this particular exploit seen in the wild, but that could be mitigated with lxc (maybe docker), partically lxc.container.conf you can set seccomp to drop ptrace syscall which this wild exploit depends on. Here, it really is a difference between VM and container though.
Earlier quoted context omitted.
10% small TCB size vs 100% of the complete code. Which one will a security minded person pick?
Sorry, can you restate that question? I'm not sure what you're asking.
C, due to arrays, strings, arithmetic operations and memory allocations requiring unsafe code leads to 100% unsafe code across the existing code.
A security minded person will pick those 10%.
Earlier quoted context omitted.
So it's been a known bug for 11 years? That sounds like a pretty serious issue with the QA and or bug tracking process.
Linux developers don't believe in security vulnerabilities: https://news.ycombinator.com/item?id=2539839
At Appcanary, we're thinking about opening up our vulnerability database to be browsable and searchable by the public. If you're not sure which version has the patch for this vulnerability in your distro, here's what we know: Ubuntu - https://appcanary.com/vulns/45984 Debian - https://appcanary.com/vulns/45983 Amazon Linux - https://appcanary.com/vulns/45992 Centos - no patch yet If you found this useful, please let…
They really need a lot of work.
Earlier quoted context omitted.
It seems like both SELinux and AppArmor could be configured to block access to /proc/self/mem which should mitigate it.
It's sad actually that this is the perfect type of exploit to block with SElinux, a simple write to unauthorized files. But since no one uses the user contexts of selinux then no one blocks this. Your shell runs unconfined because your user role is unconfined. Any process you might start will therefore run unconfined, unless stated otherwise in a policy. So this exploit will run unconfined and will be allowed writes…
Just to clarify this, any process you start from the shell. Like the PoC exploit.
But in an actual scenario, if the exploit were launched from Firefox, or Nginx, it would run under a confined context and be prevented from overwriting most critical system files.
Doesn't seem like it works on a $10 DigitalOcean droplet (1 vCPU) with grsec-patched 4.4.8. After running for quite some time (which I suspect a system administrator would notice) "cat foo" still outputs the same contents.
Earlier quoted context omitted.
Note the "HWE" (hardware enablement) on that chart. Ubuntu 14.04 came with 3.13; if you want a 4.4 kernel, you have to install linux-generic-lts-xenial.
Thanks, that answers my question! Installing linux-generic-lts-xenial should let me get the 4.4.x kernel on Ubuntu 14.04. I might still switch to Arch Linux. It's been a hassle to get the latest releases of various packages (like python, gcc, etc). I've had to use third-party PPAs or manually install them. Ubuntu's freezing of packages makes it great as a base image for Docker containers and other reliably reproducib…