Database Info

Most Android vendors lost their Linux distribution rights.

Most Android vendors lost their Linux distribution rights, could face shakedown or shutdown
Most Android vendors lost their Linux distribution rights, could face shakedown or shutdown
Last week I read about an Android licensing issue that I wasn't previously aware of. It's a pretty serious one, and it's not that hard to understand. The short version is that
rampant non-compliance with the source code disclosure requirement of the GPLv2 (the license under which Linux is published) -- especially but not only in connection with Honeycomb -- has technically resulted in a loss of most vendors' right to distribute Linux;
this loss of the distribution license is irremediable except through a new license from each and every contributor to the Linux kernel, without which Android can't run; and
as a result, there are thousands of people out there who could legally shake down Android device makers, threatening to obtain Apple-style injunctions unless their demands for a new license grant are met.
At first sight it may appear unthinkable that things could go so wrong with the distribution license for the very foundation Android was built upon. But I did my research and the above conclusions are just consistent with legal positions taken recently by two of the most renowned Free Software organizations -- the Software Freedom Conservancy (SFC) and the Software Freedom Law Center (SFLC) -- in another context involving GPLv2 (and software embedded in devices), the so-called BusyBox lawsuit (U.S. District Court for the Southern District of New York, case no. 1:09-cv-10155).
Just like those organizations forced a number of companies (most recently Best Buy, previously some others including Cisco and Verizon) to pay up, the situation surrounding most Android OEMs could become quite uncomfortable if any Linux copyright holders driven by greed or other motives team up with copyright lawyers (such as on a contingency basis) and enforce their rights. There are thousands of Linux kernel contributors besides Linus Torvalds. In some cases, it would probably be easy to just replace the code they contributed if they seek to enforce their rights, but in other cases, it would certainly take longer than someone's ability to obtain a preliminary injunction somewhere on this planet.
Click link to look at the legal issue more closely.
http://fosspatents.blogspot.com/2011/08/most-android-vendors-lost-their-linux.html
Does not sound too good...

Sensationalist bull****.

Hmm now thats interesting.

Doesn't this mean the OEM's will have to stick to vanilla android or release their modifications? Or is it not that simple? I read about the apache liscense with google and GPLv2 but im not quite sure I understood that part. Can anyone clearify?
Well from what I got it seems that google aquired motorola with good timing.
EDIT: So the problem with google and the apache license was that they never commented the proper permissions in their code, correct?

No, there ARE no problems with the licensing, and even Linus himself has said there are no issues. The kernel is licensed under GPL, and the kernel code is available. The user space itself is licensed under Apache and Google have no requirement to release the source for ASL code.
This guy is nothing but a huge Android troll and is well known for being so.

Kernel GPL violations
FloatingFatMan said:
No, there ARE no problems with the licensing, and even Linus himself has said there are no issues. The kernel is licensed under GPL, and the kernel code is available. The user space itself is licensed under Apache and Google have no requirement to release the source for ASL code.
This guy is nothing but a huge Android troll and is well known for being so.
Click to expand...
Click to collapse
The general conclusion is right (that is, most major vendors are complying with their GPL requirements, mainly because they aren't modding the kernel, and are - if somewhat reluctantly - releasing the config files). However it's not true for all. A substantial number of smaller manufacturers, often offshore ones, are modding the kernel source and config files and are not releasing the modded kernel source code and config files. Those are clear breaches of their GPL licence, hence those manufacturers are breaching copyright. Anyone selling or distributing those systems is at serious risk (and I for one hope that the Free Software Foundation goes after them soon - they may be offshore, but their business models would break if they were denied access to first-world markets).

So in plan English, What does that mean for consumers???
Sent from my LG-P999 using xda premium

KRAZYADROIDMASTER said:
So in plan English, What does that mean for consumers???
Sent from my LG-P999 using xda premium
Click to expand...
Click to collapse
No more Sense/Touchwiz/OptimusUI?

Oh darn. No TW? That would not bother me at all! Haha. Bit this is sad.
Sent from my SPH-D710 using xda app-developers app

I think the manufacturers not complying with the GPL are likely to fold when either the linux or free software foundations lean on them. It'll probably end up with the foundations getting a reasonable amount of money, and the manufacturers having to make sure that they comply (google "Cisco GPL" to see what I'm talking about). As a consumer, if your manufacturer was already complying, it won't make much difference. If they weren't, it will probably mean that a fair few apps that weren't available will become so, and the hardware will be easier to root and probably to mod.

