On Thu, Sep 19, 2002 at 04:19:48PM +0200, Giuseppe Ghib� wrote: > Which patch are you talking for? I wasn't talking about StackGuard patch. I > was > talking of an application/daemon for which could exists a known buffer > overrun but not a patch (or the patch has not yet been packaged). What to > do in > this case? Turn off the machine or the services or hope not being attacked?
I see what you're saying but unpatched problems that are known last a very short period of time in the Linux world. So as far as I'm concerned this isn't a real issue. > I'm not saying compiling everything, which IMHO is too much, because for > instance there are application where speed is of main importance (e.g. I > wouldn't like have the XFree or OpenGL SG enabled, or for instance > scientific > application like Octave, etc.), but ONLY the MAIN network daemons, and as an > option. I.e. when you install them, the installer could ask you: "would you > like > to install stackguarded version of networked daemons?". You answer yes, > they are > installed, you answer "no", the standard RPMs (i.e. like the current ones) > are > installed. How much space could take? 30-40 MBs of duplicated RPMs? I'm not sure what you consider the main network daemons. But I don't think there is tons of room left on the CDs. But I haven't sat down and cacluated room. And before anyone says "CD3 has room." A bunch of that room is reserved for things that go on the commercial CDs. > Furthermore > it's not said it should be in the CDs. Could be an option and the SG daemons > could be downloaded from the net, as in the past was done with crypto > things. I > don't see any difference in doing this and in what currently could be > obtained > having libsafe enabled (you can disable libsafe <-> you can install regular > unstackguarded daemons). I think if there was a real demand for this: a) There'd be a lot more people asking for it. (This is the first time it's been mentioned on this list in the 2 years or so it's been around) b) Someone would have already packaged replacement daemons and put them on their website. I'm not aware of any of these. c) Lots of people would be using the Immunix distribution. None of these are realities. > probably mainly for speed (since we take also a 1-5% gain of speed in > consideration, otherwise we wouldn't have had -O3 in %optflags) > and because it's not supported on recent [recents means gcc 2.9X at least] > compilers (latest SG is of two years ago). Exactly. > Nobody said that with stackguard enabled you'll don't need regular > patches: A HUGE BANNER SHOULD SAY IT when you install. It's like saying that > since you use the safety belts, you can drove safe everywhere at 250 Kph > ala Schumacher. But on the other hand it's better to use safety belts that > don't > use them at all. > > On the other hand since you'll probably get a DOS, you have to update > anyway. I didn't say that you did say that. But your argument that we should do this to protect users who won't update just enables them to be lazy. While I do think we should make achieving a secure installation easier. I don't think we should engage in actions that just enable people to justify being lazy about their security. However to be more specific about my fears... there are many attacks (possibly even under utilized attacks) that are immune to such techniques. The very people you are trying to "help" are very unlikely to possess the technical knowledge to determine what issues they are protected with via StackGuard and are not. Consider heap overflows: http://www.w00w00.org/files/articles/heaptut.txt > No it's targetted to those not doing updates anyway, either because > they can't (because the machine could not go down even for 1 second, or > because they don't know a bug exists:), either because they don't want. > Yes, you > could say "You don't upgrade! Your fault, be exploited!!!". Well in the case of the people that can't have the machine down for 1 second then they ought to be doing security updates. Because a security problem will more than likely pull the machine offline, either because of maliciousness of the hackers or simply because they need to reinstall to clean up after them.... > This seems the old Linus sentence: since the security is not total, > better to not use any kind of these schemes and use as only security the > relying > on regular updates. A "false sense of security" is meaningless: or it > protect > against a reasonable class of attacks [demonstrated by trying/attempts] > (maybe combined together with other protection artifact: kernel, libsafe, > etc.) or even a kid can easily defeace it, and in this case is not a > protection. How about trying restating this in correct enough English that it's actually understandable? > probably for benchmarking, the other could be that it maybe could CAUSING > crashes or because could be easily defeaced (and in this case it would be > interesting to see the papers). stackguard has been defeated and can be defeated again. And the papers are not that hard to find: http://www.phrack.org/show.php?p=56&a=5 Now granted this vulnerability has been fixed but these sorts of hacks are bound to have other holes. For those wondering here's Immunix's response to the vulnerability: http://immunix.org/StackGuard/emsi_vuln.html However here is a more recent paper discussing holes in StackGuard in the more recent versions (2.0): http://www.corest.com/common/showdoc.php?idx=242&idxseccion=11&CORE-ST=66bd702e547fcb4ca6c1e7626084466d The following is actually about Microsoft's feature in their latest C++ compiler but it's essentially the same technique and applies to StackGuard to some degree: http://www.cigital.com/news/mscompiler-tech.html libverify seems to be an interesting alternative that might actually work better and is a runtime option: http://www.research.avayalabs.com/project/libsafe/doc/usenix00/paper.html#sec%3Abrw Though I'm not sure about the availability of this library... It's mentioned in several places but I can't seem to find it. > I think that this is important, but also not doing anything on this subject > because other distro hasn't yet done this is not the right way. Maybe they > are wondering the same of us... I found it hard to believe that distributions hadn't considered this... but you may be right doing some digging yields very little results from Linux distros discussing it. Here are some of the discussions I found: debian: http://marc.theaimsgroup.com/?l=debian-devel&m=94935938327802&w=2 http://marc.theaimsgroup.com/?l=debian-devel&m=92006813131362&w=2 http://marc.theaimsgroup.com/?l=debian-devel&m=91060014409759&w=2 Their arguments can be summed up as follows: a) Developers don't want to do two packages. b) Not enough bandwidth, disk space etc... for the packages. c) It would be useful for very few packages since most daemons don't run as root anymore. d) Would like cause lots of headaches trying to track down bugs that stackguard creates in apps... gentoo: http://marc.theaimsgroup.com/?l=gentoo-dev&m=102182848430723&w=2 Only think new here is that they don't seem to believe it's entirely open source. But Immunix's own website seems to disagree with them. If Mandrake wants to be seen as a real security conscious distributions I'd suggest the follow actions: a) Make security a priority. It's not now. Packagers should be called on to drop what they are doing to fix security issues. There is only so much that vdanen and cbelisle can do. Maintainers are the best people to be doing these upgrades... This is the reason why all currently released versions of Mandrake have a Mozilla that is vulnerable to at least one security issue that hasn't been updated. It's on the todo list but it never gets done. It's a big project but if the packagers participated it would go quicker. And Mozilla isn't the only thing. But it's the big one I can think off the top of my head and that I feel comfortable mentioning on a public list. So rather than having developers spend time stackguarding (or tracking down bugs that might be caused by stackguard), why not have them fix real known bugs? b) Increase Mandrake's education efforts. mandrakesecure.net and the security update option in the installer is real progress. But lots more can be done. c) Pay someone to do security audits on the applications. Probably not a realistic option considering Mandrake's situation but it would definitely be a good contribution to the community. Immunix already ships a version of RedHat with StackGuard in it. Very few apps aren't compiled with it. I don't see people all running over there to get it. Truth is that StackGuard is not a real competitive advantage. But I think the above actions would definitely be seen in a more positive light than simply stackguarding a few apps. -- Ben Reser <[EMAIL PROTECTED]> http://ben.reser.org Never take no as an answer from someone who isn't authorized to say yes.
