9 ms·

But if you have arbitrary code execution on a MacBook, you probably have everything you want from that MacBook, because consumer desktop OSes and application so

But if you have arbitrary code execution on a MacBook, you probably have everything you want from that MacBook, because consumer desktop OSes and application software is insufficiently locked down to prevent you from getting everything you'd want. Escalating from arbitrary code execution to rooting the MacBook doesn't really increase its level of interesting to you. This is untrue for iOS, because iOS actually does have a pretty robust security model which has only-semi-trusted apps running on your skeleton key to everything.

toyg 8y ago
Ish. I think with a user process in OsX you don’t get passwords saved in keychain, which might well be what you are really after, these days.
- breatheoften 8y ago
  Does root access directly get you keychain credentials (or does it only get it via the possibility of key logging)?
  - acdha 8y ago
    In the past, you’d be able to read it out of the process memory when the keychain was unlocked. I believe that’s been locked down in the last couple of releases, however.
- dzhiurgis 8y ago
  How about all the other password managers, especially Chrome's?
  - toyg 8y ago
    It depends how well they are implemented (what is stored where, how it is stored and accessed, etc). It would be certainly trivial to grab the necessary files from a Chrome or Firefox profile, but if they are well-encrypted they could be practically uncrackable (although, as we know, that definition changes so fast these days). At that point it becomes about attacking or impersonating the actual process, which is not that easy - you might need another exploit for the app, or replacing the entire app without arising suspicion (a lot of apps are not even installed in the user profile, so this might well be impossible). In the end, it very much depends, but I don’t think it’s as trivial as some suggest - at least for mass-attacks/viruses, specific targeting is a different ballgame.
    - shhehebehdh 8y ago
      Nowadays I don’t think chrome even stores the passwords locally. Maybe for signed out users but it seems like all my passwords are stored at passwords.google.com.
      - pvg 8y ago
        It very much stores the passwords locally, even if you enable syncing. It wouldn't make sense for it not to.
  - ficklepickle 8y ago
    Gnome keyring was storing credentials in memory in plain text until very recently https://nvd.nist.gov/vuln/detail/CVE-2018-20781 https://nvd.nist.gov/vuln/detail/CVE-2018-20781
- geofft 8y ago
  With arbitrary code execution you can just wait around until the keychain is used and then grab it out of that process's memory, or prompt the user to unlock it with a convincing-sounding dialog, or whatever.
  - foota 8y ago
    Maybe I'm missing something, but reading something from another process' memory isn't a thing you can do, is it?
    - geofft 8y ago
      In general, for processes running as the same user on traditional desktop / server OSes (Windows, Mac, UNIX), it is. On mobile it's not because they had no backwards compatibility to care about (specifically, iOS applies heavy sandboxing to apps and Android runs them as different Linux user IDs). And desktop app stores are moving towards the same model. On Linux, SELinux/AppArmor/etc. might also prevent this depending on config. More fundamentally, an unsandboxed process can do things like set environment variables, update config files, modify applications installed into the user's home directory, read your browser cookies, etc. as a consequence of traditional desktop apps having unrestricted access to the user's home directory, so preventing reading memory doesn't really prevent one app from attacking another.
      - foota 8y ago
        Huh. Thanks, I'm surprised I didn't know that.
        JoeSmithson 8y ago
        I don't think that's true at all, not since like Win95 days at least... Perhaps I'm also completely misinformed or misunderstanding what GP is saying but each process is meant to get it's own virtual address space
        8y ago
kbenson 8y ago
> But if you have arbitrary code execution on a MacBook, you probably have everything you want from that MacBook You probably have all the locally available data you could want. You may not have access to passwords, or other data that comes from actively using an online site which doesn't currently have active credentials (because they time them out or the user logged out previously). For example, depending on the person and the documents they keep locally, you might not have access to any banking information. Privilege escalation opens up a whole slew of capabilities that make it much easier to achieve that, not to mention allowing a rootkit to get access back immediately after a reboot. Local account exploits are like a burgler breaking in (even repeatedly) while you aren't home. Privilege escalation is like them installing a remote camera system and recording your every action while you are home. Both are pretty horrible, but certain things are much more likely to be exposed with active monitoring of what you are doing over extended periods...

