Recent Features
| |||||||||||||
Civilizing SELinuxCivilizing SELinuxPosted Nov 26, 2004 4:38 UTC (Fri) by spender (subscriber, #23067)In reply to: Civilizing SELinux by walters Parent article: Civilizing SELinux
When can we expect to see Fedora fix their information leaking glibc that makes arbitrary code execution trivial for suid apps?
How about a little less SELinux hype, and a little more time spent on understanding security? It's clear RedHat is more interested in buzzwords and making a mockery of people involved in real security research. The longer you continue your propoganda machine, telling your users that "crypto-signed modules stop rootkits" and "SELinux turns a potential system compromise into WORST CASE modified DNS replies," the more you are lulling them into a false sense of security.
Let's not tell the users about kernel exploits (which are more prevalent now than bugs in suid apps) or how easy it is to execute arbitrary code on a default fedora install, because our image as great pioneers in the field of security (which has amounted to cheap ripoffs of code present 3 years prior to RedHat ever entering the game) is much more important than the security of our users.
I've also wondered why RedHat is so unnecessarily anal on the side of access control to be using SELinux, but so overwhelming lax on the side of stopping exploits in the first place to be using Exec-Shield. This conflict is confusing to me, as it seems the latter is more important.
Immunity has exploits that work *reliably* against Fedora with Exec-Shield. Of course, as Immunity doesn't release exploits, your precious image won't be tainted, which is what you really care about, right? Want to bet that if someone were to send a mail to FD and Bugtraq demanding that Fedora fix their information leaking glibc that they've refused to fix for months now, it would be fixed? Why do you think that is? It's easy to blow off your security problems as long as they hide in your bug tracking system, outside of the view of the general public.
(Log in to post comments)
Civilizing SELinux Posted Nov 26, 2004 4:58 UTC (Fri) by bluefoxicy (guest, #25366) [Link] Want to bet that if someone were to send a mail to FD and Bugtraq demanding that Fedora fix their information leaking glibc that they've refused to fix for months now, it would be fixed? Brad, do us all a favor. You're pretty smart, you can map out these things and make a comprehensive report on what's wrong, why it's wrong, and why it needs to be fixed, right? Go do it. I'd really love Linux and hell my favorite distribution to carry the "security torch," and really want to see PaX and GR get the credit they deserve. SELinux and RSBAC are good too though; but I personally despise the hype SE gets, not because anything else is better or worse, but because a lot of people get just that-- hype. When you focus on ONE solution, you come up with a crowd that thinks it's a magic bullet that will mitigate everything else, sometimes even including patches. We went through the same kind of thing with firewalls. Norton Personal Firewall, Zone Alarm, Black Ice, all things people thought "would stop [crackers]" all by themselves. I wasn't around to see if they did the same thing with Antivirus software, though I imagine this "magic program that removes [cracker] programs will fix everything!!!" Most people still blame 100% of their problems on viruses. You need a diverse range of solutions: PaX, MAC, GRSec's kernel enhancements, SSP, firewalling, augment ClamAV with heuristics, use application proxy firewalls and firefox/thunderbird plug-ins to scan for malware in web pages and e-mail, etc. I'm not sure what my exact point is WRT this topic, but there's stuff relavent here I'm sure, since I kind of went all over the place.
Civilizing SELinux Posted Nov 26, 2004 5:22 UTC (Fri) by spender (subscriber, #23067) [Link] Here's the situation: We've filed the bug reports. We've shown that it leaks the base addresses for mmap randomization. It's plain as day to see: run the suid app with LD_DEBUG=all multiple times, and you'll see the library addresses, which will be different each time. Jakub Jelinek's reply has been that it "doesn't leak specific symbol addresses." I'm not sure he understands that if you have information about the mmap base, you can easily calculate a specific symbol address from it. We've shown him another environment variable that does leak specific addresses, and his only reply has been "maybe we should fix this." I've not seen a fix announced yet. That was months ago: they've released updated glibc packages since then not containing any of these fixes.
What do you do when the person in control of the code is too stupid and stubborn to fix his own bugs? Is it my job to hold the hand of this jerk who is too concerned with being a smart-ass to fix his own bugs?
Civilizing SELinux Posted Nov 26, 2004 5:52 UTC (Fri) by bluefoxicy (guest, #25366) [Link] If I can LD_DEBUG=all and run a program, I can find the libraries it uses and find the symbols at offsets, and calculate that. You are indeed correct about this. I also read that LAZY binding allows you to block STDOUT at critical points and exploit race conditions on infinite windows instead of milisecond-wide windows. I for one am glad that Gentoo has a dedicated security team that either creates or abducts any patches that fix ANY security concern, rather than wander around and go "huh that might not really be a problem maybe we shouldn't change it . . . ." bluefox@icebox ~/data/programming/woct $ LD_DEBUG=all su You said something about posting to BugTraq about some of these vulns. Has nobody done this? It may not be the best way to get in bed with them, but if there's a security issue that *needs* *to* *be* *fixed*, it may just be time to hit them in the face with the frying pan of reality. Then again, I don't know; I'm too busy playing FF8 to think about this right now.
|
|||||||||||||