Andreas Aardal Hanssen wrote:
On Wed, 19 Jan 2005, Peter Stuge wrote:It isn't really a compiler function. 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. For example, malloc does not initialize, while calloc does.
Uninitialized variables are initialized to 0 by the compiler, so if I
can manage to somehow make those LDAP calls fail, I will have root
access on your system via the network. Not good.
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).
Andy :-)
-- Andreas Aardal Hanssen | http://www.andreas.hanssen.name/gpg Author of Binc IMAP | "It is better not to do something http://www.bincimap.org/ | than to do it poorly."
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. 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). Bottom line is the programmer should never make any assumptions either way about uninitialized memory but, more often than not, a particular location will indeed be zero.
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 must admit I did smile when I read this post, but I promise I didn't put him up to it!
Ivan M.
------------------------------------------------------------------------
