Date: Wed, 24 Nov 1999 00:29:52 -0700 From: Warner Losh <imp@village.org> To: Mark Murray <mark@grondar.za> Cc: current@freebsd.org Subject: Re: FreeBSD security auditing project. Message-ID: <199911240729.AAA18709@harmony.village.org> In-Reply-To: Your message of "Tue, 23 Nov 1999 21:05:25 %2B0200." <199911231905.VAA80949@gratis.grondar.za> References: <199911231905.VAA80949@gratis.grondar.za>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199911231905.VAA80949@gratis.grondar.za> Mark Murray writes: : o unsafe use of the str*(3) functions; strcat/strcpy/sprintf &c. Keep a keen eye out for unsafe uses of strncpy and strncat and know the man page by heart before thinking you are correct :-) : o &c. please contribute here.... I had a long list this afternoon and my link flaked out. Make sure that you look for unusual buffer overflows. This one requires that you think. Grepping for strcpy is one thing, but looking at all the memcpy, memmove, bcopy in the source tree is needed. Look for moving NULL terminated lists w/o moving the NULL. Look for opportunities to overflow things like the atexit run queue, etc. Look for buffer overflows that are caused by sloppy programming. while (*src++ = *dst); [SIC] is but one buggy example :-) Look for cases where the safer interfaces are used improperly. Eg, char foo[5]; ... snprintf(foo, 10, ...). Look for off by one errors in passing lengths to kernel routines. Make sure that you know if that routine will NUL terminate for you or not. Look for DoS things. These include infinite loops on bad data, core dumping (although not all core dumps can be turned into an attack, just some of them). Look for dangerous signal handling. Look for bugs. Don't overlook something because it has a bug that isn't security related. Fix it, or file a PR. Many of the early OpenBSD bug fixes were later turned into attacks. Look at all setuid programs to make sure the need to be setuid. Ditto setgid. Dump is a good example of a program that is setgid that doesn't need to be since it can fork write to do what it is doing internally. Look for places in the kernel that don't do range checking properly. These will turn into panics. Memory leaks can also be leveraged into a DoS, so look for them as well. Take a long hard look at the startup sequence of FreeBSD. Consider that most of the important files on the system are imutable, but make sure that all of them can be made imutable to secure the system. Right now there are many holes. OpenBSD closed the window by raising security level early. Might not be a bad idea to look into what they have done. Be paranoid. If you don't think the whole world is out to get you and a giant conspirancy, then watch more X-Files until you do :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911240729.AAA18709>