Linux, patches, and trust

Discussion in 'all things UNIX' started by Gullible Jones, May 16, 2013.

Thread Status:
Not open for further replies.
  1. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,466
    So far, we've seen cases where Linux kernel developers have:
    - suppressed news of security holes
    - failed to notify the public when said holes were fixed
    - miscategorized arbitrary code execution bugs as "possible denial of service" (repeatedly)

    How much of this has to happen before people start considering Linux untrustworthy for servers? Even if serious vulnerabilities are infrequent, this "method" of handling them makes for serious trust issues IMO.

    I'm not even certain that I would consider a GrSecurity kernel trustworthy. The GrSec team may be more responsible, but they can't audit everything AFAIK; and if the kernel devs continue to drop the ball, how can a GrSec patched kernel be consider trustworthy either? GrSec can mitigate the impact of a lot of vulnerabilities, but not all of them.

    How is this not a huge problem?
     
  2. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    It is a huge issue. And it's killing Linux security, especially for servers.

    These silent fixes you're referring to tend to follow patterns. Spender notices them often, and even when he doesn't, the fixes get backported to the supported Grsec kernels.

    Grsecurity deals with entire classes of vulnerabilities. So even if a few slip through, that's fine, we make that assumption anyways.

    Look at this latest kernel local vuln, it was a near arbitrary write allowing for full SELinux bypass and control of kernel execution flow. Grsecurity stops it three separate ways, at the very least.

    Also, the Linux kernel may have shittier devs when it comes to this, but it has more support for security features. Seccomp (one of those nice features) reduces kernel attack surface, so I'm not sure (haven't checked) that this latest vuln could even be run from Chrome or other seccomp enabled processes, even on a vulnerable kernel.

    It hurts security when Linus and Greg say moronic statements that have been disproved in the 1800's, but it's an open project, and people like Spender keep an eye out.
     
  3. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,466
    Perhaps... I'm not sure I buy the idea that a project using insecure maintenance methodologies can ever be molded into a secure product, even with the help of experts like Spengler. It's awesome that GrSec blocks that vulnerability three ways, but that might not be the case the next time, or the next... It would be better not to have the vulnerability present for two years, and then patched without notice, in the first place.

    Exploit mitigation is great to have, but I feel that proper maintenance is vital. One cannot rely on exploit mitigation, even as good as GrSec, as a substitute for good maintenance IMHO.

    Completely nonexpert opinion there BTW. But still.

    (I suppose this is where Rutkowska and company get the whole security-through-isolation thing. The hypervisor is tiny, it can be trusted; the OS is huge and badly maintained, it can't be trusted. Let the trustworthy part handle the security, instead of the buggy bloated OS. Still far from an ideal solution though.)

    Edit: I guess my take is that a buggy but well maintained and swiftly patched code base (Windows) may be superior in a lot of situations to a less buggy but poorly maintained one (GNU/Linux).
     
  4. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    It very often is. In cases where there's completely arbitrary read/writes or design issues, it gets tougher. But there are preventative measures.

    And Spender, among others, puts pressure on the kernel developers to not be so shitty. When silent fixes happen they out it on LKM, etc. People are currently to stupid to listen.

    Also keep in mind that plugins like the Size Overflow plugin will take out entire classes of overflows - kill the bugs dead, straight out. Constifying pointers also reduces kernel attack surface.

    I'm not confident in hypervisor solutions yet. Ideally we'll see seccomp become more popular. I'm considering Gentoo as a project, just because I can compile seccomp filters into whatever program I like.
     
  5. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,466
    I'll admit I'm still pretty dubious. OTOH it's not like I'm going to switch to something other than Linux... The operating system is too convenient to part with, in spite of the sloppy maintenance.

    Bromium (IIRC kind of like Deep Freeze, but hypervisor based) has apparently proved pretty sturdy in independent tests. With Qubes, I'm more concerned about their leaving the user to apply isolation (mostly) manually, which seems like a dumb idea for non-ubergeeks.

    Re Gentoo, I didn't know one could do that with seccomp filters. I'd give it a try but I frankly don't feel like spending time configuring Gentoo. Also seccomp seems like kludge city to me. The kernel should not need system call filtering, it should be secure by default.

    I vaguely wonder if a microkernel OS of some sort, with sandboxing enforced by the microkernel alone, might be a sensible answer. Tanenbaum might yet have the last laugh.
     
  6. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    I think Bromium is more impressive than Qubes, it just doesn't seem like the "final" solution to me. It's more interesting than the other dull **** I see coming out once in a while, the same old boring AV or HIPS software that fails time and time again.

    Yes, the seccomp filters have a complain mode, so you can just log the system calls and then recompile with your new list.

    It's not one or the other, thankfully. Reducing attack surface is critical, though. Same with userland applications - separating them is a great way to secure the system.

    Only to the extent that it will reduce kernel attack surface. But I think the seccomp filter approach is simpler, and easier - no major changes to the kernel are necessary, no massive architectural changes, purely a limitation on programs.
     
  7. NGRhodes

    NGRhodes Registered Member

    Joined:
    Jun 23, 2003
    Posts:
    2,381
    Location:
    West Yorkshire, UK
    Which comments are these ?
     
  8. NGRhodes

    NGRhodes Registered Member

    Joined:
    Jun 23, 2003
    Posts:
    2,381
    Location:
    West Yorkshire, UK
    Our experience is that there are no problems Linux security.
    I don't think the generally Linux development model is insecure (even Linus states takes security seriously, and has stated fast fixing and suitable disclosure is his policy).

    If Windows is buggy, it's because it is poorly maintained and there is no evidence of it being patched any faster than linux.

    Cheers, Nick
     
  9. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,466
    No problems in Linux security? IIRC there are quite a lot of compromised Linux servers out there. Heck, kernel.org got hacked at one point. Re what Torvalds says, that's all well and good, the question is why it isn't done in some cases.

    Fair enough, I'm not a software engineer. :)

    It'd be interesting to know the mean duration of kernel holes on Linux vs. Windows though. There are some kernel bugs on Linux that have been around for an awfully long time. Likewise with Windows.
     
  10. Wild Hunter

    Wild Hunter Former Poster

    Joined:
    Oct 13, 2012
    Posts:
    1,375
    Linux trailed Windows in patching zero-days in 2012, report says

    Summary: Zero-day flaws in the Linux kernel patched last year took on average more than two years to fix, twice as long as it took to fix those affecting current Windows OS, a report by security researchers has found.
     
  11. NGRhodes

    NGRhodes Registered Member

    Joined:
    Jun 23, 2003
    Posts:
    2,381
    Location:
    West Yorkshire, UK

    Just because there are compromised Linux servers does not mean that is a problem with the kernel (as you still need to be able to get remote access somehow to exploit the kernel), could well be down to the software running or configuration flaunting security best practices (like lots of shared php servers) or even because they are not fully updated ?
    Just because kernel.org got hacked once does not mean there is a general issue with security.

    IMHO this is the right question to ask.
     
    Last edited: May 17, 2013
  12. NGRhodes

    NGRhodes Registered Member

    Joined:
    Jun 23, 2003
    Posts:
    2,381
    Location:
    West Yorkshire, UK
    Sorry, but that is a very poor example.
    Averages based on 2 hand picked examples for each, far from a balanced report !
     
  13. Wild Hunter

    Wild Hunter Former Poster

    Joined:
    Oct 13, 2012
    Posts:
    1,375
    Those were the only ones that qualified as "zero days" according to the criteria adopted by the report.
     
  14. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    I wish I'd responded when I had them on hand. They had to do with Linus saying that open disclosure will "just help script kiddies" and it basically supports his and his teams silent disclosure policy that has led to multiple vulns persisting across multiple versions. There's a new discovery of a silently patched vuln all of the time, you can find them on Spender's @Grsecurity twitter account.

    There are significant issues with how disclosure is handled, how security is approached, and the security community has been screaming at Linux devs for years. http://en.wikipedia.org/wiki/Pwnie_Awards (2008 2009, bug is a bug, etc)

    I would look a bit harder then.
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.