Date: Sat, 19 Oct 1996 16:54:22 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: thorpej@nas.nasa.gov Cc: dnelson@emsphone.com, ache@nagual.ru, deraadt@theos.com, hackers@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/db/hash hash_buf.c Message-ID: <199610192354.QAA03149@phaeton.artisoft.com> In-Reply-To: <199610192038.NAA11524@lestat.nas.nasa.gov> from "Jason Thorpe" at Oct 19, 96 01:38:13 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > and will you include a runtime flag I can set to disable all of these, > > so I can get my performance back for the 100% of my programs that do > > NOT need all this security? > > Uhh, but you'd still have to pay the cost of checking the flag :-) That point occurred to me as well, but I wasn't going to be the first one to mention it. I liked PHK's suggestion of seeting a flag for the malloc() system such that free()'s cleared memory. It is unfortunately naieve, if my application watermarks total buffer allocation and uses a free list as a mechanism for fast reallocation of a class of object. For applications using this approach, the objects put on the free list but not actually freed will continue to contain potentially sensitive data. For what it's worth, the db fix will fail under similar use. Finally, it's interesting to note that these speed-driven optimizations which open the holes are often the result of attempts by OS and library designers to close holes at the expense of performance. It seems to me that the correct approach is to provide a conditional interface to any caching library system -- whether it be db or stdio or some other interface -- to explicitly dump the cache contents, and then expect the application writers to take note of potential problem situations and generate correct code to deal with them. One could arge that my knowledge that you are running on a Televideo terminal would make you subject to "send screen to host" based attacks (which I will note, I have personally used in system-cracking exercises to obtain "sensitive" exercise target information). Should we then zero the environment, which contains the TERM entry? What about the termcap entry, for which libtermcap.a would count as a caching library system? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610192354.QAA03149>