full-disclosure - Re: [FD] heartbleed OpenSSL bug CVE-2014-0160

Open Source and information security mailing list archives

Date: Fri, 11 Apr 2014 12:21:40 -0300
From: Ricardo Iramar dos Santos <riramar@...il.com>
To: "fulldisclosure@...lists.org" <fulldisclosure@...lists.org>
Subject: Re: [FD] heartbleed OpenSSL bug CVE-2014-0160

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'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@...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/

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives