38 ms·

Chinese espionage at work... I wonder how many foreign agencies can access my phone: USA, UK, China, Russia, ...

by markokrajnc 10y ago

danieldk 10y ago
Hanlon's razor applies here, but guising backdoors as programming/deployment errors gives plausible deniability.
- consp 10y ago
  If so, it was hidden in plain sight. Using /proc is not something that won't show up over a very short period of time. Especially if you call it sunxi_debug which will at least trigger my interest as an embedded developer.
- Arnt 10y ago
  Guise? They distributed source and the patch is not at all obfuscated. Eight consecutive lines like "cred->uid = 0;" and then printk("now you are root\n"), so it's really easy to spot in a diff. Don't see why they did it, but they did in in the plainest and most visible way I can imagine.
  - 0x0 10y ago
    It's not THAT easy to spot in a diff because a lot of these kernel source code repository dumps are basically 1 single commit with the entire source code; any existing kernel.org git history is lost. So you'll have to figure out which mainline revision they started working from, and manually diff with that (which will probably turn into a huge mega-patch).
    - Arnt 10y ago
      That's orthogonal. What you're saying is that the diffs are hard to work with in general. What I'm saying is that in a diff (be it large or small, a single commit or many), the code they wrote is the most visible and understandable way to do what they did.
      - 0x0 10y ago
        What better way to disguise a backdoor than an apparently deliberate "debug" utility? I mean, if they have to distribute source code sooner or later (which they do since Linux is GPL), this looks much more innocent than any super obfuscated "hidden" source code that would be discovered eventually anyway. Not saying this was the actual intention here, but it'd be a plausible way to go about it. It certainly appears the backdoor is running on lots of devices in the wild before it got noticed (even when it's this obvious in the diff(!)), so "mission accomplished"? :)
    - digi_owl 10y ago
      Given that this is Android related, and Android use very specific kernel versions, it should not be that hard.
  - danieldk 10y ago
    They distributed source and the patch is not at all obfuscated. Which is exactly my point. Say you are a government organization that requires a backdoor. You can make a very sophisticated backdoor. When it's found it is clear that it is probably an intentional backdoor (e.g. Dual_EC_DRBG). Or you can make a very obvious backdoor that is disguised as a debugging option that you forgot to disable, an obvious logic error, etc. For such backdoors, it's easy to argue that it was just sloppy programming (in contrast to an intentional government-requested backdoor), so people will assume the simpler explanation (as in Hanlan's razor). We have learned from the Debian OpenSSL saga [1] that trivial programming errors in critical software can go unnoticed for years. I don't think the Debian OpenSSL bug was government-mandated, but it's easy to see that this is a very attractive route: the bug caused only 32,768 unique private keys to be generated (great for spying), most people will believe it's a true programming error, you pay the person/company that introduces the bug royally for taking the blame. [1] https://en.wikipedia.org/wiki/OpenSSL#Predictable_private_keys_.28Debian-specific.29 https://en.wikipedia.org/wiki/OpenSSL#Predictable_private_ke...
    - dhoe 10y ago
      Assume the printk("You're root now") had not been there. Would that increase your estimate for the probability of an intentional backdoor, or reduce it?
      - Arnt 10y ago
        Two rival businessmen meet in the Warsaw railway station. "Where are you going?" says the first man. "To Minsk," says the second. "To Minsk, eh? What a nerve you have! I know you're telling me you're going to Minsk because you want me to think that you're really going to Pinsk. But it so happens that I know you really are going to Minsk. So why are you lying to me?"
- threatofrain 10y ago
  While in this case the backdoor may have been deliberate or accidental, more generally, Hanlon's razor is a heuristic for harmonious social relations -- not truth-seeking.
gonzo41 10y ago
Just go low tech, burner phones to the rescue.
- ashitlerferad 10y ago
  Burner phones are probably even more vulnerable.
  - gonzo41 10y ago
    There's a lot too say to the whole "the government listens to my calls" etc etc. If you're after privacy its about op-sec. Turning off the phone, not using it for certain activities, having different phones for different compartments of life. People (me included) are lazy, and really, if your relying on a phone for your security...well..good luck with that.
  - deleted 10y ago
    [deleted]
plaes 10y ago
Allwinner doesn't make mobile phone SoC's.
- vidarh 10y ago
  They do however get used in a bunch of cheap "phablets".
lamarkia 10y ago
Really, espionage? The hardware is used in lowcost tablets...

Chinese espionage at work... I wonder how many foreign agencies can access my phone: USA, UK, China, Russia, ...

danieldk 10y ago

Hanlon's razor applies here, but guising backdoors as programming/deployment errors gives plausible deniability.

consp 10y ago
If so, it was hidden in plain sight. Using /proc is not something that won't show up over a very short period of time. Especially if you call it sunxi_debug which will at least trigger my interest as an embedded developer.
Arnt 10y ago
Guise? They distributed source and the patch is not at all obfuscated. Eight consecutive lines like "cred->uid = 0;" and then printk("now you are root\n"), so it's really easy to spot in a diff. Don't see why they did it, but they did in in the plainest and most visible way I can imagine.
- 0x0 10y ago
  It's not THAT easy to spot in a diff because a lot of these kernel source code repository dumps are basically 1 single commit with the entire source code; any existing kernel.org git history is lost. So you'll have to figure out which mainline revision they started working from, and manually diff with that (which will probably turn into a huge mega-patch).
  - Arnt 10y ago
    That's orthogonal. What you're saying is that the diffs are hard to work with in general. What I'm saying is that in a diff (be it large or small, a single commit or many), the code they wrote is the most visible and understandable way to do what they did.
    - 0x0 10y ago
      What better way to disguise a backdoor than an apparently deliberate "debug" utility? I mean, if they have to distribute source code sooner or later (which they do since Linux is GPL), this looks much more innocent than any super obfuscated "hidden" source code that would be discovered eventually anyway. Not saying this was the actual intention here, but it'd be a plausible way to go about it. It certainly appears the backdoor is running on lots of devices in the wild before it got noticed (even when it's this obvious in the diff(!)), so "mission accomplished"? :)
  - digi_owl 10y ago
    Given that this is Android related, and Android use very specific kernel versions, it should not be that hard.
