4 ms·

tl;dr: this is stupid. People seem to love analyzing security of tiny corners of systems while ignoring the rest of the system, and entirely avoiding figuring

tl;dr: this is stupid. People seem to love analyzing security of tiny corners of systems while ignoring the rest of the system, and entirely avoiding figuring out a scope for the security. The post complains about Signal using a Google service, that Google could utilize (either now or through an update) for malicious activity. A Google service that without a fair share of poking around is only available on Google versions of Android. I mean, what. While this is a more serious problem than the usual whine about GCM (Yes, notifications can give a lot of info, but in case of Signal, the info given is "You received something from some Signal user while you were offline"), it is still amazing how blind the analysis seem to the environment. If you cannot trust Google to provide a "non-evil" Google play services, why the flying fuck do you think the Google-provided (or manufacturer-under-tight-google-control-provided) OS is fine? They could backdoor the process isolation and poke around at Signal memory if they felt like it. Now, if you are security conscious and willing to let go of the conveniences of selling your soul to Google, you would be running a non-Google'd version of Android without Google services. Your only valid complaint in this case, is that Signal depends on Google services to operate, which makes you unable to use it (without hacking Google back into your Android version, but if you do that you might just as well stick to a Google version). Oh, and what about the black box binary drivers you are using on your super-secure handset? Baseband? CPU (ME anyone?)? SIM card? Before you talk about security, figure out what you are trying to protect against, and start from the top. You look like an idiot if you complain about breakable windows but do not notice that the door is open.

snowpanda 10y ago
Your entire comment is based around the "but there are bigger problems" argument. That's like saying you shouldn't fix your leaking engine, if your brakes don't work.
- tptacek 10y ago
  This analogy is basically perfect.
- arghwhat 10y ago
  No. I'm saying that if you're trying to fix an engine leak, start with the giant hole in the block from the anti-tank round that was fired at point blank at it instead of starting with the leaking gasket.
dTal 10y ago
>If you cannot trust Google to provide a "non-evil" Google play services, why the flying fuck do you think the Google-provided (or manufacturer-under-tight-google-control-provided) OS is fine? Because the likelihood of an a-priori exploit hidden in AOSP is far more remote than the possibility of malicious exploitation, at some point in the future, of the gaping wide security hole that is the "give Google root" subsystem. >Now, if you are security conscious and willing to let go of the conveniences of selling your soul to Google, you would be running a non-Google'd version of Android without Google services. Your only valid complaint in this case, is that Signal depends on Google services to operate, which makes you unable to use it (without hacking Google back into your Android version, but if you do that you might just as well stick to a Google version). Yup. And that's unacceptable. You can't really claim to be security conscious if your product comes with the stipulation that you give a megacorp root on your computer, can you?
- arghwhat 10y ago
  > Because the likelihood of an a-priori exploit hidden in AOSP is far more remote than the possibility of malicious exploitation, at some point in the future, of the gaping wide security hole that is the "give Google root" subsystem. I am not talking about AOSP. AOSP does not ship Google Play services unless you try to squeeze them in yourself (which would be silly - why would you run a google-clean system and stuff google back in?). I am talking about versions of Android that come with Google Play services - that is, Google shipped or manufacturer-controlled-by-google shipped. (I sense that I may have misunderstood your point) > Yup. And that's unacceptable. You can't really claim to be security conscious if your product comes with the stipulation that you give a megacorp root on your computer, can you? Indeed it is unacceptable. However, Signal on a Google-powered android system is no less "backdoorable" if you avoid Google Play services. The only way out is to take a Google-less Signal, and put it on a Google-less Android. This is where OWS can start to get on my nerves, because they indeed do not want to make a google play services free version (Even if you do not care about security, you might care about the compatibility), and that they effectively took down libresignal. Their reasons for doing so were sound (dealing with uncontrolled, potentially borked clients on a protocol and service that is still evolving is quite a pain), but they could quite easily have abstracted these things away in the official Signal implementation so that things could work both with and without, especially seeing how security oriented they are. However, my problem with this post was that it took a Google Play powered signal on a Google powered Android, and started poking at how Google could backdoor Signal, when the ENTIRE system is under Google's control. I'm not saying that this does not matter until we have solved world hunger, I am saying that fixing this specific instance of the problem (Google Play services dependency of Signal) does not solve the specified problem at all (Google backdooring of Signal).