Aren't bootloaders proprietary? I don't think that's under GPL.^

Bootloaders and GPL
alpha-niner64 said:
Aren't bootloaders proprietary? I don't think that's under GPL.^
Click to expand...
Click to collapse
Hi alpha-niner; bootloaders haven't been mentioned till now in this thread, so it's a bit of a red herring. But to take the bait: the bootloader itself is almost always proprietary. The manufacturers have no obligation to release it. Of course, unlocking it with a utility provided by the overall system developer (i.e. fastboot) seems likely to be legal unless you specifically agreed not to do so in your purchase agreement, as is completely replacing it with a bootloader that you have a licence for. Disassembling it is clearly illegal. Taking it off the system to mod it and putting the modded version back is probably illegal (the illegal action is making a copy for the purpose of modding rather than backup). On the other hand, in-flash patching of the bootloader doesn't involve copying, so can't breach copyright (it might breach a carefully written licence, I guess). And of course you would then be entitled to back up the patched bootloader. It's the order and direction of actions that's important here.
But more important, you are correct in implying that the problem with some systems lie in the bootloader itself. But the problems with many others lie in "proprietary" mods to the boot kernel and GPLed components of the initramfs, and "proprietary" mods to the running kernel and GNU utilities. They could readily be reversed or adapated if the mod sources were released as per the GPL. Not doing so is a clear GPL breach. These cases are legion.
It's also worth noting that some of the worst offenders are disabling kernel modules and building drivers directly into the kernel. Whatever may be the case with loadable kernel modules, built in drivers are clear derivative works of the kernel, and thus are also subject to the GPL. In many cases, the drivers are for third party components: so the manufacturers not only breached the GPL in these cases, they very probably breached their agreements with the component vendors as well. Vendor X, who supplies manufacturer Y with a component and the proprietary driver for it, is likely to have built in some contract protection against Y's actions leading to their driver becoming GPLed.
Best Wishes
Bob

What is Responsible Disclosure?

