Roland Mainz
2016-Jan-19 23:18 UTC
Use |mprotect()| to secure key data ? / was: Re: Proposal: always handle keys in separate process
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) ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
Ángel González
2016-Jan-20 00:41 UTC
Use |mprotect()| to secure key data ? / was: Re: Proposal: always handle keys in separate process
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. Best regards
Ángel González
2016-Jan-20 00:42 UTC
Use |mprotect()| to secure key data ? / was: Re: Proposal: always handle keys in separate process
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. Best regards
Roland Mainz
2016-Jan-20 00:53 UTC
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;)