openssh unix dev - Jan 2016 - Use |mprotect()| to secure key data ? / was: Re: Proposal: always handle keys in separate process

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;)

On Wed, Jan 20, 2016 at 01:53:41AM +0100, Roland Mainz
wrote:
> 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).
Serious question: how many small embedded machines that can't afford
another process are running openssh vs dropbear server?

-- 

rgds
Stephen

On Tue 2016-01-19 19:53:41 -0500, Roland Mainz wrote:
> 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) ...
depending on the filesystem used, this could mean writing this sensitive
data to the underlying storage medium, which sounds like a worse failure
than anything this proposal would fix.

     --dkg

Hi,

On Wed, Jan 20, 2016 at 01:53:41AM +0100, Roland Mainz
wrote:
> >> any performance impact if the code is switched to plain {
|open()|,
> >> |read()|, ... } (with sufficient wrappers for |EINTR| handling) ?
> 
> 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).
Actually, "open(), read(full file size), close()" is *less* overhead
than
mixing in an extra stdio layer.  Of course what you don't want to do is
single-byte-read()s then...

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at
greenie.muc.de
fax: +49-89-35655025                        gert at
net.informatik.tu-muenchen.de

On 20 January 2016 at 03:10, Daniel Kahn Gillmor <dkg at
fifthhorseman.net> wrote:
> On Tue 2016-01-19 19:53:41 -0500, Roland Mainz wrote:
>> 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) ...
>
> depending on the filesystem used, this could mean writing this sensitive
> data to the underlying storage medium, which sounds like a worse failure
> than anything this proposal would fix.
>
>      --dkg
Why? Kernel paging/swaping would do the same, and you can force that
paging/swaping to a file in a trusted env and still get user data you
are not supposed to obtain. That's even an old trick tiger teams used
5 years ago to demonstrate that using Linux for sensitive data storage
at CEA Saclay isn't wise.

Ced
-- 
Cedric Blancher <cedric.blancher at gmail.com>
Institute Pasteur