- danieldk 10y ago
  They distributed source and the patch is not at all obfuscated. Which is exactly my point. Say you are a government organization that requires a backdoor. You can make a very sophisticated backdoor. When it's found it is clear that it is probably an intentional backdoor (e.g. Dual_EC_DRBG). Or you can make a very obvious backdoor that is disguised as a debugging option that you forgot to disable, an obvious logic error, etc. For such backdoors, it's easy to argue that it was just sloppy programming (in contrast to an intentional government-requested backdoor), so people will assume the simpler explanation (as in Hanlan's razor). We have learned from the Debian OpenSSL saga [1] that trivial programming errors in critical software can go unnoticed for years. I don't think the Debian OpenSSL bug was government-mandated, but it's easy to see that this is a very attractive route: the bug caused only 32,768 unique private keys to be generated (great for spying), most people will believe it's a true programming error, you pay the person/company that introduces the bug royally for taking the blame. [1] https://en.wikipedia.org/wiki/OpenSSL#Predictable_private_keys_.28Debian-specific.29 https://en.wikipedia.org/wiki/OpenSSL#Predictable_private_ke...
  - dhoe 10y ago
    Assume the printk("You're root now") had not been there. Would that increase your estimate for the probability of an intentional backdoor, or reduce it?
    - Arnt 10y ago
      Two rival businessmen meet in the Warsaw railway station. "Where are you going?" says the first man. "To Minsk," says the second. "To Minsk, eh? What a nerve you have! I know you're telling me you're going to Minsk because you want me to think that you're really going to Pinsk. But it so happens that I know you really are going to Minsk. So why are you lying to me?"
threatofrain 10y ago
While in this case the backdoor may have been deliberate or accidental, more generally, Hanlon's razor is a heuristic for harmonious social relations -- not truth-seeking.

gonzo41 10y ago

Just go low tech, burner phones to the rescue.

ashitlerferad 10y ago
Burner phones are probably even more vulnerable.
- gonzo41 10y ago
  There's a lot too say to the whole "the government listens to my calls" etc etc. If you're after privacy its about op-sec. Turning off the phone, not using it for certain activities, having different phones for different compartments of life. People (me included) are lazy, and really, if your relying on a phone for your security...well..good luck with that.
- deleted 10y ago
  [deleted]

plaes 10y ago

Allwinner doesn't make mobile phone SoC's.

vidarh 10y ago
They do however get used in a bunch of cheap "phablets".

lamarkia 10y ago

Really, espionage? The hardware is used in lowcost tablets...