41–50 of 218 posts
Interesting whether it will give new root exploits for Android as suggested in the comments.
CVE-2016-5195 This flaw allows an attacker with a local system account to modify on-disk binaries, bypassing the standard permission mechanisms that would prevent modification without an appropriate permission set. This is achieved by racing the madvise(MADV_DONTNEED) system call while having the page of the executable mmapped in memory. Excellent example why mounting partition with system binaries (such as /usr) rea…
If you want a secure system by default, you should probably not use Linux. I would go with OSX or OpenBSD to start.
(And finally: mounting /usr read-only isn't actually a security feature, because if you can exec code you can run a privesc and remount /usr read-write; mounting as noexec could arguably be considered a security feature)
It's probably the most serious Linux local privilege escalation ever. Look, the Azimuth people have forgotten more about reliable exploit development than I have ever known, but, no, as stated, this is clearly not true. Not long ago, pretty much all local privesc bugs were practically 100% reliable. What I think they mean to say is that this is unusually reliable for a kernel race. I still think, though, that the rig…
> 2. In almost all cases, whether or not there's a known local privesc bug, assume that code execution on your Linux systems equates to privesc; this is doubly true of machines in your prod deployment environment. I think this goes for any mainstream OS, Linux is not particularly special here.
It's probably the most serious Linux local privilege escalation ever. Look, the Azimuth people have forgotten more about reliable exploit development than I have ever known, but, no, as stated, this is clearly not true. Not long ago, pretty much all local privesc bugs were practically 100% reliable. What I think they mean to say is that this is unusually reliable for a kernel race. I still think, though, that the rig…
Well another thing to keep in mind with this one in particular is that there is no way to mitigate it. grsecurity can't help with this kind of bug, nothing can so it may not just be about reliability of this exploit but the fact that there's no mitigation other than to update.
CVE-2016-5195 This flaw allows an attacker with a local system account to modify on-disk binaries, bypassing the standard permission mechanisms that would prevent modification without an appropriate permission set. This is achieved by racing the madvise(MADV_DONTNEED) system call while having the page of the executable mmapped in memory. Excellent example why mounting partition with system binaries (such as /usr) rea…
Fwiw, you should never think about an OS in terms of what security features they have enabled by default. The OS is almost always designed to help the user use programs and to help programs run. Just assume it is not secure until you do an audit + lockdown yourself. If you want a secure system by default, you should probably not use Linux. I would go with OSX or OpenBSD to start. (And finally: mounting /usr read-only…
Earlier quoted context omitted.
Fwiw, you should never think about an OS in terms of what security features they have enabled by default. The OS is almost always designed to help the user use programs and to help programs run. Just assume it is not secure until you do an audit + lockdown yourself. If you want a secure system by default, you should probably not use Linux. I would go with OSX or OpenBSD to start. (And finally: mounting /usr read-only…
OSX? How is that more secure by default than Linux?
CVE-2016-5195 This flaw allows an attacker with a local system account to modify on-disk binaries, bypassing the standard permission mechanisms that would prevent modification without an appropriate permission set. This is achieved by racing the madvise(MADV_DONTNEED) system call while having the page of the executable mmapped in memory. Excellent example why mounting partition with system binaries (such as /usr) rea…
Fwiw, you should never think about an OS in terms of what security features they have enabled by default. The OS is almost always designed to help the user use programs and to help programs run. Just assume it is not secure until you do an audit + lockdown yourself. If you want a secure system by default, you should probably not use Linux. I would go with OSX or OpenBSD to start. (And finally: mounting /usr read-only…
Not really surprising since it's overwhelmingly used in practice as a single-user system.
See also the dedicated page for this vulnerability, dubbed Dirty COW (for copy-on-write), aka CVE-2016-5195: http://dirtycow.ninja/
Gotta love the dedication with the Dirty COW "swag" web shop and all. Though something tells to me it's just a strange in-joke. Might be the prices? ($1,000 for a mouse pad .. oh, really?)
What's with the stupid (logo|website|twitter|github account)?
It would have been fantastic to eschew this ridiculousness,
because we all make fun of branded vulnerabilities too, but
this was not the right time to make that stand. So we
created a website, an online shop, a twitter account, and
used a logo that a professional designer created.
Earlier quoted context omitted.
> "In almost all cases, whether or not there's a known local privesc bug, assume that code execution on your Linux systems equates to privesc; this is doubly true of machines in your prod deployment environment. It depends. I've seen "oh well if someone has rce they probably have root anyway" used way too many times as an excuse to avoid defense-in-depth measures.
Those people might be right. Defense in depth is a legitimate tactic, but that's all it is, and it's often an excuse for people to waste time layering stupid stuff on top of real security controls. ASLR, NX, and CFI would be an example of a defense in depth stack that is meaningful. SSH, Fail2Ban, and SPA would be an example of a defense in depth stack that basically just wastes time. I would be more comfortable with…
Earlier quoted context omitted.
>assume that code execution on your Linux systems equates to privesc Tell this to the container community. They would have you believe containers are as secure as VMs.
Citation needed. That's certainly a goal, but I've never heard the claim.