Date: Sun, 13 Apr 2014 15:48:23 +0200
From: fatkasuvayu+linux(a)gmail.com
To: users(a)lists.fedoraproject.org
Subject: Re: Serious OpenSSL vulnerability
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(a)gmail.com>
> 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.
Cheers,
--
Suvayu
Open source is the future. It sets us free.
--
users mailing list
users(a)lists.fedoraproject.org
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
Yes it's possible to compile C programs (with certain tradeoffs) to do bounds-checking
with some compiler environments.
I don't know if it would have protected against the heartbleed vulnerability but
MemGuard possibly could have caught a simple bounds overrun. See AppArmor now maintained
by Novell. Nice summary of options at
http://www.seas.gwu.edu/~simhaweb/security/summer2005/Stuart2.ppt
Ubuntu's chart of security features includes it but again it's unclear if OpenSSL
would have been protected by it in this case:
https://wiki.ubuntu.com/Security/Features
There is a performance hit for enabling bounds-checking during compile time, but that
seems worthwhile for infrastructure services.
An early publication at:
https://www.usenix.org/legacy/publications/library/proceedings/sec98/full...
QUOTE:
Array Bounds Checking for C
Richard Jones and Paul Kelly have developed a gcc patch [12] that does full array bounds
checking for C programs. Programs compiled with this patch are compatible with ordinary
gcc modules, because they have not changed the representation of pointers. Rather, they
derive a ``base'' pointer from each pointer expression, and check the attributes
of that pointer to determine whether the expression is within bounds.
The performance costs are substantial: a pointer-intensive program (ijk matrix multiply)
experienced tex2html_wrap_inline879 slowdown. Since the slowdown is proportionate to
pointer usage, which is quite common in privileged programs, this performance penalty is
particularly unfortunate.
However, this method is strictly more secure than StackGuard, because it will prevent all
buffer overflow attacks, not just those that attempt to alter return addresses, or other
data structures that are perceived to be sensitive (see Section 5.4). Thus we propose that
programs compiled with the bounds-checking compiler be treated as the ``backing
store'' for MemGuard-protected programs, just as MemGuard-protected programs are
the back-up plan for Canary-protected programs (see Section 3.3).