Sorry for ranting the list again but...

On 2014-05-14 19:17, andr...@itship.ch wrote:
> true, but then the leaking memory wouldn't have been restricted on
> critical data like private keys and password traffic. so more probing
> would have been necessary to gain exploitable data. which of course isn't
> better, but afaik the (bad) selfmade memory management somewhat
> accelerated the root bug.

Hm, I think I was wrong:

"Remember, |*payload*| is controlled by the attacker, and it's quite
large at 64KB.
If the actual |*HeartbeatMessage*| sent by the attacker only has a
payload of, say,
one byte, and its |*payload_length*| is a lie, then the above
|*memcpy()*| will read beyond
the end of the received |*HeartbeatMessage*| and start reading from the
victim
process's memory."
(http://www.theregister.co.uk/2014/04/09/heartbleed_explained/)



>
> Regarding testing, check out "John Hughes - Testing the Hard Stuff and
> Staying Sane":  http://www.youtube.com/watch?v=zi0rHwfiX1Q
> Summary (see http://en.wikipedia.org/wiki/QuickCheck ):
> Testing done with predefined behavior specification models, then the code
> to be tested gets called with random inputs and the result compared with
> the model by using the pattern matching system of Erlang. If the system
> finds a bug, it reruns the tests until it can reduce it to the minimal
> steps required to trigger the bug and delivers those as output.

Sounds lovely!
Great idea.



--------------090209010008000608030107
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Sorry for ranting the list again but...<br>
      <br>
      On 2014-05-14 19:17, <a class="moz-txt-link-abbreviated" 
href="mailto:andr...@itship.ch";>andr...@itship.ch</a> wrote:<br>
    </div>
    <blockquote
      cite="mid:52a2f948cd5525a5db370643f450f3e0.squir...@www.itship.ch"
      type="cite">
      <pre wrap="">
</pre>
      <pre wrap="">
true, but then the leaking memory wouldn't have been restricted on
critical data like private keys and password traffic. so more probing
would have been necessary to gain exploitable data. which of course isn't
better, but afaik the (bad) selfmade memory management somewhat
accelerated the root bug.</pre>
    </blockquote>
    <br>
    Hm, I think I was wrong:<br>
    <br>
    "Remember, <code><b>payload</b></code> is controlled by the
    attacker, and it's quite large at 64KB.<br>
    If the actual <code><b>HeartbeatMessage</b></code> sent by the
    attacker only has a payload of, say,<br>
    one byte, and its <code><b>payload_length</b></code> is a lie, then
    the above <code><b>memcpy()</b></code> will read beyond<br>
    the end of the received <code><b>HeartbeatMessage</b></code> and
    start reading from the victim<br>
    process's memory."
    (<a class="moz-txt-link-freetext" 
href="http://www.theregister.co.uk/2014/04/09/heartbleed_explained/";>http://www.theregister.co.uk/2014/04/09/heartbleed_explained/</a>)<br>
    <br>
    <br>
    <br>
    <blockquote
      cite="mid:52a2f948cd5525a5db370643f450f3e0.squir...@www.itship.ch"
      type="cite">
      <pre wrap="">

Regarding testing, check out "John Hughes - Testing the Hard Stuff and
Staying Sane":  <a class="moz-txt-link-freetext" 
href="http://www.youtube.com/watch?v=zi0rHwfiX1Q";>http://www.youtube.com/watch?v=zi0rHwfiX1Q</a>
Summary (see <a class="moz-txt-link-freetext" 
href="http://en.wikipedia.org/wiki/QuickCheck";>http://en.wikipedia.org/wiki/QuickCheck</a>
 ):
Testing done with predefined behavior specification models, then the code
to be tested gets called with random inputs and the result compared with
the model by using the pattern matching system of Erlang. If the system
finds a bug, it reruns the tests until it can reduce it to the minimal
steps required to trigger the bug and delivers those as output.</pre>
    </blockquote>
    <br>
    Sounds lovely!<br>
    Great idea.<br>
    <br>
    <br>
  </body>
</html>

--------------090209010008000608030107--
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to