Re: [Cooker] Stackguard, FormatGuard for future Mandrake versions?
Ben Reser wrote: Even with an insignificant performance problem (which is debatable). It would have little purpose. As an admin a tool like this wouldn't give me better sleep. As I've pointed out before there have been ways found around such tools. The only better sleep I get is by verifying that I am patched against the vulnerability with a real fix. Well, and if the patch doesn't exists yet? And furthermore I repeat, in most cases there aren't ANY sysadmin who worries about upgrades. As far as worms go there have been realtively few Linux worms. And all of them have been for well known and already patched issues. Something well, not as nimda (btw, aften one year I still get apache logs full of nimda and red worm attempts, this means that sysadmins often upgrades their machines ASAP...), but the fact that there aren't so much (especially because on Linux hasn't the email as main vehicle for the propagation) doesn't mean they aren't dangerous. like StackGuard provides an insignificant amount of added protection for people who apply the proper updates. when updates doesn't cause you to reconfigure your daemons... ;-) I just don't think it's worth it. If it was then all the distros would already be doing it and the Immunix patches would have been merged into the mainline gcc. tell me of the latest 100 security linux advisors for daemons having buffer overruns the possibility to obtain a remote shell (or root shell) and how many of them would have been blocked (with a DOS for instance) if the daemon have had libsafe active or was compiled with stackguard enabled. If we had based our security to what other distros do, then we wouldn't have had any msec, libsafe, kernel-secure, etc. and all our security tools would have been tcp_wrappers... Bye. Giuseppe.
Re: [Cooker] Stackguard, FormatGuard for future Mandrake versions?
On Thu, Sep 19, 2002 at 08:15:23AM +0200, Giuseppe Ghibò wrote: Well, and if the patch doesn't exists yet? And furthermore I repeat, in most cases there aren't ANY sysadmin who worries about upgrades. It exists it just hasn't been kept up to date with the current gcc... Which I have to wonder why? well, not as nimda (btw, aften one year I still get apache logs full of nimda and red worm attempts, this means that sysadmins often upgrades their machines ASAP...), but the fact that there aren't so much (especially because on Linux hasn't the email as main vehicle for the propagation) doesn't mean they aren't dangerous. I didn't say they weren't dangerous I just said they weren't as prevalent. And nimda/code red are both NT worms. I'll note that I was getting tons of nimda attempts when it first become well known on the net. The latest Linux worm has elicited may a few dozen possible (can't say for sure because of the way it attempts to do it) attempts since it showed up on slashdot. Comparing the threat of a NT based worm to a Linux based worm is specious at best. I believe the Linux community is far better suited to respond to threats. How many email worms has Windows had? How long did it take Microsoft to get fixes that reliably stopped the propagation of these worms? How long does it take the Linux community to respond to similar threats. You do the math. when updates doesn't cause you to reconfigure your daemons... ;-) Very rarely have we had to put out an update that requires reconfiguration. We almost always patch to fix security issues. So that's a really lame response. I can think of only one case that warranted that type of upgrade and that was an Apache upgrade because we moved everyone to using the new style configuration setup (commonhttpd.conf et al). tell me of the latest 100 security linux advisors for daemons having buffer overruns the possibility to obtain a remote shell (or root shell) and how many of them would have been blocked (with a DOS for instance) if the daemon have had libsafe active or was compiled with stackguard enabled. What you're not taking in consideration here is the potential real problems Mandrake would have in implementing stackguard. Compiling everything in the distro with it wouldn't probably be an option because I'm positive there are at least a few things that it wouldn't work right with. Making it an option to use isn't exactly an easy thing to do because it's a compile time option. Not a run time option. Mandrake is already limited on space for new RPMS Where are we going to find the MB if not GB's to put the duplicated RPMS? If we had based our security to what other distros do, then we wouldn't have had any msec, libsafe, kernel-secure, etc. and all our security tools would have been tcp_wrappers... You're certainly not the only distro shipping libsafe or secured kernels. And the stackguard patch to gcc isn't exactly new it's been around for years. There has to be a reason why other distros haven't adopted it. Or for that matter why Mandrake hasn't adopted it. However the last fear I have about implementing it is that it will make the very thing worse that you claim is a reason for implementing it. Patches are necessary with or without stackguard. As I've seen happen time and time again firewalls became an excuse for poorly implemented security. It's not that firewalls don't have a place in a security regime. It's that many of the newbie type admins you are targeting your issues to will think that's all they have to do. So indeed I fear that applying a bandaide (stackguard) and then the ensuing PR/marketing that will surround it will create a false sense of security. And will in fact make the problem worse. In the end between the difficulty in implementing this change and the problems with the attitudes it might create I tend to think it wouldn't benefit us in the long run. I could be wrong. But that's my opinion. At any rate though you didn't answer my question. *WHY* have other distros ignored this. It's not like it's something nobody has known about (it's been on slashdot at least once). There has to be a reason for it. Even if it is the attitude fear that I have about it. We certainly should take advantage of analysis that other distros have made of the technology in determining if we should implement it. Don't you think? -- Ben Reser [EMAIL PROTECTED] http://ben.reser.org Never take no as an answer from someone who isn't authorized to say yes.
Re: [Cooker] Stackguard, FormatGuard for future Mandrake versions?
[snip : Stackguard fart] This should be taken up with the ISO C standardization committee so that boundary checking becomes an optional language feature (giving us a well thought out choice) instead of forcing a stopgap measure on everybody... [snip : to the point security reply by Ben] why not with a standard install have it use the guarded versioon, with the majority of new Mandrake users coming from a windows environment, they won't think there was a performance hit at all, since anything over a 1/100 rate will be faster than windows. [snip : ridiculous benchmark] Then it would be Goodbye Mandrake. I thought Linux was about CHOICE, why would I, as a scientific user who needs all the performance he can reasonably get, be forced to get substandard performance just to suite people who don't patch their machines? Cloning Windoze (in feature and in phenomenon or culture) is making Linux LESS attractive every day, not so far from now the only difference will be price (and that's not necessarily a Good ThingTM)... Jaqui Guy
Re: [Cooker] Stackguard, FormatGuard for future Mandrake versions?
Ben Reser wrote: On Thu, Sep 19, 2002 at 08:15:23AM +0200, Giuseppe Ghibò wrote: Well, and if the patch doesn't exists yet? And furthermore I repeat, in most cases there aren't ANY sysadmin who worries about upgrades. It exists it just hasn't been kept up to date with the current gcc... Which I have to wonder why? 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 didn't say they What you're not taking in consideration here is the potential real problems Mandrake would have in implementing stackguard. Compiling everything in the distro with it wouldn't probably be an option because I'm positive there are at least a few things that it wouldn't work right with. Making it an option to use isn't exactly an easy thing to do because it's a compile time option. Not a run time option. Mandrake is already limited on space for new RPMS Where are we going to find the MB if not GB's to put the duplicated RPMS? 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? 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). If we had based our security to what other distros do, then we wouldn't have had any msec, libsafe, kernel-secure, etc. and all our security tools would have been tcp_wrappers... You're certainly not the only distro shipping libsafe or secured kernels. And the stackguard patch to gcc isn't exactly new it's been around for years. There has to be a reason why other distros haven't adopted it. Or for that matter why Mandrake hasn't adopted it. 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). However the last fear I have about implementing it is that it will make the very thing worse that you claim is a reason for implementing it. Patches are necessary with or without stackguard. As I've seen happen 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. time and time again firewalls became an excuse for poorly implemented security. It's not that firewalls don't have a place in a security regime. It's that many of the newbie type admins you are targeting your issues to will think that's all they have to do. So indeed I fear 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!!!. that applying a bandaide (stackguard) and then the ensuing PR/marketing that will surround it will create a false sense of security. And will in fact make the problem worse. 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. In the end between the difficulty in implementing this change and the problems with the attitudes it might create I tend to think it wouldn't benefit us in the long run. I could be wrong. But that's my opinion. also that was MY,
Re: [Cooker] Stackguard, FormatGuard for future Mandrake versions?
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
Re: [Cooker] Stackguard, FormatGuard for future Mandrake versions?
Steve Bergman wrote: On Mon, 2002-09-16 at 15:29, Ben Reser wrote: On Mon, Sep 16, 2002 at 02:17:50PM -0500, Steve Bergman wrote: So, am I just not seeing the negative side to this? Immunix apparently does not have enough name recognition and influence to make it happen. But Mandrake does. After seeing exploit after exploit list RedHat, SuSE, Debian. etc. as having a root vulnerability but with Mandrake as just a DOS, I'm sure all the other distros would follow suit. Performance and it's bound to cause some programs not to build right causing people problems who want to build programs from tarballs. I started to write that the performance impact is trivial. However, reviewing the info on the immunix site (which I admittedly haven't done in a while) I find that, depending on the nature of the app, the performance impact can be significant. FormatGuard does require some (small percentage of) programs to be modified to compile. StackGuard does not seem to have this problem, except with (surprise!) the Linux kernel. (And yes, that is a pain.) But no there isn't a whole lot of issues with doing this from what I've seen. However it is no guarantee to prevent successful attacks. I seem to recall that there have been some ways to get around it in the past. They get fixed but then you have to recompile all the apps to take advantage of it. I know of one instance of this in (I believe) StackGuard 1.20. Think of it as a bandaide. Sooner or later the bandaide won't stick any more. Good example. BandAid's are not a miracle cure. However, they are still a very good idea. ;-) -Steve IMHO point everytime out that more or less boundary checking techniques would have impact on performance is annoying. MHHO is this: the program compiled with boundary checking enabled is slow(er) by a factor of 10 (and even 100)? I would answer and then? buy a faster machine if you need more power and want to use boundary protected programs. Seems that the only importance is performance, while most the the vulnarable machines are machine with low traffic, whose daemons are doing almost anything, where the administrator maybe doesn't exists, or doesn't have the time to apply new RPM updates on a daily basis. Such machines are mostly vulnerable to new worms which often appears on a standard basis after the advisors. In such cases, for instance, an apache server running at a factor speed of 1/100 with respect to the unprotected version is insignificant. Certainly SG (like other tools, e.g. libsafe) it's not a panacea against every attack and should NEVER be considered a replacement for standard timely updates, but could save the sleep of many administrators to the next morning (like a spare wheel), who maybe don't remember if they are vulnerable or not to the latest worm...; now not considering that the StackGuard 2.0 patch is only available for obsolete compilers (we are currently at gcc 3.2, while stackguard is still for egcs 1.1.2) and that is two years that isn't upgraded, but a way would be NOT to compile the entire distro with stackguard, kernel included, but only the most common network daemons and the libraries they use, then link these programs statically with a stackguarded compiled version of glibc. For instance openssh and openssl, apache, php, perl, sendmail/postfix, bind, cups [not telnet, nfs, portmap, because there shouldn't be anyway ;-)], anonymousftp, etc.; furthermore these packages should be installed on demand as alternative to standard (unstackguarded) ones, not as mandatory and unique replacement. Bye. Giuseppe.
Re: [Cooker] Stackguard, FormatGuard for future Mandrake versions?
On Tue, Sep 17, 2002 at 11:19:10PM +0200, Giuseppe Ghibò wrote: IMHO point everytime out that more or less boundary checking techniques would have impact on performance is annoying. MHHO is this: the program compiled with boundary checking enabled is slow(er) by a factor of 10 (and even 100)? I would answer and then? buy a faster machine if you need more power and want to use boundary protected programs. Seems that the only importance is performance, while most the the vulnarable machines are machine with low traffic, whose daemons are doing almost anything, where the administrator maybe doesn't exists, or doesn't have the time to apply new RPM updates on a daily basis. Such machines are mostly vulnerable to new worms which often appears on a standard basis after the advisors. In such cases, for instance, an apache server running at a factor speed of 1/100 with respect to the unprotected version is insignificant. Even with an insignificant performance problem (which is debatable). It would have little purpose. As an admin a tool like this wouldn't give me better sleep. As I've pointed out before there have been ways found around such tools. The only better sleep I get is by verifying that I am patched against the vulnerability with a real fix. As far as worms go there have been realtively few Linux worms. And all of them have been for well known and already patched issues. Something like StackGuard provides an insignificant amount of added protection for people who apply the proper updates. As such I think the hassle of it is just isn't worth it. And it's not just perforance... Certainly SG (like other tools, e.g. libsafe) it's not a panacea against every attack and should NEVER be considered a replacement for standard timely updates, but could save the sleep of many administrators to the next morning (like a spare wheel), who maybe don't remember if they are vulnerable or not to the latest worm...; now not considering that the StackGuard 2.0 patch is only available for obsolete compilers (we are currently at gcc 3.2, while stackguard is still for egcs 1.1.2) and that is two years that isn't upgraded, but a way would be NOT to compile the entire distro with stackguard, kernel included, but only the most common network daemons and the libraries they use, then link these programs statically with a stackguarded compiled version of glibc. For instance openssh and openssl, apache, php, perl, sendmail/postfix, bind, cups [not telnet, nfs, portmap, because there shouldn't be anyway ;-)], anonymousftp, etc.; furthermore these packages should be installed on demand as alternative to standard (unstackguarded) ones, not as mandatory and unique replacement. This would create new problems... If you start compiling the things you are talking about with the stackguard compiler you're going to end up with one heck of a lot of stuff compiled with it. I'd have to sit down and look at the depencies but I think you might very well run into incompatiblities in C++ mangling. Granted that most of these apps are in C not C++, but perl is used by lots of things as an interpretor and if just one of those is written in C++ you have a headache on your hands. I just don't think it's worth it. If it was then all the distros would already be doing it and the Immunix patches would have been merged into the mainline gcc. -- Ben Reser [EMAIL PROTECTED] http://ben.reser.org Never take no as an answer from someone who isn't authorized to say yes.
Re: [Cooker] Stackguard, FormatGuard for future Mandrake versions?
Giuseppe Ghibò wrote: Steve Bergman wrote: On Mon, 2002-09-16 at 15:29, Ben Reser wrote: On Mon, Sep 16, 2002 at 02:17:50PM -0500, Steve Bergman wrote: So, am I just not seeing the negative side to this? Immunix apparently does not have enough name recognition and influence to make it happen. But Mandrake does. After seeing exploit after exploit list RedHat, SuSE, Debian. etc. as having a root vulnerability but with Mandrake as just a DOS, I'm sure all the other distros would follow suit. Performance and it's bound to cause some programs not to build right causing people problems who want to build programs from tarballs. I started to write that the performance impact is trivial. However, reviewing the info on the immunix site (which I admittedly haven't done in a while) I find that, depending on the nature of the app, the performance impact can be significant. FormatGuard does require some (small percentage of) programs to be modified to compile. StackGuard does not seem to have this problem, except with (surprise!) the Linux kernel. (And yes, that is a pain.) But no there isn't a whole lot of issues with doing this from what I've seen. However it is no guarantee to prevent successful attacks. I seem to recall that there have been some ways to get around it in the past. They get fixed but then you have to recompile all the apps to take advantage of it. I know of one instance of this in (I believe) StackGuard 1.20. Think of it as a bandaide. Sooner or later the bandaide won't stick any more. Good example. BandAid's are not a miracle cure. However, they are still a very good idea. ;-) -Steve IMHO point everytime out that more or less boundary checking techniques would have impact on performance is annoying. MHHO is this: the program compiled with boundary checking enabled is slow(er) by a factor of 10 (and even 100)? I would answer and then? buy a faster machine if you need more power and want to use boundary protected programs. Seems that the only importance is performance, while most the the vulnarable machines are machine with low traffic, whose daemons are doing almost anything, where the administrator maybe doesn't exists, or doesn't have the time to apply new RPM updates on a daily basis. Such machines are mostly vulnerable to new worms which often appears on a standard basis after the advisors. In such cases, for instance, an apache server running at a factor speed of 1/100 with respect to the unprotected version is insignificant. Certainly SG (like other tools, e.g. libsafe) it's not a panacea against every attack and should NEVER be considered a replacement for standard timely updates, but could save the sleep of many administrators to the next morning (like a spare wheel), who maybe don't remember if they are vulnerable or not to the latest worm...; now not considering that the StackGuard 2.0 patch is only available for obsolete compilers (we are currently at gcc 3.2, while stackguard is still for egcs 1.1.2) and that is two years that isn't upgraded, but a way would be NOT to compile the entire distro with stackguard, kernel included, but only the most common network daemons and the libraries they use, then link these programs statically with a stackguarded compiled version of glibc. For instance openssh and openssl, apache, php, perl, sendmail/postfix, bind, cups [not telnet, nfs, portmap, because there shouldn't be anyway ;-)], anonymousftp, etc.; furthermore these packages should be installed on demand as alternative to standard (unstackguarded) ones, not as mandatory and unique replacement. Bye. Giuseppe. why not with a standard install have it use the guarded versioon, with the majority of new Mandrake users coming from a windows environment, they won't think there was a performance hit at all, since anything over a 1/100 rate will be faster than windows. ( just for a test I ran an image through a few functions in corel photo paint on my 233 mhz p2 laptop, same image, same functions in corel photo paint on my wife's 600 mhz p3 tower under windows. there was no appreciable difference in the time to perform the functions. therefore the hit wouldn't really affect new users coming from windows. they are used to slower functionality.) expert install give the option for it or not. Jaqui
Re: [Cooker] Stackguard, FormatGuard for future Mandrake versions?
On Wed, Sep 18, 2002 at 04:36:28PM -0700, J. Greenlees wrote: why not with a standard install have it use the guarded versioon, with the majority of new Mandrake users coming from a windows environment, they won't think there was a performance hit at all, since anything over a 1/100 rate will be faster than windows. ( just for a test I ran an image through a few functions in corel photo paint on my 233 mhz p2 laptop, same image, same functions in corel photo paint on my wife's 600 mhz p3 tower under windows. there was no appreciable difference in the time to perform the functions. therefore the hit wouldn't really affect new users coming from windows. they are used to slower functionality.) expert install give the option for it or not. What you're suggesting would require including a bunch of extra packages. That is very unlikely to happen. Again I ask. If this is so beneficial why has it not be included into the gcc main? Even if it was just an option to turn on. -- Ben Reser [EMAIL PROTECTED] http://ben.reser.org Never take no as an answer from someone who isn't authorized to say yes.
Re: [Cooker] Stackguard, FormatGuard for future Mandrake versions?
On Mon, 2002-09-16 at 15:29, Ben Reser wrote: On Mon, Sep 16, 2002 at 02:17:50PM -0500, Steve Bergman wrote: So, am I just not seeing the negative side to this? Immunix apparently does not have enough name recognition and influence to make it happen. But Mandrake does. After seeing exploit after exploit list RedHat, SuSE, Debian. etc. as having a root vulnerability but with Mandrake as just a DOS, I'm sure all the other distros would follow suit. Performance and it's bound to cause some programs not to build right causing people problems who want to build programs from tarballs. I started to write that the performance impact is trivial. However, reviewing the info on the immunix site (which I admittedly haven't done in a while) I find that, depending on the nature of the app, the performance impact can be significant. FormatGuard does require some (small percentage of) programs to be modified to compile. StackGuard does not seem to have this problem, except with (surprise!) the Linux kernel. (And yes, that is a pain.) But no there isn't a whole lot of issues with doing this from what I've seen. However it is no guarantee to prevent successful attacks. I seem to recall that there have been some ways to get around it in the past. They get fixed but then you have to recompile all the apps to take advantage of it. I know of one instance of this in (I believe) StackGuard 1.20. Think of it as a bandaide. Sooner or later the bandaide won't stick any more. Good example. BandAid's are not a miracle cure. However, they are still a very good idea. ;-) -Steve
