Use |mprotect()| to secure key data ? / was: Re: Proposal: always handle keys in separate process

[Roland Mainz]

On Wed, Jan 20, 2016 at 1:42 AM, Ángel González <keisial at gmail.com> wrote:
> On 20/01/16 00:18, Roland Mainz wrote:
>> On Tue, Jan 19, 2016 at 11:53 PM, Ángel González<keisial at gmail.com>
>> wrote:
>>>
>>> That won't work when the data was recovered because it was read inside
>>> a stdio buffer which was not overwritten before being freed.
>>
>> Why is stdio used in such a security-sensitive area anyway ? Is there
>> any performance impact if the code is switched to plain { |open()|,
>> |read()|, ... } (with sufficient wrappers for |EINTR| handling) ?
>
> Probably not, and in fact I would favor changing it.
>
> I was just pointing out that the private key leak was not in OpenSSH
> buffers,
> which were properly zeroed, but from things like the use of stdio buffers.
>
> Your proposal may be an hardening oportunity, but is not a final solution.
> For that, a different process would be preferable.

Well, I am not happy with the solution because it adds *lots* of extra
overhead (not noticeable on today's multi-GHz desktop machines but on
small embedded machines this bites back).

What about the idea of storing "valuable" data in unlinked temp files
and |mmap()| then only on demand ? That would keep them out of the
claws of *other* users (obviously same user can use /proc/$pid/fd/$fd
to |open()| such files, but then the same user could just attach
gdb/dbx and dissect the ssh/sshd/ssh_secure_storage processes and even
inject random code) ...

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)