:: Re: [unSYSTEM] OpenSSL has exploit …
Top Pagina
Delete this message
Reply to this message
Auteur: jindq1
Datum:  
Aan: System undo crew
Onderwerp: Re: [unSYSTEM] OpenSSL has exploit mitigation countermeasures to make sure it's exploitable.
I'm sure they felt the same way when they introduced their features until
someone came along and served them humble pie. As for "completely screwed
up by all of the big players", there are no "big players", just passionate,
overworked human beings like yourself. You can't ask for perfection, just
humility when finding out a mistake-- something I think the community and
those responsible have all handled nicely this time around.


On Tue, Apr 15, 2014 at 5:44 AM, Caleb James DeLisle <cjd@???> wrote:

> Here's a pretty nice review of various SSL libraries.
> http://tstarling.com/blog/2014/04/ssl-implementations-compared/
>
> I tend to agree with him, sadly, if you need SSL probably your only
> option is running a little Java proxy in front of your webserver.
>
> Note that this is the fault of the SSL specification too, they created
> what is effectively a Ping message, nested inside of a generic SSL
> message and they added a duplicated length field. Cjdns also contains
> variable length ping messages, there is no ambiguity because they get
> their length from their container.
>
> In cjdns, all data which comes in from the world is immediately placed
> into Message structures which are effectively grow-down stacks, they
> have a length, a pointer to the head of the stack and a "padding"
> number which represents how far the stack can grow. Accesses to the
> data in this stack are through push and pop functions which contain
> bounds checks.
> https://github.com/cjdelisle/cjdns/blob/crashey/wire/Message.h
> A good example of this is in the DNS message parser where every read
> and every write is managed by Message_pop() and Message_push().
> https://github.com/cjdelisle/cjdns/blob/crashey/interface/DNSServer.c
>
> I'm not totally tooting my own horn here, my biggest point is to ask
> how can something that I managed to get more or less right be so
> completely screwed up by all of the big players?!
>
>
> Thanks,
> Caleb
>
>
> On 04/14/2014 05:53 PM, Troy Benjegerdes wrote:
> > The best part was the 'update your bitcoinz, because someone can steal
> > them if you use the completely unncecssary openssl payment protocol'.
> > Fortunately many altcoins have been saved by sheer laziness of not
> > updating to the latest pre-hacked version.
> >
> > So does Theo have a decent SSL implementation in OpenBSD? Is gnutls any
> > good?
> >
> > On Fri, Apr 11, 2014 at 10:07:34AM +0200, Caleb James DeLisle wrote:
> >> Heartbleed reads up to 64k of memory, crossing 16 page boundaries
> >> into "unallocated space" but it never triggers a segfault even
> >> on systems with hardened malloc().
> >>
> >> Theo de Raadt comments on OpenSSL's bypass of the OpenBSD secure
> malloc()
> >> http://article.gmane.org/gmane.os.openbsd.misc/211963
> >>
> >> And more about exactly how it works:
> >> http://www.tedunangst.com/flak/post/heartbleed-vs-mallocconf
> >>
> >> And why it's impossible to turn it off:
> >> http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse
> >>
> >>
> >> A missed bounds check is an accident, a pattern of insecure design
> >> practices is a scandal.
> >>
> >>
> >> _______________________________________________
> >> unSYSTEM mailing list: http://unsystem.net
> >> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
> >
> _______________________________________________
> unSYSTEM mailing list: http://unsystem.net
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>