On Wed, Jan 20, 2016 at 1:42 AM, Ángel González <keisial@xxxxxxxxx> wrote:
> On 20/01/16 00:18, Roland Mainz wrote:
>> On Tue, Jan 19, 2016 at 11:53 PM, Ángel González<keisial@xxxxxxxxx>
>> 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@xxxxxxxxxxx
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
