Date: Sat, 19 Oct 1996 20:22:38 -0400 (EDT) From: Chuck Robey <chuckr@glue.umd.edu> To: Terry Lambert <terry@lambert.org> Cc: thorpej@nas.nasa.gov, 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: <Pine.OSF.3.95.961019201850.8857C-100000@baud.eng.umd.edu> In-Reply-To: <199610192354.QAA03149@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 19 Oct 1996, Terry Lambert wrote: > 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. If one could set such a flag globally, then all the stuff in libc that uses malloc could be written to look at that global flag and DTRT, without changing any of the interfaces at all. Set the flag in crt0 to the current action (no action) and things in fact would not change at all, no speed penalty. Doesn't sound like a bad idea at all. > > 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. > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and n3lxx, both FreeBSD (301) 220-2114 | version 2.2 current -- and great FUN! ----------------------------+-----------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.OSF.3.95.961019201850.8857C-100000>