4 ms·

The kernel is owned (or some part of the phone below the application level). The encryption only gets applied at the application level before the messages are s

The kernel is owned (or some part of the phone below the application level). The encryption only gets applied at the application level before the messages are sent down the wire. The interception happens prior to the encryption being applied. Think of it as a dongle on the wire between your keyboard and the computer. It doens't matter if the computer is secure - the message is intercepted prior to any encryption. This is, what I am assuming, has happened here. Edit: lots of stuff deleted for very valid criticism, as below.

dleslie 10y ago
I don't trust Google, Facebook, or anyone else who provides freemium services and has ties to the American Government. I don't understand why anyone does.
- Synaesthesia 10y ago
  It's funny, I trust Apple because they're not "freemium" as in, they make their profit elsewhere. But I'm not sure I should really! After all they did participate in PRISM AFAIK
GauntletWizard 10y ago
You're very much misrepresenting the facts. Android very much encrypts data (or gives users the option to, I'm not certain if it's the default). Chrome, the desktop application, does not. Why? Because that's a false sense of security. Chrome would have to also store the encryption key, and store it in the same place and under the same access controls as the encrypted data. This is not real protection. It is up to the user to not run malicious apps under the same security context as Chrome, and to encrypt their hard drive to protect their data at rest. Nothing that chrome can do in its security context is anything more than placebo - as shown by the fact that malware (and legitimate programs!) can read the Firefox local password database.
- libertymcateer 10y ago
  > Why? Because that's a false sense of security. Chrome would have to also store the encryption key, and store it in the same place and under the same access controls as the encrypted data. I hear you, but this is not the case with Safari. It offers secure local storage. It's the securesettings API. It uses the OS level encryption, and, based on the current state of play, this does not appear to be compromised. > as shown by the fact that malware (and legitimate programs!) can read the Firefox local password database. Is this also the case for Safari? I have not read anything to this effect.
  - mschuster91 10y ago
    > It uses the OS level encryption So all the NSA/CIA needs is a XNU kernel exploit which they need anyway for iPhone root exploits. Then, intercept the securesettings API or just do a raw memory dump of the browser process. And the NSA has another card they can play, and that way easier on Apple than on the fragmented Windows ecosystem: all the tiny chips on your motherboard (EC, or any chip on the PCI bus which has DMA) can read and parse the RAM. Given that there is a highly limited number of different Mac EC chips and even then Apple likely uses the same firmware across them, it's easier for CIA/NSA to develop an exploit for these and don't care about kernel at all.
  - GauntletWizard 10y ago
    I'll admit that the OSX Keychain has advantages - Offering OS-managed secure storage, with the possibility of the OS authenticating requests for credentials with the user is pretty cool. But as Chrome is cross-platform, and there's not standardized and similar APIs on Linux and Windows, I don't think it's the right move to have an OSX exclusive implementation that uses that api.
    - libertymcateer 10y ago
      > But as Chrome is cross-platform, and there's not standardized and similar APIs on Linux and Windows, I don't think it's the right move to have an OSX exclusive implementation that uses that api. That is a very fair point, which I will take into consideration.
md_ 10y ago
> Given Google's stance of not encrypting local storage in any way that I am aware of, this is fundamentally unsurprising. I have long been saying that Android is insecure and that storing passwords in Chrome is dangerous. ChromeOS and Android both implement FDE. There are some legitimate criticisms of (especially) the latter, voiced by e.g. Matthew Green, but you're just speaking nonsense here. There's very little value in per-app encryption on desktop OSes; it's security theater. I shudder to think of what your "secure communications" app does. I hope you're a good lawyer. ;)
- libertymcateer 10y ago
  I am not talking about ChromeOS - I am talking about the Chrome browser. Localstorage, last I checked, which was recently, is plaintext. > ChromeOS and Android both implement FDE Which is irrelevant if the runtime is compromised, which appears to be the case.
  - md_ 10y ago
    Let's be all Socratic here: Given a desktop OS like Windows that implements FDE like Bitlocker and runs a browser like Chrome, can you describe a hypothetical threat in which Chrome encrypting localstorage would prevent exploitation?
    - libertymcateer 10y ago
      Yes - worms or browsers that scan local data files without accessing the runtime of the parent application.
      - md_ 10y ago
        So your threat model is "malware which has access to memory containing plaintext but is written by idiots"? 0_o
        libertymcateer 10y ago
georgemcbay 10y ago
You don't even need to necessarily own the phone at the kernel level. Things like the Android AccessibilityService APIs are kind of a huge gaping issue if the app uses standard text controls without overriding the View.AccessibilityDelegate event handlers. Of course, this is a bit of a balancing act, because many disabled people legitimately benefit from the accessibility services, but they are like a huge vacuum from which displayed and entered textual data from your application can be sucked out.
daenney 10y ago
> Given Google's stance of not encrypting local storage in any way that I am aware of, this is fundamentally unsurprising How does not encrypting local storage relate to this story? You're just pulling that one out of thin air to somehow prove your point. Besides the fact that there is no correlation between encrypting local storage and intercepting keystrokes or more broadly owning the kernel, it's also false. Though there are concerns with how disk encryption is implemented in Android and there are ways around it, it's come with FDE since version 5.0. Encrypting local storage wouldn't have saved you one bit from this kind of thing where they just intercept the keystrokes. And your app wouldn't be safe from it either.
- libertymcateer 10y ago
  I agree. Wholeheartedly. The point, however, is that it belies Google's larger approach, including that they turned a browser into an operating system. Encrypting local storage would not have saved you. Absolutely. Maybe I am reading tea leaves, but it seems to me that this is indicative of the sort of security-lax mindset that allowed android to be owned. > And your app wouldn't be safe from it either. Yup. I know. It is a concern.