Responsible Disclosure is a term often used in security, but what is it?
In essence, responsible disclosure is the process of making the vendor or OEM of the vulnerable software or system aware of the problem before disclosing details of the vulnerability to the public. The idea here is that the vendor will promptly solve the issue, and release a fix to users of the software, and accredit the finding of the issue to the researcher, who then discloses the vulnerability in full, now the software has been patched.
Responsible disclosure is named as such, as vendors feel it's the most responsible way to go about handling a security issue you have found. It's often the best strategy to try if you do find an issue - look for a security contact for the company, and give them a shout.
Unfortunately, some companies are rather poor at dealing with security issues, and either don't respond, or don't issue a patch or inform users of a mitigation strategy. Or in severe cases, might not even inform users of there being an issue whatsoever, and appear to ignore the vulnerability. Do bear in mind though when dealing with mobile devices that many carriers add significant delays to software releases (where on the desktop, a fix may be available the next day, the OEM might take a week or more to make a patch available on unbranded firmware, since devices and firmwares often must be approved by regulators before release, and carriers will then want further changes applied to these firmwares before their own testing).
Often if a vendor acts like this, the only solution is Full Disclosure, a process where the full details of the vulnerability are publicly released, in order to raise awareness of the vendor's insecurity and inaction (particularly if efforts were already made to contact them). Full disclosure permits the end user to be made aware of the extent and details of the security issue, and attempt to mitigate or resolve it themselves (for example, by removing an affected plugin, deleting an APK, or using a firewall to prevent access to a vulnerable service until a fix is produced).
If you are new to security, and are unsure, responsible disclosure is usually the best way forwards, but there are plenty of people around who can give good advise about this. This may well change, in light of recent practices by some companies pertaining to how they handle security vulnerabilities which are responsibly disclosed (see https://www.openrightsgroup.org/blog/2013/nsa-affects-responsible-disclosure)

Good writeup, thanks!
Is full disclosure really an effective way of handling things though? I can understand that the intention is to make the vulnerability so well known that vendor has no choice but to fix it, but during that lead time there's going to be a vulnerability going around that people could really capitalize on. I don't have figures, but I would imagine that even if a user-made solution is found, the number of people that would actually adopt it has got to be a tiny fraction of a percent. If you're going full-disclosure, aren't you essentially ensuring the worst-case scenario? Security through obscurity is weak, but isn't it still better to sit on your hands and just hope that the vendor will get around to fixing it eventually?

Grand Guignol said:
Good writeup, thanks!
Is full disclosure really an effective way of handling things though? I can understand that the intention is to make the vulnerability so well known that vendor has no choice but to fix it, but during that lead time there's going to be a vulnerability going around that people could really capitalize on. I don't have figures, but I would imagine that even if a user-made solution is found, the number of people that would actually adopt it has got to be a tiny fraction of a percent. If you're going full-disclosure, aren't you essentially ensuring the worst-case scenario? Security through obscurity is weak, but isn't it still better to sit on your hands and just hope that the vendor will get around to fixing it eventually?
Click to expand...
Click to collapse
True, but also depends on the type of vulnerability. Is not the same finding a vulnerability where you need physical access to the device (ie a way of unlocking without PIN) than finding a vulnerabilty that allows remote access to sensite data without user action. I suppose that some sort of waiting can be defined. Like waiting for a week for the first type of vulnerabity and 3 months for the other....just my 2 cents.
Great writeup BTW!

For the security enthusiasts here: The Full DIsclosure Mailing List has been reopened. ENJOY!

Talking about responsible disclosure, I have the following question for you guys:
I found a vulnerability that can be exploited to drain the battery of a device. I informed the application vendor and they reacted that they agree with my finding and will fix it soon. I send my vulnerability and PoC 24th of February and they responded 3 weeks after. Now I am waiting for the vulnerability to be fixed.
I found this bug when writing my thesis and I really want to include it in my paper which should be published on the 31th of May. Does that fit responsible disclosure? Should I send them an e-mail stating that I will publish the details at the end of May?

It can't hurt to let them know youre doing it.
Sent from my Xperia ZL using XDA Free mobile app

Is full disclosure really an effective way of handling things though?

rakoczy12 said:
Is full disclosure really an effective way of handling things though?
Click to expand...
Click to collapse
If the end result of the disclousre is that the users can protect themselves, then yes. As the OP pointed out:
pulser_g2 said:
Full disclosure permits the end user to be made aware of the extent and details of the security issue, and attempt to mitigate or resolve it themselves (for example, by removing an affected plugin, deleting an APK, or using a firewall to prevent access to a vulnerable service until a fix is produced).
Click to expand...
Click to collapse

How did I just now see this forum? Pulser I was talking to you about such an area for many many moons ago.
@pulser_g2
I have a question about posting things I find that script kiddies would love. Like today, I opened up an apk that was supposed to be an icon pack. Instead, it has @Stericson 's RootTools package in it and someone else's libpush work. So it starts out as a script kiddies dream, cause that's all it is. But it would be good for people to learn from.
When I came here, before I installed @DaveShaw 's power menu .cab, I first learned what a cab was, what it did, how it worked, and what all the little bits and pieces did inside of it. You just can never be too safe. Which is probably why I don't go jumping on a new ROM, or app someone just released. I'll mull it over and let some other people be the testers. How could I post something like without giving away how it works, but showing what's inside. So as to let people know to be careful? Teach them how to open it up, the different parts of an apk, how to read it and such. That's the kind of thing I was meaning way back when I was asking you about making this kind of area. But you had the same concerns as me. It not turning into a scriptkiddy funhouse.
Are we going to be able to disclose threats among ourselves? You can't make everyone wear a white hat. Lord knows we didn't all wear one back in compsci. I see it like teaching firemen how to put out a fire. Yea they are going to learn what makes a really big fire that's hard to stop. But if you don't teach them how to build the fire, just put it out, then they have to go through just that extra bit of effort to do bad.

Maybe some parts of this thread belongs here. http://forum.xda-developers.com/general/security/security-threat-middle-attack-umts-t3374626

It is Awesome

wow

Samsung Addresses The Knox Vulnerability That Wasn't

http://www.androidpolice.com/2014/0...attack-avoidable-with-existing-knox-features/
The response wraps up by citing Professor Patrick Traynor from the Georgia Institute of Technology, who previously expressed concern over the researchers' findings. According to Traynor, "Proper configuration of mechanisms available within KNOX appears to be able to address the previously published issue. Samsung should strongly encourage all of their users to take advantage of those mechanisms to avoid this and other common security issues."
This person is trying to justify knox?

lqrt said:
http://www.androidpolice.com/2014/0...attack-avoidable-with-existing-knox-features/
The response wraps up by citing Professor Patrick Traynor from the Georgia Institute of Technology, who previously expressed concern over the researchers' findings. According to Traynor, "Proper configuration of mechanisms available within KNOX appears to be able to address the previously published issue. Samsung should strongly encourage all of their users to take advantage of those mechanisms to avoid this and other common security issues."
This person is trying to justify knox?
Click to expand...
Click to collapse
This Professor shouldn't speak for us, neither should Samsung. We pay for the devices, and those who choose to root are those who are aware of the risks.

[HELP] Has my phone been compromised physically?

Hi,
My phone was recently compromised with a sophisticated RAT. The exploits the RAT used were picked up by CM security and CM said it found.
1. Towel Root Exploit
2. Fake ID Exploit - something to do with exploiting Android certificates.
The thing is I have never rooted the phone or done anything other than a factory reset and purchased it new.
I'm concerned this may have been planted by someone close to me and need information to ensure I am safe in future.
How possible is it that this was carried out physically? the hacker who planted the RAT had physical access to my phone?
There is also other evidence which I can supply which was suggesting my phone had been flashed without my knowledge as well.
Any help would be greatly appreciated.
UPDATE: I just did a factory reset and reinstalled CM and again the exploits were found. How is this possible? Is the malware embedded in my ROM?
-Tim

timmyhall83 said:
Hi,
My phone was recently compromised with a sophisticated RAT. The exploits the RAT used were picked up by CM security and CM said it found.
1. Towel Root Exploit
2. Fake ID Exploit - something to do with exploiting Android certificates.
The thing is I have never rooted the phone or done anything other than a factory reset and purchased it new.
I'm concerned this may have been planted by someone close to me and need information to ensure I am safe in future.
How possible is it that this was carried out physically? the hacker who planted the RAT had physical access to my phone?
There is also other evidence which I can supply which was suggesting my phone had been flashed without my knowledge as well.
Any help would be greatly appreciated.
UPDATE: I just did a factory reset and reinstalled CM and again the exploits were found. How is this possible? Is the malware embedded in my ROM?
-Tim
Click to expand...
Click to collapse
1) Towel root is an application used to root phones, it itself is not malware
2) FakeID is a vuln, but not one to get worked up over and not introduced by malware
CM Security is utter garbage, and is only popular due to the shear amount of spamming that company has done. I have deleted a ton of their spam from here. Use Lookout if you want movie anti virus software. Delete that trash of an app CM.

