On Wed, Jan 19, 2005 at 11:27:06AM -0700, Ivan M. wrote: > >>Uninitialized variables are initialized to 0 by the compiler, so > > > >It the memory beneath the variable is untouched, it will be 0 > >because that's its value at boot time. But 99.999999% of the time, > >it'll be garbage. And the compiler isn't required to clean up (gcc > >doesn't, and MSVC++ initializes it to garbage, if I'm not mistaken, > >to enforce a crash). > > It isn't really a compiler function.
I've heard that it is. On checking the comp.lang.c FAQ I learn that it is, but not always. Answer 1.30 says that static variables "are guaranteed to start out as zero, as if the programmer had typed "= 0"" but that other kinds "start out containing garbage, unless they are explicitly initialized." > Ultimately, all memory is provided by the operating system in > response to library calls. Whether or not memory is /guaranteed/ > to be initialized to zeros depends on the call. Sure, as long as higher layers don't specify anything else. (Like the static.) > For example, malloc does not initialize, while calloc does. > > But even that depends on the OS. A secure OS would /always/ > initialize all new memory pages to zeros, simply to prevent old > information from being available to programs that shouldn't be able > to read it. How usable would a program be if it only ran on secure OS:s? I want my programs to be able run in as many places as possible, so I can't really afford the luxury of assuming that the OS makes any good decisions beyond what is standardized or documented. > On the Intel architecture this is really easy to do, and I believe > that Linux does it (although I'd have to check to be sure). 2.4.23 doesn't, and probably not later versions either. > Bottom line is the programmer should never make any assumptions > either way about uninitialized memory Agreed! > but, more often than not, a particular location will indeed be > zero. This depends entirely on the OS memory management. (Kernel as well as C library.) > I hate to beat a horse to death (especially the rescue horse my wife > just got) but this whole class of potential errors by Oort can be > avoided with a single line of code at the beginning of main() in the > bincimapd.cc file: > > if (!geteuid() || !getuid()) return 111; > > This solves the problem for all compiler/OS combinations. I'm afraid not, since groupId and userId weren't static, the program would change to undefined ids. Either 0, or any other valid user ID on the system, which makes it impossible to test for. As a side note, 1 or 2 is probably better than 111 since this isn't a temporary problem. > I must admit I did smile when I read this post, but I promise I > didn't put him up to it! This was _really_ a bug in the checkpassword program, and as such it should be fixed there, not worked around elsewhere. The checkpassword program is obviously tremendously sensitive, and while it introduces a single point of failure I still appreciate only having to audit one small program, rather than having to check every single program that talks to the network. :) //Peter
