Vulnerability GoFetch could be a big problem for crypto self custody on own device

I bought a MBA M3 15” 24GB/1TB two weeks ago.

Today is the 14th day and I pulled the trigger (in the other direction).

Believe me, it is an impressive machine, the best laptop in the world probably.

The GoFetch vulnerability scared me, but what forced me to return is how the vulnerability has been managed from Apple: just silence.

Apple has been informed on 5th of December about it. No real comments about it right now.

If you do not know GoFetch please read the details about it, just search “GoFetch vulnerability”.

I made my own research a lot and I would like to share my knowledge about information that are difficult to find or understand immediately:

• This is a new vulnerability, the paper is new and not peer reviewed but the authors are reliable experts
• The risk is considered low right now
• The vulnerability is theoretically VERY bad
• In the real world it could be nothing or a disaster, we still do not know if the research was conducted on Linux Asahi or MacOS Sonoma. If the former than it could be a no issue for Sonoma
• The research was conducted with a quiet environment in the L2, could it work on a normal device in normal activity?
• It is fake news that physical control of the machine is needed, it could theoretically happen remotely, theoretically through Java Scripts visiting a website. Theoretically because like already said, it is not known exactly what are the precise limits and conditions. But these vectors can not be excluded either!
• User privileges are enough, Admin/Root is NOT needed.
• The issue involves the private keys, but this might be just the appetizer. The original paper itself explains that every cached information could be – again, theoretically – fetched.
• The research ran on M1 Chips, but is reasonable to speculate that M2 and M3 are involved as well.
• In this case the M1+M2 have a different mitigation as M3, maybe a less efficient on. The consequence of these mitigations is a loss in performance but it is not known how much thus if it is relevant.
• If the problem is real (read above) and therefore a mitigation is needed, then the loss in performance is probably very acceptable in order to protect the private keys on M3 BUT (!) the software developers must independently employ the mitigation, as there is not – right now – a system patch through Apple.
• In order to protect the private keys there should be mitigations on M1+M2 as well (run the encryption through the efficiency cores only) but they are more difficult to implement. In oder to protect just the private keys, then the performance should not be impacted too much on M1+M2 too.
• If the attack goes public and mainstream and it works good on MacOS, remotely through JavaScripts and with a noisy L2 and without much knowledge and control about what is running on the system… if, if, if… then the far west is coming.
• In this worst case scenario, it should be then always possible to protect the private keys somehow, but it will never be possible to protect all fetchable informations without a HUGE performance impact, (possibly on M3 as well!).

Therefore there is a real possibility that the M3 devices experience longevity problems in the next years.

TL;DR: A lot of “theoretically”, “if”, “possibly”… the situation is still very unclear, potentially very bad. Hence my decision to 1. Return 2. Wait 3. More DYOR