Raphael S. Carvalho
2018-Jan-06 19:29 UTC
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.
Philipp Marek
2018-Jan-06 19:38 UTC
PEM file opened without DIRECT I/O which makes private key readable by attacker exploiting MELTDOWN
> I think we are possibly interested in switching to DIRECT IO (given > that it > bypasses any caching system including page cache) when reading *.PEM > fileSorry, 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".
Raphael S. Carvalho
2018-Jan-06 19:57 UTC
PEM file opened without DIRECT I/O which makes private key readable by attacker exploiting MELTDOWN
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.
Seemingly Similar Threads
- PEM file opened without DIRECT I/O which makes private key readable by attacker exploiting MELTDOWN
- C6 KPTI cpuinfo flag?
- [RFC PATCH V2 5/5] vhost: access vq metadata through kernel virtual address
- [RFC PATCH V2 5/5] vhost: access vq metadata through kernel virtual address
- [RFC PATCH V2 5/5] vhost: access vq metadata through kernel virtual address