Related
Hey,
I have some experience with eFuses and I just wanted to offer some incite, as you know the whole bricking thing has been debunked and what not so no reason to worry.
What I did want to go over is what would happen if Motorola did choose to pop a eFuse. This type of security measure is not really meant to brick the device but to prevent downgrades in general.
Imagine a cave where TNT is placed by the opening, the eFuse purpose to collapse any possibility to downgrade the phone or boot loader. As in the Droid most people use the Motorola RDS tool to downgrade the phone so you have the available security holes needed. Blowing the eFuse would prevent this. Send out patch, then blow eFuse.
That being said they have not done anything like this with any of the current phones and would most likely avoid doing it to the Droid X. Even if they chose to do this it would be a big task to take on and would be risky.
Apple has not done it, nor Motorola. The only example I can think of when the xbox 360 was hacked and the team notified Microsoft about and they actually blew the eFuse to prevent and kernel downgrades and it worked.
Just thought I would share some information with the lot here at XDA
See ya
First of all: I'm an OSS advocate and love the idea of open source. Don't forget that while reading this.
Some 2 month ago, I got myself a Galaxy S. It's not exactly cheap, but on the other side, it's really good hardware. This thread is not about Samsung or the Galaxy S. It's about the missing parts of android security.
We all know it from our home computers: Software sometimes has bugs. Some just annoy us, others are potentially dangerous for our beloved data. Our data sometimes gets stolen or deleted due to viruses. Viruses enter our machines by exploiting bugs that allow for code execution or priviledge escalation. To stay patched, we regularly execute our "apt-get update;apt-get dist-upgrade" or use windows update. We do this to close security holes on our systems.
In the PC world, the software and OS manufacturers release security bulletins to inform users of potentially dangerous issues. They say how to work around them or provide a patch.
How do we stay informed about issues and keep our Android devices updated?
Here's what Google says:
We will publicly announce security bugs when the fixes are available via postings to the android-security-announce group on Google Groups.
Click to expand...
Click to collapse
Source: http://developer.android.com/guide/appendix/faq/security.html#informed
OK, that particular group is empty (except for a welcome post). Maybe there are no bugs in Android. Go check yourself and google a bit - they do exist.
"So why doesn't Google tell us?", you ask. I don't know. What I know is that the various components of Android (WebKit, kernel, ...) do have bugs. There's nothing wrong with that BTW, software is made by people - and people make mistakes and write buggy code all the time. Just read the changelogs or release notes.
"Wait", I head you say, "there are no changelogs or release notes for Android releases".
Oh - so let's sum up what we need to stay informed about security issues, bugs and workarounds:
* Security bulletins and
* Patches or Workaround information
What of these do we have? Right, nada, zilch, rien.
I'll leave it up to you to decide if that's good common practise.
"But why is this important anyway", you ask.
Well, remember my example above. You visit a website and suddenly find all your stored passwords floating around on the internet. Don't tell me that's not possible, there was a WebKit bug in 2.2 that did just that. Another scenario would be a drive-by download that breaks out of the sandbox and makes expensive phone calls. Or orders subscriptions for monthly new ringtones, raising your bill by orders of magnitute. Or shares your music on illegal download portals (shh, don't tell the RIAA that this is remotely possible).
The bug is probably fixed in 2.2.1 - but without changelogs we can't be sure.
But that's not all - there's a second problem. Not only are we unaware of security issues, we also don't have automated update mechanisms.
We only receive updates when our phone's manufacturers release new firmware. Sadly, not all manufacturers support their phones in the long run.
In the PC world, most Distros have a central package management - that Google forgot to implement in Android. Agreed, some phones can receive OTA updates, but that depends on the carrier. And because of the differences in Android versions it's not possible to have a central patch management either. So we do not know if our Android devices might have security issues. We also have no easy way to patch them.
Perhaps you knew this before, then I apologize for taking your time.
What do YOU - the computer literate and security aware XDA users - think about this? Do you think that's a problem? Or would you rather say that these are minor problems?
Very intresting, thanks! The update problem should be fixed with the next release, no more custom UIs and mods from phone manufacturers,at least google said that
Sent from my Nexus One using XDA App
Excellent post and quite agree with you. The other significant problem looming is the granularity (or rather, lack thereof) in app permissions which can cause problems you describe without bugs and exploits. I install an app that does something interesting with contacts and also has internet access to display ads. How do I know that my contacts are not encrypted, so making sniffing useless, and beamed back to mummy? Nothing other than blind trust!
I love Android but it's an accident waiting to happen unless the kind of changes you advocate are implemented and granularity of permissions significantly increased. I don't like much about Apple but their walled garden app store is something they did get right although IMHO, they also abuse that power to stifle competition. Bring out the feds!
simonta said:
The other significant problem looming is the granularity (or rather, lack thereof) in app permissions [...]
How do I know that my contacts are not encrypted, so making sniffing useless, and beamed back to mummy? Nothing other than blind trust!
Click to expand...
Click to collapse
I agree, although I'm not sure that less experienced users might have difficulties with such options.
simonta said:
I love Android but it's an accident waiting to happen
Click to expand...
Click to collapse
Sad but true. I'm just curious what Google will do when the first problems arise and the first users will have groundshaking bills.
If that happens to just a few users, it'll get a kind media coverage Google surely won't like.
I've seen quite a few android exploits posted on bugtraq over the years. It's a high-volume email list, but with some filtering of stuff you don't care about, it becomes manageable. It's been around forever and is a good resource if you want the latest security news on just about anything computer related.
http://www.securityfocus.com/archive/1/description
People are bashing a lot about the Android security model but the truth is you can never have 100% protection with ANY solution.
Apple is not allowing any app in their store. Fine. but mostly they are only filtering out apps that crash, violate some rules or they just don't like them or whatever. but they can never tell what an app is really doing. Therefore they would neeed to reverse-engineer every app they get etc. That's just impossible considering the amount of apps....
Speaking again of Android. I think the permission model is not bad. I mean, no other OS got such detailed description about what an app can do or not. But unfortunately it can only filter out very conspicuous apps, i.e. a Reversi game asking for your location and internet access. But then you never know... if the app is using ads it requires location and internet access, right? so what can you do?
RAMMANN said:
Apple is not allowing any app in their store. Fine. but mostly they are only filtering out apps that crash, violate some rules or they just don't like them or whatever. but they can never tell what an app is really doing. Therefore they would neeed to reverse-engineer every app they get etc. That's just impossible considering the amount of apps....
Click to expand...
Click to collapse
Not really, they do blackbox testing and let the apps run on emulated devices they then check if the app "behaves" as desired...
Of course you can't get 100% security and I don't think that's what we're saying, but there is a lot you can do.
Take for example internet access which is the biggest worry I have. The only reason most apps request internet access is to support ads. I now have a choice to make, don't use the app or trust it. That simple, no other choice.
If I installed an app that serves ads but did not have internet access, then the only way that app can get information off my phone is to use exploits and I'm a lot more comfortable knowing that some miscreant needs to understand that than the current situation where some script kiddy can hoover up my contacts.
However, if internet access and ad serving were separate permissions, you could in one hit address, taking a wild guess, 90% of the risk from the wild west that is Marketplace. With a bit more design and work, it would be possible to get the risk down to manageable and acceptable levels (at least for me).
I absolutely agree with you on Apple, one of the main reasons that I chose a Desire instead of an iPhone, but the Android approach is too far the other way IMHO.
Just my tuppence, in a hopeless cause of imagining someone at Google paying attention and thinking you know what, it is an accident waiting to happen.
marty1976 said:
Not really, they do blackbox testing and let the apps run on emulated devices they then check if the app "behaves" as desired...
Click to expand...
Click to collapse
Well, so why did a tethering app once make it into the appstore?
Also I think there are many possibilities for an app to behave normal, and just start some bad activity after some time. Wait a couple months until the app is spread around and then bang. Or remotely launch some action initiated through push notifications etc.
If there is interest, then there is always a way....
simonta said:
However, if internet access and ad serving were separate permissions, you could in one hit address, taking a wild guess, 90% of the risk from the wild west that is Marketplace. With a bit more design and work, it would be possible to get the risk down to manageable and acceptable levels (at least for me).
Click to expand...
Click to collapse
I agree that a seperate permission for ads would be a good thing.
But there are still many apps which need your location, contacts, internet access.... all the social media things nowadays. And this is where the whole thing will be going to so I think in the future it will be even harder to differenciate.
Getting back on topic: I just read that Windows 7 Phone will get updates and patches like desktop windows. That means patchday once a month plus when urgency is high...
simonta said:
However, if internet access and ad serving were separate permissions, you could in one hit address, taking a wild guess, 90% of the risk from the wild west that is Marketplace. With a bit more design and work, it would be possible to get the risk down to manageable and acceptable levels (at least for me).
Click to expand...
Click to collapse
But, how do you distinguish them? Today, (as a developer) I can use any ad-provider I want. In order to distinguish ads from general internet access, the OS would need one of:
A Google-defined ad interface, which stifles "creativity" in ad design. Developers would simply ignore it and do what they do now as soon as their preferred ad-provider didn't want to support the "official" ad system or provided some improvement by doing so.
An OS update to support every new ad-provider (yuck^2).
Every ad-provider would have to go through a Google whitelist that was looked up on the fly (increased traffic, and all ads are now "visible" to Google whether Google is involved in the transaction or not). This would also make ad-blocking apps harder to implement since Google's whitelisting API might not behave if the whitelist was unavailable. On the upside, it would make ad-blocking in custom ROMs be trivial.
Even if Google did one of these things, it still wouldn't provide any real increase in privacy or security. The "ad service" would still need to deliver a payload from the app to the service (in order to select ads) and another from the service to the app (the ad content). Such a mechanism could be trivially exploited to do anything that simple HTTP access could provide.
http://code.google.com/p/android/issues/list
issues submitted are reviewed by google employed techs... they tell you if you messed up and caused the issue or if the issue will be fixed in a future release or whatever info they find.
probably not the best way to handle it but its better then nothing.
twztdwyz said:
http://code.google.com/p/android/issues/list
Click to expand...
Click to collapse
Knew that bug tracker, but the free tagging aka labels isn't the best idea IMHO.
You can't search for a specific release, for example...
twztdwyz said:
probably not the best way to handle it but its better then nothing.
Click to expand...
Click to collapse
Ack, but I think Google can do _much_ better...
Two more things to have in mind:
1. I doubt that many Android users bother much about what permissions they give to an app.
2. Using Google to sync your contacts and calendar (and who knows what else), is a bad, bad idea.
QuadRooter allows attackers to take complete control of Android devices, potentially exposing your sensitive data to cybercrime.
However, there is no evidence of the vulnerabilities currently being used in attacks by cyberthieves.
"I'm pretty sure you will see these vulnerabilities being used in the next three to four months," said Michael Shaulov, head of mobility product management at Checkpoint. [BBC News]
Click to expand...
Click to collapse
Play Store link:
Check Point QuadRooter Scanner
Alternative: QuadRooter Scanner (less intrusive permissions)
CM (and other AOSPs) will get patched, but Stock 5.1? I suspect the only hope is that Motorola will release something for Moto G (2nd Gen) Stock 6.0, meaning Identity Crisis 6 can be made secure.
Why does a vulnerability check app require permissions for accounts and contacts?
Also, has anyone already created a universal rooting tool based on this vulnerability?
_that said:
Why does a vulnerability check app require permissions for accounts and contacts?
Also, has anyone already created a universal rooting tool based on this vulnerability?
Click to expand...
Click to collapse
I don't know, but an alternative is available: QuadRooter Scanner.
It's early days, nothing so far - but maybe there is now hope for those CDMA users who want root.
So I'm vulnurable to 5 "things" according to that app. This is a general situation and not device specific, right?
Penemue said:
So I'm vulnurable to 5 "things" according to that app. This is a general situation and not device specific, right?
Click to expand...
Click to collapse
Google have said it's not really a big deal - more a case of a company (Checkpoint) scare-mongering to sell their software.
The Android feature 'Verify apps' essentially protects against malicious software if not ignored.
To answer your question, it depends on the device - the degree of vulnerability - but generally speaking most handsets are 'affected.'
Now it's clear there's a security problem with the official build of Oreo before Sept builds.. now all the Oreo roms and official roms have this vuneralablity... If you're gonna continue to publish them without replacing them with the sept security patch you may as well put a damn virus in you're roms cause that's basically what you're doing...
Pixelxluser said:
Now it's clear there's a security problem with the official build of Oreo before Sept builds.. now all the Oreo roms and official roms have this vuneralablity... If you're gonna continue to publish them without replacing them with the sept security patch you may as well put a damn virus in you're roms cause that's basically what you're doing...
Click to expand...
Click to collapse
What's the vulnerability?
Plain and simple the software needs removed.. doesn't that apply to the devs policy's which they agreed to here on xda not to publish anything which may be a threat to someone... So you know what should of happened is the devs should of removed the software right away. That never happened so I've lost all faith in theses devs and publishers of official software threads...
I ignore all posts where the word "of" is used instead of the correct "have" or at least the contraction ending in 've that sounds like of.
...should of happened
sliding_billy said:
I ignore all posts where the word "of" is used instead of the correct "have" or at least the contraction ending in 've that sounds like of.
...should of happened
Click to expand...
Click to collapse
I ignore all posts that don't make sense like the OP's and this thread.
Pixelxluser said:
Now it's clear there's a security problem with the official build of Oreo before Sept builds.. now all the Oreo roms and official roms have this vuneralablity... If you're gonna continue to publish them without replacing them with the sept security patch you may as well put a damn virus in you're roms cause that's basically what you're doing...
Click to expand...
Click to collapse
First, there are no Oreo roms. Secondly, the devs who support our phones for free owe you nothing. Lastly, you need more than 12 posts to be taken seriously about anything around here. And, you can never post enough to attain the right to throw around accusations about the devs who, again, support our phone for free.
Pixelxluser said:
Now it's clear there's a security problem with the official build of Oreo before Sept builds.. now all the Oreo roms and official roms have this vuneralablity... If you're gonna continue to publish them without replacing them with the sept security patch you may as well put a damn virus in you're roms cause that's basically what you're doing...
Click to expand...
Click to collapse
Tell us how you really feel!
Windows people ?
Sent from my Pixel using XDA-Developers Legacy app
Pixelxluser said:
Now it's clear there's a security problem with the official build of Oreo before Sept builds.. now all the Oreo roms and official roms have this vuneralablity... If you're gonna continue to publish them without replacing them with the sept security patch you may as well put a damn virus in you're roms cause that's basically what you're doing...
Click to expand...
Click to collapse
If this is the case all root and bootloader exploits need removing also.
Any bootloader exploits or method of rooting without and unlocked bootloader is a SIGNIFICANTLY large security risk.
Sent from my Pixel using Tapatalk
Are we going to remove ALL the old ROMs from XDA? SHEESH.
In before the lock.
One thing I've found out over the years with hacking Android you eventually get tired of doing just hacking so you move onto security... Well that's the case with me anyways. Getting rid of vuneralable software is actually a good thing...
There's a reason why malware is successful with Android, and it's one that still hasn't been addressed: most phones are using old software and haven't been patched against it.
Google does a lot of work to make Android secure and keep it that way. It pays people to find security exploits, works with hardware vendors like Qualcomm or NVIDIA to fix them if needed, then writes a patch that can be injected into the existing version with no fuss. If you have a Pixel or Nexus or BlackBerry product, you'll then get these patches. If you have any other phone you roll the dice and hope the people who made it care enough.
Pixelxluser said:
One thing I've found out over the years with hacking Android you eventually get tired of doing just hacking so you move onto security... Well that's the case with me anyways. Getting rid of vuneralable software is actually a good thing...
There's a reason why malware is successful with Android, and it's one that still hasn't been addressed: most phones are using old software and haven't been patched against it.
Google does a lot of work to make Android secure and keep it that way. It pays people to find security exploits, works with hardware vendors like Qualcomm or NVIDIA to fix them if needed, then writes a patch that can be injected into the existing version with no fuss. If you have a Pixel or Nexus or BlackBerry product, you'll then get these patches. If you have any other phone you roll the dice and hope the people who made it care enough.
Click to expand...
Click to collapse
Nobody hacks individual phones. They hack companies and clouds.
****! Hey, can y'all hold it for just a moment? Need to run to the store real quick. I'm out of popcorn.
Seriously, though, just simply rooting your phone is a security risk. Also, from what i've seen, the majority of ROM users are smart about what they download. It's the general public that downloads mischevious apps that spread viruses. And as someone else mentioned, the malware and viruses don't target one person's phone. They are free floating and latch onto whatever moron downloads it. Your phone is not exactly the best place to download all your porn
But seriously, there are exploits with every security patch...it's the reason we get them every month, lol. Android is great and I love it but the OS itself is full of holes that malware developers consistently take advantage of.
Couldnt say this better myself..
Security is engineered into everything we do
Our goal is to make Android the safest computing platform in the world. That's why we invest in technologies and services that strengthen the security of devices, applications, and the global ecosystem.
It's also one reason Android is open source. Being open allows us to tap into a global network of security talent full of innovative ideas that help make Android safer every day. Security experts around the world can review our code, develop and deploy new security technology, and contribute to Android’s protections.
As the Android ecosystem evolves, we continue to invest in leading-edge security ideas. And we want to share our knowledge openly with you. Explore below to learn about the latest technologies and information that help secure Android.
Adrian Ludwig
Director of Android Security
Pixelxluser said:
Now it's clear there's a security problem with the official build of Oreo before Sept builds.. now all the Oreo roms and official roms have this vuneralablity... If you're gonna continue to publish them without replacing them with the sept security patch you may as well put a damn virus in you're roms cause that's basically what you're doing...
Click to expand...
Click to collapse
With some custom ROMs whether or not the have the Sept security patch is probably the least of your problems, if security is a concern of yours... you should be more concerned with things like;
- what keys are they using to sign their ROM (Apks included). Did they generate their own private signing keys and platform keys, or did they just use a devkeys or keys provided in the SDK?
- what changes have they made to aosp sources or not integrate (or revert) that could reduce security?
- have they messed with android's security or permissions model?
- have they included legacy code (like forward porting), that may have been dropped in the first place do to being insecure (legacy mediaserver without seccomp integration).
- have they modified selinux policies in ways that potentially could open up attack vectors.
- does the ROM have odexing enabled? The fact is, odexing while useful for booting/loading programs faster, also has the side benefit of making an apk harder to tamper with...
- have any changes that have been made been audited, or verified for correctness?
...and the list goes on. You are worried about a monthly security patch, with a handful or two of fixes for CVEs, yet make no mention of far bigger concerns that may be present in XYZ custom ROM.
Just saying.
contribute to Android’s protections. Is one thing which is lacking from what I see... I hope you understand that there are underaged people who don't know any better about what's best for them and come running off to try to be the cool kids by rooting or adding unsecured software on their phones.. rooting is so crazy to do now a days you're all really going to the extremes by bypassing security features just so you can have root... That's not the message the younger generation should be taught... They should be taught the importance of how security works not 50 ways to bypass it... There's not a feature out there which Google wouldn't consider adding officially but also Google doesn't go off and use unofficial code to pull features from it would look bad for their business..
And as long as there's a community of underaged people who do go off and root and install unsecured software you might wanna lead by example and provide them with the best security you can... A child with unsecured software is scary that someone would open up security holes for them to be a possible victim and the best you're actually willing to do is try to remove yourself from the responsibility of being responsible for it by saying if you install our software you are responsible for any damages. You can't just publish something then go out and say you take no responsibility when by law you're still responsible for any damages cause you never legally got you're software that way...
Since you're the ones distributing the software you're liable for damages if there was a defect in you're product which was distributed.. security flaws and security bypasses count as defects in a product..
Distributorship and Liability
Even though the distributor is not responsible for manufacturing a product, it can be held liable in the event of defects. Under strict product liability laws, the seller, distributor, and manufacturer of a defective product can be held liable if a person is injured due to the defect. Though manufacturers are typically most responsible since they created the product, the liability can also fall to those that distribute or sell the defective items.
This liability law prevents the plaintiff from the need to prove the chain of supply. In order for any entity in the line of distribution to prove it has no fault, it would need to show which entity is actually responsible for the defect
I suggest you stick with Windows dude
The only thing your posts are good for is making people spit their coffee with humour, and embarrassing yourself.
Sent from my Pixel using XDA-Developers Legacy app
So what realistically are the time frames on getting a new root and BL unlock for the snapdragon chipsets?
I ask since now the leak that happened means keys and other information are public.
Here's the thing about real security that has been properly implemented: a source leak doesn't compromise the security of the system. Thus, there is no realistic time frame, because there is no guarantee that a source leak will even result in a bootloader unlock method. A source leak will give insight into how the system works, and it might even expose a vulnerability, but even if revealed, it doesn't mean it will translate into a practical bootloader unlock method.
Imagine for example this purely hypothetical speculation: the persistent state of the OEM unlock bit, in the steady partition or wherever it is stored, is not encrypted or protected by a secure hash. While such a hypothetical vulnerability represents an attack vector, it would likely still be problematic to activate, possibly even requiring direct physical access to the device's eMMC IC.
I've seen said leak. If you're hoping for such access, I'd recommend disabling updates for a while. As far as phones are concerned, the leak goes deep. We're talking certs, signing apps, source code, even qualcomm source.
I dont imagine it will be long.
FesterCluck said:
I've seen said leak. If you're hoping for such access, I'd recommend disabling updates for a while. As far as phones are concerned, the leak goes deep. We're talking certs, signing apps, source code, even qualcomm source.
Click to expand...
Click to collapse
There is a lot there for sure. That said, the Snapdragon (cinammon) bootloader trees seem a lot lighter than the Exynos (strawberry) bootloader trees.
On the Exynos side, "SATURN/bootloader/lib/sbl_security/ddi.c implements get_oem_unlock_val() which is called in a variety of places. I'm still trying to understand the relationship between the two instances of the OEM Unlock flag, that is FROM_RPMB vs. FROM_PERSISTENT. In the case of the latter, this seems to simply be stored in the clear as the last byte in the PERSISTENT partition, where 0 means locked, and 1 means unlocked. As such, it can probably be readily written via JTAG or directly to the eMMC in a matter analogous to how the PERSISTENT partition is deleted to clear FRP state in many YouTube videos, though admittedly these both require special tools and invasive physical access.
I assume there exists at least conceptually similar implementation on the Snapdragon side, but so far I have not found it.
@Badger50 if there is a better place for this development-oriented discussion please advise or move the thread as (a) there does not seem to be a lot of development-oriented discussion in this forum and (b) it is likely not very specific to S20 devices--it is likely to apply to many recent Samsung models.
sjevtic said:
@Badger50 if there is a better place for this development-oriented discussion please advise or move the thread as (a) there does not seem to be a lot of development-oriented discussion in this forum and (b) it is likely not very specific to S20 devices--it is likely to apply to many recent Samsung models.
Click to expand...
Click to collapse
I'll move it to the "Guides and News" section since that would be the more appropriate section. Thanks for the shout out.
I'd be happy to donate to make progress. Just bought a new S20 and of course it has v2 BL. So lmk if there is anything needed.