freebsd security - Apr 2014 - Heartbleed, a few naive questions

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.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 4/9/14, 10:28 PM, Ronald F. Guilmette wrote:
> 
> 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"?
For this bug, doing calloc() makes no difference.  Is doing calloc() a
good practice in general?  Sometimes it is, sometimes it merely slows
things down.
> 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] ?
Automatic arrays are introduced with C99.

By the way, how do you benefit from allocating from stack than from
heap for relatively large chunk of memory?
> 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)?
I don't think I understood this question, do you have a code fragment
to describe your question?
> 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?
Do you have any reference here?  I'm not an expert in OpenSSL code but
looking at the specification, it seems like, without the payload
length there is no way to figure out what length the padding is.
> 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.
Upon successful exec*(), the process address space is rebuilt.  So no,
you can no longer access any memory contents.
> 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.
New pages are always initialized to zeros before access is given to
process, this must happen or that by itself is a very serious security
issue, because inter-process isolation is broken.

Hope this helps.  Should you find anything that we need to correct in
the manual page to help others please speak up.

Cheers,
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTRjouAAoJEJW2GBstM+nsaBUP/3efRvXu6+g37XZvPmJq6Ahm
+uHQlZx7RjEP/3StQhNpHGL0BGTKiv5+diSusABOk8brkaw+Ergn7nTXRGRO4TTz
9wWBLcQs0iETsltYXmDSUw+EBJZDPFSjhyiZZTjxi9rzdqyVeIPlE4L5Tfu8dRhC
QqO4Ccxh4QA6p3nMVhrh0WNbnvjfBTWNkZERo4w8b4QdwrkyxpnqVq0fwwNyIks1
EJ8u54EE2wAra7EfmaIfPFEELjID9JmlknmLuGE1rAbqW5zYyMU4eVaFHWpMVR1E
1yjJZrj7wGu6wBhM5zp1kh2+9HU7UnB7Xg1VVZjzT7XdkBO2IcftbpxZ6j+3VLM0
H9zwV7+9tMFAcXoOrAuHPhzqmxEImXd88uWxGJ31m0Ke6gPO1HZkc+Hknkaznfpa
+W/NOKEKwr8a01renLIm0HhMdSRM/s2iDMFhZg47uCXWNxIqcpaDyJ/wU2vgi+yF
OnDpxJ9/OfCcaj2pd8FdR+4mkxAQiwOc1ItSPqOj2pKNVbTNZnbff/z7ATAWI0e3
5aI4OibW7Fm2I5n6UhRePPfmNle+iJL2WXawmolNnvUohtrSwqeznkpvm2kLl3gz
c4G+TzbegSn2wVmM2IiRP4tQcYxTuhFPCGnDnH2MfGpaEAMqMZRl5CESeiTjtY1F
8eC8q75ReaBNO95iGge1
=vXk2
-----END PGP SIGNATURE-----