Re: heartbleed OpenSSL bug CVE-2014-0160

[Ricardo Iramar dos Santos <riramar () gmail com>]

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 () gmail com> wrote:

> Reading this post
> http://vrt-blog.snort.org/2014/04/heartbleed-memory-disclosure-upgrade.htmlit's saying "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 () coredump 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/