[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