Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spectre V1 safety #2

Closed
ghost opened this issue Apr 4, 2018 · 2 comments
Closed

Spectre V1 safety #2

ghost opened this issue Apr 4, 2018 · 2 comments

Comments

@ghost
Copy link

ghost commented Apr 4, 2018

Parsing any externally supplied data, such as SSL packets, can potentially expose application to Spectre V1 attacks. IMO. What's your stance on Spectre safety of your library?

@ymjing
Copy link
Contributor

ymjing commented Apr 4, 2018

Thanks for submitting the first issue for MesaLink! We are well aware of this issue and so is the Rust community. The Rust compiler is currently upgrading to LLVM 6, which has integrated the fix. See this merged PR.

IIUC you are supposing a remote attack with carefully crafted SSL packets. I would say it may succeed and trigger a leak to the cache on the remote machine. However, it would require local code execution privileges on the remote machine to read the leaked data and send them back. So Spectre v1 alone would not cause serious problems in this scenario.

But wait. What about public clouds? An attacker can do the same to a "remote" VM that resides in the same machine as the attacker. This is referred as a VM co-residence attack. Fortunately, most big name public cloud providers have deployed software mitigations to Spectre and Meltdown.

Hope that answers your question. At Baidu Security Lab we have several experts in this area. You might want to read Dr. Yueqiang Cheng's article Meltdown & Spectre Attacks and Mitigations.

@ghost
Copy link
Author

ghost commented Apr 5, 2018

Thanks for the reply!

The reason behind my question was two fold:

  1. Scenario where library such as mesalink is put inside SGX enclave. Here it's desired that local, even privileged attacker, should be unable to recover private key from enclave.
  2. Scenario where library such as mesalink is used by an application. Here it's desired that local unprivileged attacker, or privileged attacker in different VM, should be unable to recover private key.

SSL libraries have to parse externally provided BLOBs - SSL packets, certificates (locally provided or coming from SSL handshake), locally provided private key.
These BLOBs can be "corrupt", and potentially expose sensitive data - due to code that has been speculatively executed, but not commited. Through a variation on Spectre V1 attack where attacker doesn't necessarily share pagetable with the target.

Public cloud providers deployed mitigations primarily against Meltdown and Spectre V2. Hence my question.

Thanks for keeping side-channel attacks in mind during your development!

@ghost ghost closed this as completed Apr 5, 2018
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant