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@xxxxxxxxx> > wrote: > > > Hi > > > > > > 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.
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.
Attachment:
pgpM7Ef2vha_R.pgp
Description: PGP signature
-- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
