-----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----- _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"