openssh unix dev - Jan 2018 - PEM file opened without DIRECT I/O which makes private key readable by attacker exploiting MELTDOWN

Hi everyone out there,

I just found out that ssh command doesn't use DIRECT IO to open *.pem,
which means private key goes to page cache, which means attacker may
exploit meltdown to discover user's private key. I may come up with a POC
for that if anybody is interested, I'm basing my work on the tool I created
for checking whether system is vulnerable by exploiting MELTDOWN, follow
it: https://github.com/raphaelsc/Am-I-affected-by-Meltdown

Check strace output when connect to instance via ssh:
open("/home/utroz/.ssh/raphaelsc_aws.pem", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0400, st_size=1696, ...}) = 0
read(4, "-----BEGIN RSA PRIVATE KEY-----\r"..., 4096) = 1696
close(4)

I think we are possibly interested in switching to DIRECT IO (given that it
bypasses any caching system including page cache) when reading *.PEM file
to prevent something like this from ever happening in the future. It turns
out we can't rely on processors anymore to secure our data safely, even
though Linux will be now safe after KAISER patchset, but users may have it
disabled or mistakenly run a unpatched kernel.

I'm interested in writing a patch for that, if you guys want me to. I'd
need directions on where to look at (searching it in the source code
now...) and where to send the patch to. That's going to be my first patch
for the project, and I'd be really happy about doing it.

Regards,
Raphael Carvalho.

> I think we are possibly interested in switching to DIRECT IO (given 
> that it
> bypasses any caching system including page cache) when reading *.PEM 
> file
Sorry, but this makes no sense.
The data could just as well be read from the SSH process
memory space.

Direct IO has some additional complexity; this may well
be avoided.


It makes *zero* sense to panic now and start "hardening"
[which direct IO wouldn't even be!] individual programs -
if separate memory spaces are not available,
    "all hope is lost".

On Sat, Jan 6, 2018 at 5:38 PM, Philipp Marek <philipp at marek.priv.at>
wrote:
> I think we are possibly interested in switching to DIRECT IO (given that it
>> bypasses any caching system including page cache) when reading *.PEM
file
>>
> Sorry, but this makes no sense.
> The data could just as well be read from the SSH process
> memory space.
>
I think that's actually not true. SSH process's stack and heap
aren't
mapped/stored into the kernel space mapped in all user space programs, so
how come a malicious program running in victim's system could have access
to stack/heap memory of SSH process which is only mapped in its address
space? Please correct me if I'm wrong.

>
> Direct IO has some additional complexity; this may well
> be avoided.
>
Actually, it's only about adding a flag to open and making sure IO is DMA
aligned.

>
>
> It makes *zero* sense to panic now and start "hardening"
> [which direct IO wouldn't even be!] individual programs -
> if separate memory spaces are not available,
>    "all hope is lost".
>
I agree with this sentiment though, better to think it through and come up
with informed decisions, but I think this is possibly a direction worth
considering.