jcase said:
1) Towel root is an application used to root phones, it itself is not malware
2) FakeID is a vuln, but not one to get worked up over and not introduced by malware
CM Security is utter garbage, and is only popular due to the shear amount of spamming that company has done. I have deleted a ton of their spam from here. Use Lookout if you want movie anti virus software. Delete that trash of an app CM.
Click to expand...
Click to collapse
Towel root is an exploit and can be packaged into malicious apps. If you do a Google search on this there are various articles explaining how it will be a nightmare for security firms due to this reason.

timmyhall83 said:
Towel root is an exploit and can be packaged into malicious apps. If you do a Google search on this there are various articles explaining how it will be a nightmare for security firms due to this reason.
Click to expand...
Click to collapse
Yeah I dont need garbage from a google search, I know what it is and how it works, doesnt change statement.

jcase said:
Yeah I dont need garbage from a google search, I know what it is and how it works, doesnt change statement.
Click to expand...
Click to collapse
Solid logic my friend.
I'll save you the hassle of searching and offer you this quote from an AVAST Virus Lab expert.
“Even though TowelRoot is not malicious itself, it may be misused as an exploit kit. Generally, TowelRoot can be used as a delivery package for malicious applications,” explained Filip Chytry, an AVAST Virus Lab expert on mobile malware. “It’s capable of misusing a mistake in Android code which allows attackers to get full control over your Android device. TowelRoot itself is more a proof-of-concept, but in the hands of bad guys, it can be misused really quickly. For this reason we added it to our virus signatures, so Avast detects it as Android:TowelExploit.” - Quoted from - blog.avast.com/2014/06/20/samsung-galaxy-s5-and-other-popular-phones-vulnerable-to-towelroot-android-exploit/

