From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 border2.nntp.dca3.giganews.com!backlog4.nntp.dca3.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!eu.feeder.erje.net!newsfeed.freenet.ag!takemy.news.telefonica.de!telefonica.de!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Wed, 23 Apr 2014 10:06:36 +0200
From: Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: OpenSSL development (Heartbleed)
References: <-OGdnezdYpRWFc_OnZ2dnUVZ_vednZ2d@giganews.com>
 <535297f1$0$6715$9b4e6d93@newsspool3.arcor-online.net>
 <op.xekmrhmiule2fv@cardamome>
 <5352a585$0$6707$9b4e6d93@newsspool3.arcor-online.net>
 <lj4ath$c6i$1@loke.gir.dk>
 <535688a0$0$6721$9b4e6d93@newsspool3.arcor-online.net>
 <19mxjybev4fc9.1fkxznem326v8$.dlg@40tude.net> <lj671n$bj6$1@dont-email.me>
 <1ottu3pw9hxl1.i1h7v3r51vk0.dlg@40tude.net>
 <slrnlleked.i0l.lithiumcat@nat.rebma.instinctive.eu>
 <6xpjk44lobfz.fctt93m75u47$.dlg@40tude.net>
In-Reply-To: <6xpjk44lobfz.fctt93m75u47$.dlg@40tude.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <5357748c$0$6700$9b4e6d93@newsspool2.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 23 Apr 2014 10:06:36 CEST
NNTP-Posting-Host: ee96003c.newsspool2.arcor-online.net
X-Trace: DXC=nbSeK7I]S2>gP]QSEBQ^d4A9EHlD; 3Yc24Fo<]lROoR18kF<OcfhCO;
 RL[?1iOKGN8PCY\c7>ejV8<0O3ncWeXZ<P1@IcoP?eX0
X-Complaints-To: usenet-abuse@arcor.de
X-Original-Bytes: 3620
Xref: number.nntp.dca.giganews.com comp.lang.ada:186016
Date: 2014-04-23T10:06:36+02:00
List-Id: <comp.lang.ada>

On 23/04/14 09:30, Dmitry A. Kazakov wrote:

>>> Boundary checks or not, the transport layer shall have no access to the
>>> server data.
>>>
>>> A tightly coupled system is vulnerable. If compromising just one component
>>> opens all gates wide, that is a bad standard and bad design. The effects of
>>> errors and faults must be bounded per design.
>>
>> How would you design a transport layer that has no access to whatever is
>> supposed to be transported?
>>
>> "Heartbleed" didn't leak any data that ins't legitimataly needed by
>> OpenSSL (i.e. transported data and/or transport parameters (like keys))
>
> I heard it leaked user data, I didn't go into details. I hope user data are
> not transported, because otherwise that would be even an greater design
> fault.

They are not, by design, transported. I think the issue
boiled down to using some int variable `p' as an offset without
checking bounds. OpenSSL sometimes uses its own malloc,
for historical reasons. So, perhaps this approximates.

At least GNAT warns, no matter what. What do other compiler
diagnose?

with System.Storage_Elements;  use System.Storage_Elements;
with Ada.Integer_Text_IO;

procedure Leak is
    type A is array (Integer range <>) of Storage_Element;
    type A_P is access all A;

    Pool : A (1 .. 123_456);
    for Pool'Address use To_Address (16#100_000#);
    Current_Offset : Storage_Offset := 0;

    function Our_Own_Malloc (Size : Natural) return A_P is
       Result : A_P;
       for Result'Address use Pool'Address + Current_Offset;
    begin
       Current_Offset := Current_Offset + Storage_Offset (Size);
       return Result;
    end Our_Own_Malloc;

    function Something (P : Integer) return A is
       Result : A_P;
    begin
       Result := Our_Own_Malloc (P);
       return Result.all;
    end Something;

    use Ada.Integer_Text_IO;
    I : Integer;
begin
    Get(I);
    declare
       Y : A := Something (I);
    begin
       null;
    end;
end Leak;