Date: Wed, 09 Apr 2014 22:28:09 -0700 From: "Ronald F. Guilmette" <rfg@tristatelogic.com> To: freebsd-security@freebsd.org Subject: Heartbleed, a few naive questions Message-ID: <41616.1397107689@server1.tristatelogic.com>
next in thread | raw e-mail | index | archive | help
My apologies if the following few naive questions are out of place
or off topic here. I do suppose that there might perhaps be other
places where such question might perhaps be better put, but many/most/all
of those other places appear to be filled, at present, with discussions
and comments which are about on par with some of the alien abduction
theories relating to MH370. And I would prefer to have a more thoughtful
exchange. Thus I come here.
Anyway, having read the currently available (and quite detailed) online
descriptions of the Heartbleed bug, I am disposed to seek answers to the
following few questions:
1) Why does OpenSSL even contain a function called "OPENSSL_malloc"?
Does anyone other than me think that it might perhaps have been
a better choice to provide only a function called "OPENSSL_calloc"?
2) Not that this would actually have eliminated the bug, but...
Was there some compelling reason why space for the "buffer" at issue
was allocated via a call to "OPENSSL_malloc", rather than, say, simply
being declared as a function-local "auto" char[1+2+65536+padding] ?
3) Not that this would actually have eliminated the bug, but...
After making some effort to do so, I have been unable to find any
information online which would serve to document the initial state
of the blocks of memory allocated by calls to pthread_create().
Would any of you happen to know if said blocks are or, conversely,
are not cleared to zeros prior to execution of the created thread(s)?
4) If, as has been suggested in some quarters, the _actual_ size of the
heartbeat client-supplied payload may be correctly determined
without any reference whatsoever to the _content_ of the request
packet, then why is/was it the case that the SSL protocol specified
that such packets should contain a payload length specification...
a value that, as we all now know, may be spoofed with disasterous
consequences?
Regards,
rfg
P.S. Looking just now at the man page for execve(2) I could not help but
notice that it neglects to say a single word about the state of the memory
comprising the initial page of the (new) execution stack, let alone any
additional pages that may be subsequently and automagically added to the
execution stack.
I, for one, had certainly always hoped and believed that such pages would
be pre-initialized by the kernel to all zeros... as opposed, say, to whatever
data had been left in those pages by the most recently deceased process(es)
that last held them. But in lieu of any explicit statement on the matter
within the man page, I am left with a slight uneasy feeling.
To be clear, I have no real fear that others might be able to abscond with
data left unerased at the demise of my processes, but as a general matter
of principal I greatly prefer it if important aspects of behavior are
documented.
To me, every man page is a contract.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41616.1397107689>