On Sun, Apr 13, 2014 at 10:05:08AM -0400, Sam Varshavchik wrote:
Suvayu Ali writes:
On Sun, Apr 13, 2014 at 08:38:11AM -0500, Ranjan Maitra wrote:
On Sun, 13 Apr 2014 09:15:04 -0400 Rahul Sundaram metherid@gmail.com wrote:
On Sun, Apr 13, 2014 at 6:23 AM, Timothy Murphy wrote:
Roger wrote:
It happened. It was known for years.
Everything I have seen says it has been known for about 1 week.
Incidentally, I am no programmer but I would have thought it would be relatively simple to set up a test to see if a "malloc"-ed space could be transgressed.
Not in this case. openssl uses a custom malloc
So, a valgrind -tool=memcheck --leak-check=yes --show-reachable=yes --track-fds=yes --track-origins=yes would not have helped?
AFAIU this is not a memory leak; it is a buffer overflow: lack of bounds checking. I do not think valgrind (or any other tool) can help with that. Feel free to correct me if I am wrong.
For this particular vulnerability, it is not technically a buffer overflow. The vulnerable code merely reads past the end of an allocated buffer. A buffer overflow gets exploited by writing past the allocated buffer.
If you want to classify this, the best classification here would be an information leak, and not a buffer overflow.
Indeed! I wasn't accurate there. Thanks for pointing it out.
The chances of valgrind catching this exploit are quite small. The only possible way I see valgrind could've complained would be if the original buffer that was allocated for the TLS ping message got padded by malloc() by a non-significant amount, and valgrind would've complained about reading uninitialized memory.
And ven in that case, valgrind() tends to complain about uninitialized memory only if its value is used to branch on. There's lots of code that ends up reading uninitialized memory without resulting in undefined behavior, for one reason or another. valgrind() doesn't typically complain reading a few uninitialized bytes after a range that's been legally malloc()ed, unless its value is used for branching, or something.
There is a nice analysis by a cloudflare engineer here:
Although the conclusion of that article about the likelihood of such an information leak was proven wrong by the results of their challenge, I think the analysis still seems very valid.
Thanks to the other posters for their responses. Quite a nice read.
Cheers,