[Cryptography] [Crypto-practicum] Usable Security Based On Sufficient Endpoint-Specific Unpredictability

Ron Garret ron at flownet.com
Mon Oct 12 11:38:28 EDT 2015


[Administrative note: Ralf sent his reply to the wrong list.  His original post was sent to both cryptography at metzdowd.com and crypto-practicum at lists.sonic.net.  My response was sent only to the latter, but Ralf’s response was sent only to the former.  I’m sending this response to both.]

On Oct 12, 2015, at 2:22 AM, Ralf Senderek <crypto at senderek.ie> wrote:

> On Sun, 11 Oct 2015 22:41:27 Ron Garret writes:
> 
>> Heartbleed didn’t work by malware obtaining root read access,
>> it worked by taking advantage of a bug in some code running as root.
>> The exploiting code wasn’t even running on the same machine.
> 
> Exactly. And that makes it the perfect example to show that for
> a network attacker the disclosure of information he should never
> be able to get read access to and running arbitrary code as UID 0
> on the target machine is not the same thing and by no means
> equivalent. This is all about a realistic threat model.

OK, but then this doesn’t make sense:

> The idea is that a malware running on the user's behalf would not
> be able to produce this password unless it has execute permission as the
> root user.

The phrase “malware running on the user’s behalf” generally means malware that is running *on the same machine* where the secret is stored, and with the user’s (non-zero) UID.  So the code that took advantage of the heartbleed bug was not “malware running on the user’s behalf” because it was not running on the same machine.

In any event, I am still at a loss to understand the problem you are trying to solve and the solution you are proposing.  Heartbleed was just a bug in openssl.  It doesn’t matter what fancy games your secret keeping program plays with permissions or inode numbers; if it contains a bug that reveals the secret in response to a request that comes in over the network, then you lose.  It’s that simple.

rg



More information about the cryptography mailing list