toyg 8y ago

Ish. I think with a user process in OsX you don’t get passwords saved in keychain, which might well be what you are really after, these days.

breatheoften 8y ago
Does root access directly get you keychain credentials (or does it only get it via the possibility of key logging)?
- acdha 8y ago
  In the past, you’d be able to read it out of the process memory when the keychain was unlocked. I believe that’s been locked down in the last couple of releases, however.
dzhiurgis 8y ago
How about all the other password managers, especially Chrome's?
- toyg 8y ago
  It depends how well they are implemented (what is stored where, how it is stored and accessed, etc). It would be certainly trivial to grab the necessary files from a Chrome or Firefox profile, but if they are well-encrypted they could be practically uncrackable (although, as we know, that definition changes so fast these days). At that point it becomes about attacking or impersonating the actual process, which is not that easy - you might need another exploit for the app, or replacing the entire app without arising suspicion (a lot of apps are not even installed in the user profile, so this might well be impossible). In the end, it very much depends, but I don’t think it’s as trivial as some suggest - at least for mass-attacks/viruses, specific targeting is a different ballgame.
  - shhehebehdh 8y ago
    Nowadays I don’t think chrome even stores the passwords locally. Maybe for signed out users but it seems like all my passwords are stored at passwords.google.com.
    - pvg 8y ago
      It very much stores the passwords locally, even if you enable syncing. It wouldn't make sense for it not to.
- ficklepickle 8y ago
  Gnome keyring was storing credentials in memory in plain text until very recently https://nvd.nist.gov/vuln/detail/CVE-2018-20781 https://nvd.nist.gov/vuln/detail/CVE-2018-20781
geofft 8y ago
With arbitrary code execution you can just wait around until the keychain is used and then grab it out of that process's memory, or prompt the user to unlock it with a convincing-sounding dialog, or whatever.
- foota 8y ago
  Maybe I'm missing something, but reading something from another process' memory isn't a thing you can do, is it?
  - geofft 8y ago
    In general, for processes running as the same user on traditional desktop / server OSes (Windows, Mac, UNIX), it is. On mobile it's not because they had no backwards compatibility to care about (specifically, iOS applies heavy sandboxing to apps and Android runs them as different Linux user IDs). And desktop app stores are moving towards the same model. On Linux, SELinux/AppArmor/etc. might also prevent this depending on config. More fundamentally, an unsandboxed process can do things like set environment variables, update config files, modify applications installed into the user's home directory, read your browser cookies, etc. as a consequence of traditional desktop apps having unrestricted access to the user's home directory, so preventing reading memory doesn't really prevent one app from attacking another.
    - foota 8y ago
      Huh. Thanks, I'm surprised I didn't know that.
      - JoeSmithson 8y ago
        I don't think that's true at all, not since like Win95 days at least... Perhaps I'm also completely misinformed or misunderstanding what GP is saying but each process is meant to get it's own virtual address space
        8y ago

kbenson 8y ago

> But if you have arbitrary code execution on a MacBook, you probably have everything you want from that MacBook You probably have all the locally available data you could want. You may not have access to passwords, or other data that comes from actively using an online site which doesn't currently have active credentials (because they time them out or the user logged out previously). For example, depending on the person and the documents they keep locally, you might not have access to any banking information. Privilege escalation opens up a whole slew of capabilities that make it much easier to achieve that, not to mention allowing a rootkit to get access back immediately after a reboot. Local account exploits are like a burgler breaking in (even repeatedly) while you aren't home. Privilege escalation is like them installing a remote camera system and recording your every action while you are home. Both are pretty horrible, but certain things are much more likely to be exposed with active monitoring of what you are doing over extended periods...