Add "Pentimento: Data Remanence in Cloud FPGAs"

[0xdabbad00]

This issue was validated on AWS but seems likely to impact any cloud provider that offers FPGAs. https://arxiv.org/pdf/2303.17881.pdf

The issue is sort of a side channel for seeing the data of customers that previously used an FPGA.

This issue raises a number of questions.

• What cloud provider(s) should we associate with this? Should we add multiple cloud providers (basically all of them) or just the one that was validated to be impacted (AWS)?
• This is a sort of cross-tenant issue, but it's unclear what all the limitations might be, as the researchers didn't seem to indicate any, other than the attacker needs to end up acquiring an FPGA that was previously and recently used by a victim. This issue is most similar to the AMI issue where files could be recovered, which we marked as low severity: https://github.com/wiz-sec/open-cvdb/blob/main/vulnerabilities/ami-recoverable-files.yaml

[korniko98]

1. I think we should only mention AWS since it's technically possible the issue doesn't exist in other CSPs.
2. In my opinion this should be low if only because the impact is highly dependent on circumstance and is sort of random (an attacker can't normally preselect a specific target VM, they'd have to be very lucky - correct?).

[0xdabbad00]

I think the "impact" of the theoretical success of the attack is possibly critical in that using an AWS services mean an attacker can see your data, but the "likelihood" is where I'm most unclear. If an attacker can just constantly try spinning up F1 instances and if they had 100% success in recovering all of the data on it, then that is very bad. But the question here to me is how successful can an attacker be in recovering that data? In the AMI issue, you were only impacted if you purposefully made your AMI public, and so you should have already had some expectation that you shouldn't be putting private data on an image you plan to make public, even if you deleted it. In this case, just like any other EC2 instance, you have an expectation that your data you put on it is not recoverable.

An important requirement for this attack is:

it can allow an attacker who knows a non-secret “skeleton” (the physical structure, but not the contents) of the victim’s design

I don't know if it is common to know that for FPGAs (ie. are there are only a few common skeletons out there?), but that seems like a very big ask.

Next, how much data can be recovered? It makes mention of "64 routes", so I think this is the equivalent of saying a 64 bit value is being recovered, but I'm not sure, as some of the statements seem to indicate only a single bit is being recovered.

Next, how often are they able to successfully recover the data? I can't tell if they are always successful or were successful once or what is happening.

Next, are there any other limitations? They mention performing a 200 hour burn-in, prior to the attacks, but I'm not clear if it common to use an FPGA in that way.

Given this uncertainty, I'm fine giving it a severity of Low and bumping that up later if it becomes apparent that we misunderstood it. I'd rather give it a lower severity and raise it if we misunderstood it, rather than giving it a higher severity and lowering it later.

I'm also fine mentioning this only impacts AWS and extending that later if it becomes clear other cloud providers are impacted.