Date: Mon, 17 Feb 1997 20:54:23 +1000 (EST) From: Stephen McKay <syssgm@devetir.qld.gov.au> To: Charles Mott <cmott@srv.net> Cc: freebsd-chat@freebsd.org, syssgm@devetir.qld.gov.au Subject: Re: Countering stack overflow Message-ID: <199702171054.UAA16812@ogre.devetir.qld.gov.au>
next in thread | raw e-mail | index | archive | help
Charles Mott <cmott@srv.net> wrote: >I think strcpy() can tell whether it is working on an automatic variable >by looking for proximity to the stack pointer. However, it the frame >pointer isn't guaranteed, then strcpy() would not be able to determine an >upper bound for the length of the copy. Putting a bunch of arbitrary limits in strcpy() to try to second guess hackers will lead to 1) slower code 2) bugs. There aren't any other alternatives. >> > There is a tendency among the freebsd team to look for perfect solutions. >> > These security holes seem so severe, that I think some redundant overlay >> > schemes are advised, even if they are not perfect. Looking for perfection means you sometimes find it. I like this idea. It sure beats the hell out of a truck load of half solutions. Kinda like the one film a year that moves you, vs the regular slop on the TV. >I don't necessarily think an emergency code audit is the way to go. >However, it is a good idea to have a lot of people looking over the code. >My tendency would be to identify security holes but not have a load of >individual fixes. A few broad strategic moves are preferable in my view. The code audit is the best thing I've heard of in a long time. Independent code review is the best tool I've seen for producing quality code. The security beat-up has been a great motivator. The audit will reduce the quantity of all bugs, not just security holes. In all the time I've used computers (17 years now) I've lost data to butter fingers, application errors, OS errors, and hardware failures, never to hacker attacks. At the end of the audit, fewer programs will fail or corrupt data, so the chances of my data being safe will have increased. I'll probably have increased protection against the hackers, too, but that's a bonus. >What other security holes exist, other than stack overflow variations, >which allow an intruder to take over a machine? Other security holes? The whole of Unix is a security hole in one sense. It was designed to make adding things easy, and it succeeded. Easy change implies policy corruption over time. The way to make a secure OS is to make it bloody difficult to change anything. You build in data security classification from the start. You make sure nothing depends on anything with a lower security classification. You spend lots of time worrying about whether a high security class program can signal data to a low security class program by out of band channels like varying the cpu load or playing busily with a disk drive. Armed guards on the machine room door help too. :-) In short, right now you have a wonderfully productive, open, and free operating system that is full of holes and that will never be 100% secure. For every feature added you run the risk of a new security hole. That's life. Don't connect it to your pacemaker. Do keep backups. Don't make bizarre changes to the internals because it might stop a hacker attack you heard of the day before. Don't trust anything just because it works under DOS. Keep a level head. Brush your teeth. Don't accept lifts from strangers. Stephen.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702171054.UAA16812>