timmyhall83 said:
Solid logic my friend.
I'll save you the hassle of searching and offer you this quote from an AVAST Virus Lab expert.
“Even though TowelRoot is not malicious itself, it may be misused as an exploit kit. Generally, TowelRoot can be used as a delivery package for malicious applications,” explained Filip Chytry, an AVAST Virus Lab expert on mobile malware. “It’s capable of misusing a mistake in Android code which allows attackers to get full control over your Android device. TowelRoot itself is more a proof-of-concept, but in the hands of bad guys, it can be misused really quickly. For this reason we added it to our virus signatures, so Avast detects it as Android:TowelExploit.” - Quoted from - blog.avast.com/2014/06/20/samsung-galaxy-s5-and-other-popular-phones-vulnerable-to-towelroot-android-exploit/
Click to expand...
Click to collapse
I work fulltime in the mobile security industry "my friend". I analyze a large number of malware and exploit samples, on frequent basis. I'm well aware of what TowelRoot is, and did the first third party analysis of the exploit (as GeoHot shared a copy a day early with me).
That whole statement is rather poor, and misinformed. The Futex vulnerability, which is what towel root uses, is not even in Android code, its in the Kernel code. TowelRoot is not a proof of concept, its a full blown exploit doing it's designed purpose. Towelroot, as is, can not be used as a "delivery package".
Next time before coming with attitude against someone helping you, please do your research.

jcase said:
I work fulltime in the mobile security industry "my friend". I analyze a large number of malware and exploit samples, on frequent basis. I'm well aware of what TowelRoot is, and did the first third party analysis of the exploit (as GeoHot shared a copy a day early with me).
That whole statement is rather poor, and misinformed. The Futex vulnerability, which is what towel root uses, is not even in Android code, its in the Kernel code. TowelRoot is not a proof of concept, its a full blown exploit doing it's designed purpose. Towelroot, as is, can not be used as a "delivery package".
Next time before coming with attitude against someone helping you, please do your research.
Click to expand...
Click to collapse
I have done my research. It's seems out of the ordinary that a quote from a company representative of a major anti-virus firm would be 'rather poor, and misinformed'. Who's a more reliable source you or him?
I'm not coming with an attitude against anyone, if anything your second response was coming against me with attitude.

timmyhall83 said:
I have done my research. It's seems out of the ordinary that a quote from a company representative of a major anti-virus firm would be 'rather poor, and misinformed'. Who's a more reliable source you or him?
I'm not coming with an attitude against anyone, if anything your second response was coming against me with attitude.
Click to expand...
Click to collapse
Its not out of the ordinary, its called FUD and rather common.
In this case, me.
My second post had no attitude,
This is your THIRD thread about this topic, you have your answers. You seem not to like the answers.

jcase said:
Its not out of the ordinary, its called FUD and rather common.
In this case, me.
My second post had no attitude,
This is your THIRD thread about this topic, you have your answers. You seem not to like the answers.
Click to expand...
Click to collapse
Okay so explain to me, what would be the point of anti-virus companies adding the exploit to their databases if it can't be used for malicious purposes?
Your reply came of as pretty arrogant so yeah it did have attitude.

timmyhall83 said:
Okay so explain to me, what would be the point of anti-virus companies adding the exploit to their databases if it can't be used for malicious purposes?
Your reply came of as pretty arrogant so yeah it did have attitude.
Click to expand...
Click to collapse
The vulnerability can, that exploit as is can't as it requires user interaction.
More detections, more pop ups they show customers, more sales they get.
You have been given you answer here, and in the other two threads. I am closing this thread, please do not repost this question to other sections.

Would it be possible for a Developer to inject root Using CVE-2016-0728?