dleslie 10y ago

I don't trust Google, Facebook, or anyone else who provides freemium services and has ties to the American Government. I don't understand why anyone does.

Synaesthesia 10y ago
It's funny, I trust Apple because they're not "freemium" as in, they make their profit elsewhere. But I'm not sure I should really! After all they did participate in PRISM AFAIK

GauntletWizard 10y ago

You're very much misrepresenting the facts. Android very much encrypts data (or gives users the option to, I'm not certain if it's the default). Chrome, the desktop application, does not. Why? Because that's a false sense of security. Chrome would have to also store the encryption key, and store it in the same place and under the same access controls as the encrypted data. This is not real protection. It is up to the user to not run malicious apps under the same security context as Chrome, and to encrypt their hard drive to protect their data at rest. Nothing that chrome can do in its security context is anything more than placebo - as shown by the fact that malware (and legitimate programs!) can read the Firefox local password database.

libertymcateer 10y ago
> Why? Because that's a false sense of security. Chrome would have to also store the encryption key, and store it in the same place and under the same access controls as the encrypted data. I hear you, but this is not the case with Safari. It offers secure local storage. It's the securesettings API. It uses the OS level encryption, and, based on the current state of play, this does not appear to be compromised. > as shown by the fact that malware (and legitimate programs!) can read the Firefox local password database. Is this also the case for Safari? I have not read anything to this effect.
- mschuster91 10y ago
  > It uses the OS level encryption So all the NSA/CIA needs is a XNU kernel exploit which they need anyway for iPhone root exploits. Then, intercept the securesettings API or just do a raw memory dump of the browser process. And the NSA has another card they can play, and that way easier on Apple than on the fragmented Windows ecosystem: all the tiny chips on your motherboard (EC, or any chip on the PCI bus which has DMA) can read and parse the RAM. Given that there is a highly limited number of different Mac EC chips and even then Apple likely uses the same firmware across them, it's easier for CIA/NSA to develop an exploit for these and don't care about kernel at all.
- GauntletWizard 10y ago
  I'll admit that the OSX Keychain has advantages - Offering OS-managed secure storage, with the possibility of the OS authenticating requests for credentials with the user is pretty cool. But as Chrome is cross-platform, and there's not standardized and similar APIs on Linux and Windows, I don't think it's the right move to have an OSX exclusive implementation that uses that api.
  - libertymcateer 10y ago
    > But as Chrome is cross-platform, and there's not standardized and similar APIs on Linux and Windows, I don't think it's the right move to have an OSX exclusive implementation that uses that api. That is a very fair point, which I will take into consideration.

md_ 10y ago

> Given Google's stance of not encrypting local storage in any way that I am aware of, this is fundamentally unsurprising. I have long been saying that Android is insecure and that storing passwords in Chrome is dangerous. ChromeOS and Android both implement FDE. There are some legitimate criticisms of (especially) the latter, voiced by e.g. Matthew Green, but you're just speaking nonsense here. There's very little value in per-app encryption on desktop OSes; it's security theater. I shudder to think of what your "secure communications" app does. I hope you're a good lawyer. ;)

libertymcateer 10y ago
I am not talking about ChromeOS - I am talking about the Chrome browser. Localstorage, last I checked, which was recently, is plaintext. > ChromeOS and Android both implement FDE Which is irrelevant if the runtime is compromised, which appears to be the case.
- md_ 10y ago
  Let's be all Socratic here: Given a desktop OS like Windows that implements FDE like Bitlocker and runs a browser like Chrome, can you describe a hypothetical threat in which Chrome encrypting localstorage would prevent exploitation?
  - libertymcateer 10y ago
    Yes - worms or browsers that scan local data files without accessing the runtime of the parent application.
    - md_ 10y ago
      So your threat model is "malware which has access to memory containing plaintext but is written by idiots"? 0_o
      - libertymcateer 10y ago

georgemcbay 10y ago

You don't even need to necessarily own the phone at the kernel level. Things like the Android AccessibilityService APIs are kind of a huge gaping issue if the app uses standard text controls without overriding the View.AccessibilityDelegate event handlers. Of course, this is a bit of a balancing act, because many disabled people legitimately benefit from the accessibility services, but they are like a huge vacuum from which displayed and entered textual data from your application can be sucked out.

daenney 10y ago

> Given Google's stance of not encrypting local storage in any way that I am aware of, this is fundamentally unsurprising How does not encrypting local storage relate to this story? You're just pulling that one out of thin air to somehow prove your point. Besides the fact that there is no correlation between encrypting local storage and intercepting keystrokes or more broadly owning the kernel, it's also false. Though there are concerns with how disk encryption is implemented in Android and there are ways around it, it's come with FDE since version 5.0. Encrypting local storage wouldn't have saved you one bit from this kind of thing where they just intercept the keystrokes. And your app wouldn't be safe from it either.

libertymcateer 10y ago
I agree. Wholeheartedly. The point, however, is that it belies Google's larger approach, including that they turned a browser into an operating system. Encrypting local storage would not have saved you. Absolutely. Maybe I am reading tea leaves, but it seems to me that this is indicative of the sort of security-lax mindset that allowed android to be owned. > And your app wouldn't be safe from it either. Yup. I know. It is a concern.