Message-ID: <CAO-d6_9GAF0D_o+eRq6L6Y2dCjKsK8WrRypepgRP4V2aVBkJXw@mail.gmail.com>
Date: Fri, 11 Apr 2014 12:36:57 -0500
From: HaCKsPy <hackspy@...il.com>
To: "fulldisclosure@...lists.org" <fulldisclosure@...lists.org>
Subject: Re: [FD] heartbleed OpenSSL bug CVE-2014-0160

Cloudfare has also open a challenge about heartbleed. You can found at:

https://www.cloudflarechallenge.com/heartbleed

Regards,

Juan Pablo.


On Fri, Apr 11, 2014 at 10:21 AM, Ricardo Iramar dos Santos <
riramar@...il.com> wrote:

> I think that I found the answer for my question on the RFCs 6520 on page 5
> (
> https://tools.ietf.org/html/rfc6520#page-5) and 6066 page 8 (
> https://tools.ietf.org/html/rfc6066#page-8).
> Take a look on the RFC6520 on page 5:
>
>      The total length of a HeartbeatMessage MUST NOT exceed 2^14 or
> max_fragment_length when negotiated as defined in [RFC6066].
>
> Now let's take a look on RFC6066 page 8:
>
>      Without this extension, TLS specifies a fixed maximum plaintext
> fragment length of 2^14 bytes.  It may be desirable for constrained clients
> to negotiate a smaller maximum fragment length due to memory limitations or
> bandwidth limitations.
>
> I think the idea to have the client setting a SMALLER length is just for in
> case of memory or bandwidth limits.
> I had this in my mind because if there wasn't a reasonable explanation for
> the client set the length it could be that the developer malicious
> intention to include this bug. Anyway, I was thinking wrong since we have
> the reason on the RFCs.
>
> Thanks
> Ricardo Iramar
>
>
> On Fri, Apr 11, 2014 at 12:09 AM, Ricardo Iramar dos Santos <
> riramar@...il.com> wrote:
>
> > Reading this post
> >
> http://vrt-blog.snort.org/2014/04/heartbleed-memory-disclosure-upgrade.htmlit'ssaying "This is the length indicated by the SSL client for the
> > heartbeat payload".
> > Why the client should set the length of a payload? Why not have a fix or
> > some values? Sorry but I'm a not C developer and I didn't get the idea of
> > this.
> >
> > "Finally (and here's the critical part), using the size supplied by the
> > attacker rather than its actual length, it copies the request payload
> bytes
> > to the response buffer."
> >
> >
> > On Thu, Apr 10, 2014 at 9:17 PM, Michal Zalewski <lcamtuf@...edump.cx
> >wrote:
> >
> >> >
> >>
> http://m.smh.com.au/it-pro/security-it/man-who-introduced-serious-heartbleed-security-flaw-denies-he-inserted-it-deliberately-20140410-zqta1.html
> >>
> >> "Man who introduced serious 'Heartbleed' security flaw denies he
> >> inserted it deliberately"
> >>
> >> Wow, we're climbing to some new levels here.
> >>
> >> /mz
> >>
> >> _______________________________________________
> >> Sent through the Full Disclosure mailing list
> >> http://nmap.org/mailman/listinfo/fulldisclosure
> >> Web Archives & RSS: http://seclists.org/fulldisclosure/
> >>
> >
> >
>
> _______________________________________________
> Sent through the Full Disclosure mailing list
> http://nmap.org/mailman/listinfo/fulldisclosure
> Web Archives & RSS: http://seclists.org/fulldisclosure/
>



-- 
==========================



|_|0|_|   Ing. Juan Quiñe, CISSP, GISP, ISO 27001 LA, OSCP, Cobit
Foundations
|_|_|0|   visita: http://hackspy.blogspot.com
|0|0|0|   suscribete a: http://groups.google.com/group/swp-scene
a.k.a. HaCKsPy - Security Wari Projects now PeruSEC

"... hacking and learning is a way to live your life, not a day job or
semi-ordered list of instructions found in a thick book. ..."
Anthony Bunyan

"...Romper un sistema de seguridad los acerca tanto a ser hackers como
encender autos puenteando los convierte en ingenieros automotrices..."

"...Live as if you will die tomorrow but learn as if you will live
forever..."
Mahatma Gandhi

"NADA ES TAN IMPORTANTE, NI TAN URGENTE QUE NO PUEDA SER HECHO CON
SEGURIDAD"  Anónimo

"El mejor ataque es aquel que aun siendo previsto por el oponente no puede
ser evitado"

_______________________________________________
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists