ZTE Backdoor(pastebin.com)
pastebin.com
ZTE Backdoor
http://pastebin.com/wamYsqTV
48 comments
I suspect that roughly 10% percent of backdoors are discovered. If this is the case then I wonder to what extent backdoors hide in our computing devices. RMS deserves more credit and I think he will be remembered fifty years from now when our lives are even more controlled by computers.
Especially health related implanted computers and or home automation systems running software with backdoors, it is a wild future.
Not 50 years from now. We're already there:
CIA wants to spy on you through your appliances [1]
[1] https://www.networkworld.com/community/blog/cia-wants-spy-yo...
[1] https://www.networkworld.com/community/blog/cia-wants-spy-yo...
[deleted]
I don't know whether I'm more suspicious of ZTE, the carrier, the Chinese government or the US government. I don't really know how to process that thought.
It's one of the reasons for gravitating towards open source and specialist firmwares. These sorts of devices are too sophisticated to be trustworthy.
A while back Indian govt barred its state telecom carrier (BSNL) to source equipment from Huawei for similar concerns. I thought they were paranoid at the time. Looks like they had a valid point.
While they had a valid point, Huawei != ZTE. ZTE is partly state-owned, but Huawei is not, it's all privately owned.
PS: http://www.forbes.com/sites/robertolsen/2011/02/24/huaweis-o...
PS: http://www.forbes.com/sites/robertolsen/2011/02/24/huaweis-o...
That's no guarantee for anything. It's already out in the open that Huawei has close ties to the Chinese government and military. The point OP is trying to make is that Chinese telecom cannot be trusted as the Chinese government is actively indulging in systematic deployment of espionage frameworks on this level - by infiltration through business.
Yep, it's impossible to do business in china without good government connections.
This stuff needs to be outlawed. If you want a backdoor for mainteneance, install some hardware serial console.
Any time you think to yourself, "There ought to be a law!"
Just don't.
Just don't.
If you think about it, every law is a threat of violence. If you're not prepared to use violence, or at least force to some degree, to enforce it, you merely have a strong suggestion. Even if you just start off with handcuffs, if they escalate, you have to escalate, or let them go.
I think this is a useful heuristic for deciding whether something should be legislated: "is this worth using violence over?"
I think this is a useful heuristic for deciding whether something should be legislated: "is this worth using violence over?"
violence means very little in the context of corporations, since they're not people.
Do you know why corporations do what courts say (pay damages, clean up oil spills, etc.)? Because inside their scaly, corporate armor, they're made of squishy people.
And when countries like China make it a law mandating the existence of such backdoors in devices sold/manufactured in their country?
I wonder what wonderful bugs/backdoors are available in ZTE networking equipment.
Is there trusted hardware a company could buy that is completely open-source, including hardware design and checks, so white-hats could identify any mishaps with it?
The Openmoko phones are AFAIK the only mobile phones with open source hardware. http://wiki.openmoko.org/wiki/Main_Page
They're not open-source hardware in that sense. What they publish is a 19-page pdf of schematics of how the components are put together [1] -- and even that has redactions due to NDAs (like page 14 -- the say they have a "super NDA" with the GSM chip provider that bans them from even publishing the datasheet!) The components themselves (like the Samsung SoC and the GSM chip) are completely closed.
"Open" in that they show you how they put together the black boxes. "Closed" because it's all made up of black boxes.
[1] http://wiki.openmoko.org/wiki/Neo_FreeRunner_Hardware#Hardwa...
[2] http://lists.openmoko.org/pipermail/community/2007-January/0...
"Open" in that they show you how they put together the black boxes. "Closed" because it's all made up of black boxes.
[1] http://wiki.openmoko.org/wiki/Neo_FreeRunner_Hardware#Hardwa...
[2] http://lists.openmoko.org/pipermail/community/2007-January/0...
Have you read trusting trust?
"Reflections on Trusting Trust", Ken Thompson's 1983 Turing Award lecture: http://cm.bell-labs.com/who/ken/trust.html
Also, there is an interesting article on trusting hardware ( http://theinvisiblethings.blogspot.fr/2009/03/trusting-hardw... ) which was reposted two months ago on HN ( http://news.ycombinator.com/item?id=3656522 ).
Also, there is an interesting article on trusting hardware ( http://theinvisiblethings.blogspot.fr/2009/03/trusting-hardw... ) which was reposted two months ago on HN ( http://news.ycombinator.com/item?id=3656522 ).
Even then, trusting trust is not really all that undetectable in a world of different compilers and different hardware. Or, perhaps more accurately, the power of the adversary has to increase by a lot to maintain the illusion of non-infection.
http://www.acsa-admin.org/2005/abstracts/47.html
http://www.acsa-admin.org/2005/abstracts/47.html
I can't really be surprised by this, you would expect the chinese goverment to want a backdoor in the electronics they sell.
As skeptical as I am of government in general, and perhaps the chinese one in particular, I find it very hard to believe they would put a suid root binary with a password in the flash... What would be the point of that?
Now if it was some daemon that set up a listening socket and linked to some APIs, ready to let an unidentified external party hook into the phonebook, or something like that, then I'd be screaming government, bloody government! :)
Now if it was some daemon that set up a listening socket and linked to some APIs, ready to let an unidentified external party hook into the phonebook, or something like that, then I'd be screaming government, bloody government! :)
It's not remotely accessible and really seems more like a debug tool.
Your tinfoil hat might be defective.
Your tinfoil hat might be defective.
ZTE phones are very popular in China. I'm looking out for the Chinese reaction to this is.
Chinese reaction? I'm thinking nothing.
People who care about this privacy issue usually don't use ZTE. No offense, but ZTE aims at the entry-level consumers, most of whom don't know what root is and only buy ZTE for the low price.
Besides, in China, there are way more to be worried than this non-issue. You know it...
People who care about this privacy issue usually don't use ZTE. No offense, but ZTE aims at the entry-level consumers, most of whom don't know what root is and only buy ZTE for the low price.
Besides, in China, there are way more to be worried than this non-issue. You know it...
Isn't ZTE a chineese corporation? It seems to me possible, that not only does China know this exists, they ordered it.
I don't understand why there is so much xenophobia about this exploit. A government backdoor would be far more capable and sophisticated than this. Occam's razor applies here: an suid debug binary was left in the production image by accident.
Because "China". :)
Anyone who thinks the Chinese government had anything to do with this is just an idiot.
Anyone who thinks the Chinese government had anything to do with this is just an idiot.
> I'm looking out for the Chinese reaction to this is.
Free root form the manufacturer! Time to install another ROM.
Free root form the manufacturer! Time to install another ROM.
Check your phone using this free app: ZTE Backdoor Finder.
https://play.google.com/store/apps/details?id=com.pcl.ztebd
It's such a security fail... So big that I doubt it's true. Without any proof, explanation... has anybody been able to reproduce it?
If it's true, it would a great opportunity to see how Google/ZTE reacts to this vulnerability. How much time will ZTE take to correct this and issue an update? And also, will be able Google to stop applications who exploit this vulnerability to go public in the Market? I sincerely doubt it.
If it's true, it would a great opportunity to see how Google/ZTE reacts to this vulnerability. How much time will ZTE take to correct this and issue an update? And also, will be able Google to stop applications who exploit this vulnerability to go public in the Market? I sincerely doubt it.
According to this post on Reddit, it is real and ZTE is planning on fixing it: http://www.reddit.com/r/Android/comments/tkc45/zte_backdoor/...
By fixing it, I assume they mean removing this backdoor and put in a new one? If they remove it altogether, there's not much reason to have it there in the first place.
Does the reason for the backdoor really have to be to allow malicious remote access (hence requiring a replacement backdoor)?
I highly doubt, considering the obvious nature and simplicity of the binary, that clandestine remote access (i.e. by the Chinese government or other such tinfoil hat theories) was the idea.
Especially given the name of the binary, I suspect some ZTE engineer was tasked with writing a desktop or mobile sync application that they decided needed root access for some reason. Said engineer then made a major mistake and decided a non-unique plaintext secret stored in the binary was adequate security. This happens all the time - see the recent RuggedCom "backdoor" fiasco [0]. It's happened at places I've worked, too, and it's not exactly new in the industry as a whole.
An engineer was uninformed or ignored security best practices and wrote code with a vulnerability. The vulnerability will be patched out. It's a big deal and it sucks (why were all setuid binaries not audited, at least to the level that basic oversights like this one would be noticed?), but at least in my mind it's not some kind of secret government control backdoor conspiracy - it's just a horrible bug.
[0]: http://www.nerc.com/fileUploads/File/Events%20Analysis/A-201...
I highly doubt, considering the obvious nature and simplicity of the binary, that clandestine remote access (i.e. by the Chinese government or other such tinfoil hat theories) was the idea.
Especially given the name of the binary, I suspect some ZTE engineer was tasked with writing a desktop or mobile sync application that they decided needed root access for some reason. Said engineer then made a major mistake and decided a non-unique plaintext secret stored in the binary was adequate security. This happens all the time - see the recent RuggedCom "backdoor" fiasco [0]. It's happened at places I've worked, too, and it's not exactly new in the industry as a whole.
An engineer was uninformed or ignored security best practices and wrote code with a vulnerability. The vulnerability will be patched out. It's a big deal and it sucks (why were all setuid binaries not audited, at least to the level that basic oversights like this one would be noticed?), but at least in my mind it's not some kind of secret government control backdoor conspiracy - it's just a horrible bug.
[0]: http://www.nerc.com/fileUploads/File/Events%20Analysis/A-201...
I fail to comprehend how you can fix a backdoor.
The backdoor is a setuid-binary that gives a root shell when prompted with the correct "password." Deleting the binary removes the backdoor.
A discovered backdoor is a vulnerability. You fix the vulnerability.
I understand that, but I meant it more in a philosophical way. The backdoor is not a bug (it's hard for me to imagine that the backdoor was included by accident), so you can't fix it. You can only remove it.
Also, it's not a vulnerability either (from ZTE's point of view). It's a feature.
Also, it's not a vulnerability either (from ZTE's point of view). It's a feature.
You make it more stealth.
And the downvotes are because of...