Known security issues

[mkow]

This issue lists known security problems with Graphene. Everything we're aware of but didn't have time to fix yet should be listed here. We'll also need to resolve all of them before we can say we're ready for production.

I'll try to keep this list up-to-date.

Critical: (checked means "already fixed on master")

• Security audit of the old code - we do security reviews of newly created code, but there's a lot of old code which was never properly audited.
• Audit of defaults and their security implications - We must ensure that it's not possible to use Graphene insecurely by an accident because we had some insecure defaults (or misleadingly named options).
  Update: @mkow did the review and made some fixups in [Docs] Ensure that insecure options are clearly marked as such  graphene#2454.
• Better sanitization of CPU topology information in sysfs ([LibOS/PAL] Sanitize /sysfs pseudo filesystem graphene#2105) - We forward a lot of information from untrusted host to the user application with only partial sanitization. User app may trust this data, as it thinks they are coming from the trusted OS kernel and so have exploitable bugs in the parsing logic.
  Update: This feature was hid under a feature flag and will be re-enabled after we implement proper sanitization. See [Pal,LibOS] Disable sysfs topology by default #135.
• Finish rework of the logging system. Right now we leak some secrets in error messages even in release builds, we need to carefully censor them.
  Update: Done in Strip confidential information from logs on "error" level (minimal version) graphene#2497.
• Review OCALL interface security.
• Cryptography review of protected files implementation. We don't have professional cryptographers on the team, so the implementation still needs to be verified.
• Cryptography review of attestation-related code (SGX-only).
• Fix all known memory corruption bugs in Graphene (IPC subsystem, I'm looking at you!). Done after IPC rework.
• Review all TODOs and XXXes in the codebase and verify if any of them is security-relevant.
  Update: Done by @boryspoplawski with some consulting help from other maintainers.
• Review low-level SGX entry code. See gramineproject/graphene#292, [Linux-SGX PAL] Untrusted signal number during signal handling is not verified graphene#598 and Review exception handling for proper handling of nesting graphene#637.
  All known issues were fixed (see [Pal/Linux-SGX] Detect signal stack overflow in "enclave_entry.S" #108). We should be fine for now, but we plan to rewrite this code anyways, to have more confidence in it :)
• Sanitize VMID (Graphene internal process ID). See [Pal/Linux-SGX] Sanitize VMID graphene#2087.

Probably not-so-critical: (or rather: we don't know any app which would be vulnerable because of these)

• CPUID sanitization (Iago attacks on CPUID graphene#966) - currently we sanitize everything we know may lead to corruptions in users' apps (like xsave area sizes), but maybe there are more dangerous cpuid leaves? We also allow the values to change in time in some cases, which is usually impossible on real hardware.
• There are tons of subtle attack angles related to differences between the upstream Linux API and what we actually implement or can support on a specific backend. E.g. on SGX1 we can't change memory permissions, so everything is RWX, or that we support flag X but not flag Y in some syscalls (while in Linux support for X implies support for Y). It's quite hard for me to imagine a real-world application which would rely on such things for its correctness (and I mean correctness, not exploitability if another bug is present), but it's still worth noting that such a possibility exists.
• Time readings may be easily spoofed, but unless we won't allow it going backwards then it's hard to imagine an application exploitable by changing system time. There may be some issues with TLS certificate validation logic in applications (e.g. the attacker shifts back time and shows an old, leaked cert for some domain). I guess users would need to ship the applications with a reasonably up-to-date revocation lists?

Update: I moved the hardening ideas to a separate issue: #54.

[Glenrun]

@mkow hello, is the security audit done by external security expert?

[mkow]

Hi, depends what do you mean by "external". There were some non-gramine-developers doing parts of it, but they were employed by a company involved in this project. And some parts were done by the maintainers.