this post was submitted on 22 Mar 2024
625 points (98.9% liked)

Technology

55715 readers
5725 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related content.
  3. Be excellent to each another!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, to ask if your bot can be added please contact us.
  9. Check for duplicates before posting, duplicates may be removed

Approved Bots


founded 1 year ago
MODERATORS
 

The attack has been dubbed GoFetch: https://gofetch.fail/

you are viewing a single comment's thread
view the rest of the comments
[–] GlitterInfection@lemmy.world 2 points 3 months ago (1 children)

Doesn't it require a separate process to be using the cryptographic algorithm in the first place in order to fill the cache in question?

If it's done in-process of a malicious app that you're running, why wouldn't the app just steal your password and avoid all of this in the first place?

An efficient and fast version of this in Javascript would be worrisome. But as-is it's not clear if this can be optimized to go faster than 1-2 uninterrupted hours of processing, so hopefully that doesn't end up being the case.

[–] _dev_null@lemmy.zxcvn.xyz 1 points 3 months ago

Doesn’t it require a separate process to be using the cryptographic algorithm in the first place in order to fill the cache in question?

Yes, that's my understanding. I haven't looked at the code, but their high level explanation sounds like their app is making calls to an API which could result in the under-the-hood crypto "service" pulling the keys into the cache, and there's an element of luck to whether they snag portions of the keys at that exact moment. So it seems like the crafted app doesn't have the ability to manipulate the crypto service directly, which makes sense if this is only a user-land app without root privileges.

why wouldn’t the app just steal your password and avoid all of this in the first place?

I believe it would be due to the app not having root privileges, and so being constrained with going through layers of abstraction to get its crypto needs met. I do not know the exact software architecture of iOS/macOS, but I guarantee there's a notion of needing to call an API for these types things. For instance, if your app needs to push/pull an object it owns in/out of iCloud, you'd call the API with a number of arguments to do so. You would not have the ability to access keys directly and perform the encrypt/decrypt all by yourself. Likewise with any passwords, you would likely instead make an API call and the backing code/service would have that isolated/controlled access.