:: Re: [unSYSTEM] OpenSSL has exploit …
Góra strony
Delete this message
Reply to this message
Autor: Amir Taaki
Data:  
Dla: System undo crew
Temat: Re: [unSYSTEM] OpenSSL has exploit mitigation countermeasures to make sure it's exploitable.
openssl is shit. you'd be wise to listen and not thrust your opinion where
you're misinformed.

https://www.peereboom.us/assl/assl/html/openssl.html

we've been looking to replace it since before heartbleed for ages now.
problem is that there's a wealth of software out there using openssl, and
migrating away is not as easy as flicking a switch.

when you have small overworked teams which consistently perform better
than large orgs or popular software, we can certainly say there's some
mega stupidity going on here.

for instance i've had to add valgrind exceptions to ignore all the many
false reports openssl triggers. this is just lazy poor unprofessionalism
and there's no excuse (except the coders are irresponsible and dont give a
fuck except getting the next paycheck / making it work). this is a case of
everyone passing the buck onto someone else, and then others making
hacks/workarounds for each others shit work culminating in a giant
clusterfuck. a microcosm of society really.

> It's all naivety. US Congressmen for example, on the whole, still think
> AOL
> is the only way to use the internet. With the push to further automate
> everything, using a calculator in math class will child's play compared to
> the sweeping decisions and assessments made by completely unexperienced
> individuals thrust into positions of management and power over others.
> It's
> going to get much worse before it gets better, that's why we have open
> source and people like you, for those who want to do it *right*. :)
>
>
> On Tue, Apr 15, 2014 at 5:59 AM, Caleb James DeLisle <cjd@???> wrote:
>
>> I totally forgive the guy who missed the bounds check, he made a human
>> mistake, we've all been there.
>> What I can't forgive is the culture which prides cryptic pointer
>> acrobatics
>> and eschews verification because "Good Programmers don't make mistakes".
>>
>> Thanks,
>> Caleb
>>
>>
>> On 04/15/2014 12:47 PM, jindq1 wrote:
>> > 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
>> >>
>> >
>> >
>> >
>> > _______________________________________________
>> > 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
>>
> _______________________________________________
> unSYSTEM mailing list: http://unsystem.net
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>