Hello all,
I was wondering if it would be possible for a developer to make use of vulnerability CVE-2016-0728 to gain root and inject SuperSU or others to gain permanent root on currently unrootable devices.
"perception-point(dot)io/2016/01/14/analysis-and-exploitation-of-a-linux-kernel-vulnerability-cve-2016-0728/"
Another article here "databreachtoday(dot)com/zero-day-flaw-found-in-linux-a-8808" says that most android phones are vulnerable, even with SELinux enabled, and that it might just be harder.
I realize that I am not a developer and wouldn't understand at all how these vulnerabilities work, but I am just hoping that someone sees this. sorry I cannot post links yet.

Here's an active link for those interested- http://perception-point.io/2016/01/...f-a-linux-kernel-vulnerability-cve-2016-0728/
I actually came here looking for discussion about patching this newly discovered vulnerability, but the OP's question is intriguing to the non-developer.

windowsman01 said:
Hello all,
I was wondering if it would be possible for a developer to make use of vulnerability CVE-2016-0728 to gain root and inject SuperSU or others to gain permanent root on currently unrootable devices.
"perception-point(dot)io/2016/01/14/analysis-and-exploitation-of-a-linux-kernel-vulnerability-cve-2016-0728/"
Another article here "databreachtoday(dot)com/zero-day-flaw-found-in-linux-a-8808" says that most android phones are vulnerable, even with SELinux enabled, and that it might just be harder.
I realize that I am not a developer and wouldn't understand at all how these vulnerabilities work, but I am just hoping that someone sees this. sorry I cannot post links yet.
Click to expand...
Click to collapse
This is definitely something I'm interested in as well. I have a verizon galaxy s5 that my wife updated to latest lollipop and can't root it. If I could get super-su injected and then patch this it would be awesome!

I think there is potential.
However: "The vulnerability affects any Linux Kernel version 3.8 and higher. SMEP & SMAP will make it difficult to exploit as well as SELinux on android devices."

windowsman01 said:
Hello all,
I was wondering if it would be possible for a developer to make use of vulnerability CVE-2016-0728 to gain root and inject SuperSU or others to gain permanent root on currently unrootable devices.
Click to expand...
Click to collapse
some people are interested in it if you see the comments
https://gist.github.com/PerceptionPointTeam/18b1e86d1c0f8531ff8f

jb789 said:
Here's an active link for those interested- http://perception-point.io/2016/01/...f-a-linux-kernel-vulnerability-cve-2016-0728/
I actually came here looking for discussion about patching this newly discovered vulnerability, but the OP's question is intriguing to the non-developer.
Click to expand...
Click to collapse
A Dutch consumer organization (consumentenbond) is sueing Samsung for the lack of security updates on their devices.
Here a link in English.
Now i wonder. I have for example a smartphone from the Chinese manufacturer 'No.1". I think No.1 users will never get a update about for example 'Linux Kernel Vulnerability (CVE-2016-0728)'.
What do you think, is their a possibility that if the Dutch consumer organization wins the battle, that we can sue all Android device builders who lack the priority of Android security updates?
I just send this email to No.1, curious is they reply (guess not,probably select and past in trashbin) :
Hello No.1 employee.
First of all, i'm very satisfied about my No.1 X6800 smartphone.
But i'm a bit dissapointed when i ask a question as consumer, and don't get any reply of the manufacturer of my smartphone.
I asked long time ago for a recovery / update rom for the No.1 X6800 on your website as firmware download. I see other phones roms , but not the X6800 rom.
But now..
A big security leak is found in the Linux kernel. (Linux Kernel Vulnerability (CVE-2016-0728)).
So i hope that the build in update app of the X6800 will offer me a update in future days.
May i remind you for the next thing: Consumentenbond takes Samsung to court for its poor update policy for smartphones.
Here a link: https://www.consumentenbond.nl/nieuws/attachment/20160118_Consumentenbond_takes_Samsung_to_court.pdf
Then i think, isn't it your duty to give us consumers of No.1 smartphones Android security updates ?
Click to expand...
Click to collapse

Sounds like it's unlikely to be exploited on Android, but still, it should be patched:
http://www.zdnet.com/article/how-to-fix-the-latest-linux-and-android-zero-day-flaw/