141–150 of 218 posts
The github page [0] states that "The In The Wild exploit relied on using ptrace." Now, I'm wondering what purpose ptrace serves, aside from debuggers? Why don't we just disable this by default on production systems (where you shouldn't be debugging anyhow)? [0] https://github.com/dirtycow/dirtycow.github.io/wiki/Vulnerab...
Cool, this will be great for rooting Android phones to fix this and other security bugs!
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?
Here, it really is a difference between VM and container though.
Curious that the original commit's hash to fix this was never indexed by Google: https://www.google.com/search?q=f33ea7f404e5&ie=utf-8&oe=utf...
Curious that the original commit's hash to fix this was never indexed by Google: https://www.google.com/search?q=f33ea7f404e5&ie=utf-8&oe=utf...
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.
The github page [0] states that "The In The Wild exploit relied on using ptrace." Now, I'm wondering what purpose ptrace serves, aside from debuggers? Why don't we just disable this by default on production systems (where you shouldn't be debugging anyhow)? [0] https://github.com/dirtycow/dirtycow.github.io/wiki/Vulnerab...
I'm not sure about this. Ideally, yes, but if you don't know what's causing an issue it can be difficult to reproduce it, and strace can be phenomenally helpful in figuring out the cause. Of course, you could leave it off until you think you might be in such a situation.
Earlier quoted context omitted.
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…
> 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. I am actually surprised that sane and safe defaults are ignored and left to user's discretion. Most users think Linux is secure by default. It's interesting to see Windows going into other direction and locking down more and more by default.
The scale is so high, that kernel security has become a major discussion subject.
http://arstechnica.com/security/2016/09/linux-kernel-securit...
Earlier quoted context omitted.
https://github.com/dirtycow/dirtycow.github.io/wiki/Vulnerab... and scroll up a bit. If you have an iPhone you can scroll horizontally even if it doesn't look like you can (though I am also annoyed by HN truncating the text)
The solution is for people to stop using blockquote formatting for text and reserve it for it's intended puprose of quoting code and retaining formatting.
Earlier quoted context omitted.
https://github.com/dirtycow/dirtycow.github.io/wiki/Vulnerab... and scroll up a bit. If you have an iPhone you can scroll horizontally even if it doesn't look like you can (though I am also annoyed by HN truncating the text)
It's not that you can't scroll, it's just very tedious to scroll back and forth each and every line.