thinkloop 10y ago
> They could backdoor the process isolation and poke around at Signal memory if they felt like it. Actual question: are google services not apps that run on android similar to other apps, within confined environments?
- arghwhat 10y ago
  Yes, it is isolated with interaction through IPC and intents, although Google Play Services have a lot of permissions, it is a normal "app". To communicate with it, you use a Google-provided, obfuscated library which potentially could be malicious. However, the "real backdoor" mentioned is in a component that is loaded dynamically when Signal prepares a MapView. The dynamic load means that Google can change what is loaded into the Signal app in the future, unlike the Google API client which while potentially malicious, is static until OWS updates it.
  - thinkloop 10y ago
    Ty. In that case, specifically regarding poking in memory, isn't that not possible regardless of how malicious the program is?
    - arghwhat 10y ago
      Yes, although the system can be modified to permit it. Also, google play services require a library to use, and this library runs in your process. Likewise, the dynamically loaded mapview problem takes some external code and stuffs it into your process.
larma 10y ago
Signal is told to be a secure crypto messenger everyone can use. This means that people are installing it on a usual Android device and assume that nobody is able to read their messages without physical access. Of course you are right, there are many black boxes in most mobile devices. But does this mean we shouldn't care about any of them? Most of these black boxes are not updated on a regular basis or the update requires user consent. This means that, if they don't allow arbitrary code execution now, it is hard to make them do evil things. The mentioned issue with Google Maps integration (leave the GCM problems aside) however is a real possibility to silently drive targeted attacks on Signal - it's actually damn easy for Google to do this. If we'd be doing a proper analysis on all other black boxes (processor, modem, manufacturer extensions, etc), I doubt we'll find such kind of backdoors in most of them. And if I will find such a thing, be sure I'll be writing about it as well. This backdoor is important for those that want to securely communicate and their adversary is for example the US gov. e.g. the next Snowden. Google can be forced by US agencies to use this backdoor and this renders Signal unusable for them. These people should know about the backdoor. If you know and don't care, that's your problem...
- arghwhat 10y ago
  If you are running an Android version that legitimately bundles Google Play, the Android release itself was either directly shipped by, or shipped by someone controlled by Google. I am not saying we shouldn't care about problems because there are bigger ones. However, if the problem you are trying to fix is "Google is capable of poking around in your running instance of Signal" (That is, what the map trick is potentially capable of), then removing any Google integration from the Signal app will not help as long as you still run on a Google-controlled Android release. The only unique thing about this specific Google dependency is that it is more dynamic than the OS, but as long as Google owns your OS, they have every possibility of monitoring your process memory. That's before you start worrying about the black box proprietary drivers most ARM devices use and all that jazz. My complaint lies in that fixing this will not improve the security by any noticable measure (that is, no noticable reduction in Google's capability of reading process memory of your instance of Signal) for any of the current Signal users (which are implicitly Google Android users, although a some instances may be non-Google + google services manually patched in). The primary benefit is that some people that cannot currently run Signal due to the dependency can join while maintaining the non-Googliness of their system.

snowpanda 10y ago

Your entire comment is based around the "but there are bigger problems" argument. That's like saying you shouldn't fix your leaking engine, if your brakes don't work.

tptacek 10y ago
This analogy is basically perfect.
arghwhat 10y ago
No. I'm saying that if you're trying to fix an engine leak, start with the giant hole in the block from the anti-tank round that was fired at point blank at it instead of starting with the leaking gasket.

dTal 10y ago

>If you cannot trust Google to provide a "non-evil" Google play services, why the flying fuck do you think the Google-provided (or manufacturer-under-tight-google-control-provided) OS is fine? Because the likelihood of an a-priori exploit hidden in AOSP is far more remote than the possibility of malicious exploitation, at some point in the future, of the gaping wide security hole that is the "give Google root" subsystem. >Now, if you are security conscious and willing to let go of the conveniences of selling your soul to Google, you would be running a non-Google'd version of Android without Google services. Your only valid complaint in this case, is that Signal depends on Google services to operate, which makes you unable to use it (without hacking Google back into your Android version, but if you do that you might just as well stick to a Google version). Yup. And that's unacceptable. You can't really claim to be security conscious if your product comes with the stipulation that you give a megacorp root on your computer, can you?

arghwhat 10y ago
> Because the likelihood of an a-priori exploit hidden in AOSP is far more remote than the possibility of malicious exploitation, at some point in the future, of the gaping wide security hole that is the "give Google root" subsystem. I am not talking about AOSP. AOSP does not ship Google Play services unless you try to squeeze them in yourself (which would be silly - why would you run a google-clean system and stuff google back in?). I am talking about versions of Android that come with Google Play services - that is, Google shipped or manufacturer-controlled-by-google shipped. (I sense that I may have misunderstood your point) > Yup. And that's unacceptable. You can't really claim to be security conscious if your product comes with the stipulation that you give a megacorp root on your computer, can you? Indeed it is unacceptable. However, Signal on a Google-powered android system is no less "backdoorable" if you avoid Google Play services. The only way out is to take a Google-less Signal, and put it on a Google-less Android. This is where OWS can start to get on my nerves, because they indeed do not want to make a google play services free version (Even if you do not care about security, you might care about the compatibility), and that they effectively took down libresignal. Their reasons for doing so were sound (dealing with uncontrolled, potentially borked clients on a protocol and service that is still evolving is quite a pain), but they could quite easily have abstracted these things away in the official Signal implementation so that things could work both with and without, especially seeing how security oriented they are. However, my problem with this post was that it took a Google Play powered signal on a Google powered Android, and started poking at how Google could backdoor Signal, when the ENTIRE system is under Google's control. I'm not saying that this does not matter until we have solved world hunger, I am saying that fixing this specific instance of the problem (Google Play services dependency of Signal) does not solve the specified problem at all (Google backdooring of Signal).

thinkloop 10y ago

> They could backdoor the process isolation and poke around at Signal memory if they felt like it. Actual question: are google services not apps that run on android similar to other apps, within confined environments?

arghwhat 10y ago
Yes, it is isolated with interaction through IPC and intents, although Google Play Services have a lot of permissions, it is a normal "app". To communicate with it, you use a Google-provided, obfuscated library which potentially could be malicious. However, the "real backdoor" mentioned is in a component that is loaded dynamically when Signal prepares a MapView. The dynamic load means that Google can change what is loaded into the Signal app in the future, unlike the Google API client which while potentially malicious, is static until OWS updates it.
- thinkloop 10y ago
  Ty. In that case, specifically regarding poking in memory, isn't that not possible regardless of how malicious the program is?
  - arghwhat 10y ago
    Yes, although the system can be modified to permit it. Also, google play services require a library to use, and this library runs in your process. Likewise, the dynamically loaded mapview problem takes some external code and stuffs it into your process.

larma 10y ago

Signal is told to be a secure crypto messenger everyone can use. This means that people are installing it on a usual Android device and assume that nobody is able to read their messages without physical access. Of course you are right, there are many black boxes in most mobile devices. But does this mean we shouldn't care about any of them? Most of these black boxes are not updated on a regular basis or the update requires user consent. This means that, if they don't allow arbitrary code execution now, it is hard to make them do evil things. The mentioned issue with Google Maps integration (leave the GCM problems aside) however is a real possibility to silently drive targeted attacks on Signal - it's actually damn easy for Google to do this. If we'd be doing a proper analysis on all other black boxes (processor, modem, manufacturer extensions, etc), I doubt we'll find such kind of backdoors in most of them. And if I will find such a thing, be sure I'll be writing about it as well. This backdoor is important for those that want to securely communicate and their adversary is for example the US gov. e.g. the next Snowden. Google can be forced by US agencies to use this backdoor and this renders Signal unusable for them. These people should know about the backdoor. If you know and don't care, that's your problem...

arghwhat 10y ago
If you are running an Android version that legitimately bundles Google Play, the Android release itself was either directly shipped by, or shipped by someone controlled by Google. I am not saying we shouldn't care about problems because there are bigger ones. However, if the problem you are trying to fix is "Google is capable of poking around in your running instance of Signal" (That is, what the map trick is potentially capable of), then removing any Google integration from the Signal app will not help as long as you still run on a Google-controlled Android release. The only unique thing about this specific Google dependency is that it is more dynamic than the OS, but as long as Google owns your OS, they have every possibility of monitoring your process memory. That's before you start worrying about the black box proprietary drivers most ARM devices use and all that jazz. My complaint lies in that fixing this will not improve the security by any noticable measure (that is, no noticable reduction in Google's capability of reading process memory of your instance of Signal) for any of the current Signal users (which are implicitly Google Android users, although a some instances may be non-Google + google services manually patched in). The primary benefit is that some people that cannot currently run Signal due to the dependency can join while maintaining the non-Googliness of their system.