Earlier quoted context omitted.
Linux developers don't believe in security vulnerabilities: https://news.ycombinator.com/item?id=2539839
First you gotta tell me what do you think I'm saying > Linux developers don't believe in security vulnerabilities
“Most serious” Linux privilege-escalation bug ever is under active exploit
181–190 of 218 posts
Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#182Earlier quoted context omitted.
The link doesn't say what you say it does. It says that Linus thinks that security researchers want to put security at the expense of usability, which is a different thing entirely.
That, and that a bug is a bug is a bug. Any bug can potentially be a security vulnerability with the right approach. Thus putting people that find such bugs on a pedestal is counterproductive.
Anyone who's actually operating Linux cares about security vulnerabilities more.
Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#183Cool, this will be great for rooting Android phones to fix this and other security bugs!
It's sad that anyone should have to rely on security bugs to take ownership of their own phone...
These phones exist, because people are buying them.
Other phones that allow unlocking the bootloader also exist.
Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#184Earlier quoted context omitted.
I'm confused, how is SSH an example of defense in depth? It is an access method. You should absolutely harden your SSH configuration. Fail2Ban is useless on a properly configured SSH server (no root, no passwords, no kerberos, only keys). Managing the keys at scale, well that is a different story. I agree with you that ASLR, NX, and CFI are the most important system level defenses to employ.
SSH is fine. Stacking extra stuff on top of SSH to create a defense-in-depth stack for it SSH is what's silly. Just disable passwords and use SSH.
Not entirely reasonable for all use cases. If there's a machine that you need access to from many different locations, a keyfile is more of a PITA than a long passphrase.
Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#185Earlier 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…
Err.. what about running SEL in permissive mode? The process works, and you'll get a nice log file filled with what would have gotten blocked.
It's invaluable in setting up new policies.
Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#186Earlier quoted context omitted.
it's definitely a joke. everything in the store is overpriced, FAQ item "how can I uninstall linux" links to a video of a guy smashing a computer, etc. look at this FAQ item: 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…
Definitely not funny for all the admins that had an emergency task to handle. This site needs some good updating.
Yeah, agreed. This page is coming up on google searches now, and the first hit is something that downplays its seriousness in the name of meta-snark.
Very irresponsible on the part of the author. There's a time and a place for humor - this isn't it.
Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#187Earlier quoted context omitted.
That, and that a bug is a bug is a bug. Any bug can potentially be a security vulnerability with the right approach. Thus putting people that find such bugs on a pedestal is counterproductive.
Anyone who's actually operating Linux cares about security vulnerabilities more.
Exactly which bugs are those? Linus makes valid points that people then seem to ignore and change the meaning of.
He thinks all bugs need fixing and how they are described is unimportant. Fixing the bugs is more important than how they are categorized.
Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#188I wish someone could explain in simpler terms to us casual users what this means.
If only privileged users can SSH into my server, does this really affect me? In other words, I already allow only SSH users to become root.
Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#189CVE-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…
Man, MADV_DONTNEED again? I mean, Linux's implementation is already weird (it behaves in a way counter to most other implementations of the call: you can see Bryan Cantrill's talk for the details). What is with that call?
I don't think you need madvise() for this bug. It's just easier to exploit that way.
Re: “Most serious” Linux privilege-escalation bug ever is under active exploit
#190Can someone help me better understand how this works, or perhaps point me to a decent article explaining more of the details? Most of the articles I can find just briefly explain the exploit, but not really how it works (in detail).
From looking at the example code, it seems like the general process is:
- Open some (normally un-writable) file as read-only and mmap it in to your process.
- Kick off two threads. One thread to repeatedly write to the same mmap-ed address via /proc/PID/mem and another thread to keep issuing the madvise call.
- Wait for some race condition to be (un)satisfied such that you're able to write to a cached copy of the file.
What I don’t fully understand is how the /proc/PID/mem thing works.
Here’s what I’m curious about:
1. What would happen if you tried to write to the mmap-ed region directly? Since it’s been mapped in with “PROT_READ”, does this mean that you’ll get a segmentation fault or something? From the manpage, it seems like “MAP_PRIVATE” allows it to be a COW mapping, but I don’t see how the combination of “PROT_READ” and “MAP_PRIVATE” is even valid. Unless this means that any writes to data copied from the mmap-ed region into other buffers will be COW-ed and that you can’t actually write to the mmap-ed region itself? That would make sense to me.
2.How is writing to /proc/PID/mem any different than writing through the mmap-ed region directly? Assume that you weren’t running the madvice thread. What would happen then if you tried to write to the /proc/PID/mem file? Presumably the same thing that happens if you just tried to write to the file directly…
3. Finally, how does the madvice call cause a race condition? I realize this might be a little too much to cover in a comment, but this seems like the meat of it.