RE: [suse-security] Will SuSE support stack smashing protection one day?
Er, a vulnerablility that hasn't been discovered isn't a danger to anyone > and doesn't need protecting against! I'm not sure what you mean to say here.
I would sure hope that this is NOT the views of the Novell/SuSE team...
Not that many I suspect. SSP is unlikely to make a vulnerability unexploitable, just harder to exploit. If I were penetration testing a
machine I knew to be using SSP I'd just craft my exploit accordingly. Sometimes SSP/Stackguard/Stackshield/et al make it impossible to exploit a vulnerability, but that is far from guaranteed. More likely the attacker just needs to try harder.
You appear to be under the impression that these sorts of tools offer genuine protection. They don't. They sometimes downgrade a code execution exploit into a denial of service (because the "protected" program will
still crash when its buffer is overflowed), but in general they just force the attacker to work harder.
But when dealing with script kiddies, any delay or difficulties you can cause very well may make the difference. In general, anything that one can do to increase the security of an information system under their control is a good thing. And any tools the vendors can provide us only helps to increase the security posture of our systems. Downgrading a local / remote compromise (or code execution exploit) to a denial of service is a great step forward. It could mean the difference of joe hacker crashing your system or having your shadow file - which would you prefer? I personally would prefer that my system be crashed than having to deal with a security incident.
On Wednesday 29 December 2004 17:07, James M. Patton wrote:
But when dealing with script kiddies, any delay or difficulties you can cause very well may make the difference. In general, anything that one can do to increase the security of an information system under their control is a good thing. And any tools the vendors can provide us only helps to increase the security posture of our systems.
Exactly. And doubting the use of such tools would be like saying "why using a seatbelt, at 150 km/h it doesn't save me anyway"...
Downgrading a local / remote compromise (or code execution exploit) to a denial of service is a great step forward. It could mean the difference of joe hacker crashing your system or having your shadow file - which would you prefer? I personally would prefer that my system be crashed than having to deal with a security incident.
ACK. It's nice to see they're working on at according to Thomas.
Hi! Another way to secure a system is to use role based access control on kernel-basis: http://grsecurity.org/ Before anybody says a word to this have a look at it before giving any argumentation against it. This is done with capabilities (like on SuSE with compardment) and some other techniques (it's a kind of "distribution" of multiple kernelpatches including an iptables-patch and even sone stack-protections - look at the link "features"). Capabilities set accessrights on kernel-basis (role based access control uses this technique based on rulesets). Is a right removed nobody can unset it, even as root. This means e.g. editing of a file or opening of a socket is only allowed to what is setup in the rules. O.K. SSP or stackoverflow protection is a nice feature but easy to be bypassed. AFAIK every security setup can be bypassed, because all code is written as a software and software will ever be exploitable. Role based access control gives you extra security and stackoverflow protection gives you some more security. The price you have to pay is, that the administration of such a system is more difficult and error searching will be more complicated (especiall if you develope whatever software under such a system). Notice: This software needs much investigation in how to setup it. The config always depends on the filelocation which is unique in every distribution. If you don't know what you need to do, you shouldn't use this. A false setup may alter your system and lock you out without any access to anything. If you want to gain the whole benefits you always need the newest patches for it. Reguards Philippe P.S.: As was said it isn't a must-have-feature and "should" be included as a bonus package. Everybody has his own idea of how to setup a system and this is not a must-have. It would be nice, if someday someone at SuSE includes this software into their distribution (as an optional feature).
On Wednesday 29 December 2004 11:07, James M. Patton wrote:
Er, a vulnerablility that hasn't been discovered isn't a danger to
anyone > and doesn't need protecting against! I'm not sure what you mean to say
here.
Mail interface giving you shit huh ;)
I would sure hope that this is NOT the views of the Novell/SuSE team...
Obviously not.....
Not that many I suspect. SSP is unlikely to make a vulnerability unexploitable, just harder to exploit. If I were penetration testing a
machine I knew to be using SSP I'd just craft my exploit accordingly. Sometimes SSP/Stackguard/Stackshield/et al make it impossible to
exploit a
vulnerability, but that is far from guaranteed. More likely the
attacker
just needs to try harder.
You appear to be under the impression that these sorts of tools offer genuine protection. They don't. They sometimes downgrade a code
execution
exploit into a denial of service (because the "protected" program will
still crash when its buffer is overflowed), but in general they just
force
the attacker to work harder.
But when dealing with script kiddies, any delay or difficulties you can cause very well may make the difference. In general, anything that one can do to increase the security of an information system under their control is a good thing. And any tools the vendors can provide us only helps to increase the security posture of our systems.
Do you say that at work? From the addy I see Military, and I know you guys have some Windows boxes somewhere, unless they were finally taken out. scares me when the Army uses Windows.... Or any other team who protects.
Downgrading a local / remote compromise (or code execution exploit) to a denial of service is a great step forward. It could mean the difference of joe hacker crashing your system or having your shadow file - which would you prefer? I personally would prefer that my system be crashed than having to deal with a security incident.
And lose my uptime???????? That bastard better hope he grabs the shadow file, at least that way I have one IP in the logs instead of 300 a second. Then I can retaliate. What's he going to do, say he was rooting me and I attacked him ? -- ----------------------------------------------- http://www.misfits.com Punk Rock, Opiates, and SUSE Linux. das Blut in den Adern erstarren lassen. Kuerbis der Zuhaelter
On Thursday 30 December 2004 00:07, James M. Patton wrote:
But when dealing with script kiddies, any delay or difficulties you can cause very well may make the difference. In general, anything that one can do to increase the security of an information system under their control is a good thing. And any tools the vendors can provide us only helps to increase the security posture of our systems.
Agreed, but you and most other people in this thread are continuing to make the assumption that these sorts of tools actually do what you want them to do. In the quote above you assume they will present delays or difficulties to script kiddies (or, I presume, any other flavour of attacker). Do you have reason to believe that they will actually do that? Have a look at Metasploit or some such script kiddie haunt: how long would it take to convert any of their exploits to bypass anti-stack smashing trickery? Not long, I suspect. An hour or two maybe. In the past I've taken a Metasploit exploit and fine tuned it myself for a specific penetration test. That example was a Windows one, actually, and I was trying to bypass something other than a stack guard, but I still did it without any real trouble. If stack guards become defacto standard on Linux, all the Metasploit exploits, and all the other script kiddie exploits, will be adjusted to bypass the protection. Exactly nothing will have been gained: script kiddies will still be able to download and run exploits, and 0-day hackers will just need to spend another hour in front of their disassembler working their way past one more hurdle to make their exploit work. Oh, and my computer will run slightly slower.
Downgrading a local / remote compromise (or code execution exploit) to a denial of service is a great step forward. It could mean the difference of joe hacker crashing your system or having your shadow file - which would you prefer? I personally would prefer that my system be crashed than having to deal with a security incident.
So would I, if that's what is achieved. As I said in a previous post, partial protection is *sometimes* achieved. If the reality is that for the most part these patches don't work, they do more harm than good. False sense of security, slower computers. As Thomas Beige said: "We evaluated various solutions. The problem is that some are very intrusive and most can be bypassed." I believe Linus rejected software based non-executable stack patches for the kernel for the same reasons.
participants (5)
-
Allen -
Derek Fountain -
James M. Patton -
Malte Gell -
Philippe Vogel