Heartbleed: Install Chromebleed on Chrome to Detect Affected Sites
Yesterday, OpenSSL’s biggest bug – Heartbleed – was announced, along with the fact that it affected some two thirds of the world’s websites.
Some pretty important sites have been affected by the security bug, including Yahoo, Flickr, Kickass Torrents and many more.
Visiting these sites until the vulnerability is fixed is a bit dangerous. While the situation hasn’t exactly changed over the past two years and users are still vulnerable to the same issues, more hackers could now attempt to exploit the bug.
Since any attacks conducted so far have left no traces, there’s no way of knowing exactly how many times the vulnerability was used to obtain data that should have been encrypted, be it passwords or banking information.
Now that Heartbleed has been exposed, sites are that much more in danger until they fix the security problem since, after all, if hackers didn’t known about the bug, they do now.
Along with the announcement, a patch has been made available for OpenSSL, as well as a small Chrome extension for those users who want to make sure they’re not browsing a website that is still exposed to the issue.
Dubbed “Chromebleed,” the tool uses a web service developed by Filippo Valsorda and checks the URL of the page. If affected by Heartbleed, a notification will be displayed.
The tool is in no way intrusive and takes a small place in the extensions bar to the right of the address bar in the browser. It can easily be removed at any time.
You can download Chromebleed from the Chrome Web Store or from Softpedia.
Sent from my SM-N900P using XDA Premium 4 mobile app
Not a very smart thing to install SOME application to run on your device to detect a security hole.
It's a nice way to trick people to install things they would not normally install.
Heartbleed is out in the air for a longer time, not from yesterday.
OpenSSL TLS flaw
Claims most all testers are flawed.
"Herein lies the problem with the detection tools..."
http://www.theguardian.com/technology/2014/apr/16/heartbleed-bug-detection-tools-flawed
A good look at the results of detection tools compared:
http://www.hut3.net/blog/cns---networks-security/2014/04/14/bugs-in-heartbleed-detection-scripts-
I know openSSL is free software, but maybe someone could pay them to have a few full time employees?
One plus ten or so volunteers? Not gonna catch everything :-$
Doesn't make sense to test for something you cannot fix. We should wait for updates from teh devs and that's the only thing we can do.
Can smartphones, particularly Android ones, be affected by this bug? I thought only windows are affected. Correct me if I'm wrong...
New funding for OpenSSL security audits etc.
av2588 said:
Can smartphones, particularly Android ones, be affected by this bug? I thought only windows are affected. Correct me if I'm wrong...
Click to expand...
Click to collapse
If you run Android 4.1.1. or similar early JB you might be still open to exploit.
Apr 15, 2014
The Heartbleed OpenSSL flaw affects the earliest version of Jelly Bean, which powers millions of activated Android devices.
Click to expand...
Click to collapse
http://www.citeworld.com/article/2143625/mobile-byod/heartbleed-android-jelly-bean-disaster.html
If you'd like to chek yourself out: https://play.google.com/store/apps/details?id=com.lookout.heartbleeddetector
This thing might be less likely in future.
Tech giants team up to prevent new 'Heartbleed' -- 04/24/14
Click to expand...
Click to collapse
http://thehill.com/policy/technology/204260-tech-giants-team-up-to-prevent-new-heartbleed
++++++++EDIT+++++++++
Sorry - I spoke too soon. Others may also be vulnerable to that heartbeat flaw
According to FireEye, Android apps can often bypass the operating system's libraries for cryptography and use their own native OpenSSL
libraries, which may not have been patched. Even though an app may be connecting to a secure, patched server, if the app itself uses
a vulnerable version of OpenSSL, the connection is still insecure, Hui Xue, senior engineer...
...
To add further insult to injury for end users, FireEye found that apps that claim to scan for the Heartbleed flaw on Android, for the most part,
don't really work. Looking at 17 different apps that claim to scan for Heartbleed ...
"Only two of them did a decent check on Heartbleed vulnerability of apps,"...
...
"We've also seen several fake Heartbleed detectors in the 17 apps, which don't perform real detections nor display detection results to users
and only serve as adware."
Click to expand...
Click to collapse
http://www.eweek.com/security/heartbleed-puts-150-million-android-app-downloads-at-risk.html
All 4.1.1 devices should be updated to 4.1.2 by manufacturers regardless of whether they were former flagships or entry level devices.
The Main Problem with KNOX
Is that end-users are left-out cold without any form of privacy control.
As cool as MDM is to the "enterprise" developer and from a hacker's
perspective, there's nothing attractive with this to the end-user. How
can the end-user be certain that his store-bought KNOX enabled device,
hasn't already been compromised by some "enterprise"?
Without fully transparent, open source and public KNOX documentation,
this will be practically impossible to answer. As far as we know from
recent past experiences, on how "curious" enterprises like Google,
Samsung and NSA have been, why should we trust them this time? Or what
about the mobile service providers themselves? We know from many recent
examples how companies like Verizon and AT&T have been spying on their
customers before.
What follows is a few enlightening excerpts from the latest KNOX
white-paper. Before reading this and having recent major KNOX related
developer issues, I have gone from a "KNOX-who-cares" person, to a vivid
Anti-KNOX-er! I will most likely stay that way, at least until our
devices are sold without KNOX, and only available as a voluntary device
add-on/feature, using open source as it's basis.
What about you? Would you be happy to walk around the streets with a
laptop that has a remote access tool that constantly tracks your every
move, picture, sound and friends you meet and call, all while not
informing of any of that? While being way beyond you control? In fact,
you will not even have any choice, if Godzilla and Samsung gets their
way, in the next year.
Attestation
Attestation offers verification of a mobile device's core system
software i.e, the boot loaders and the kernel, at runtime based on the
measurement data collected during trusted boot. Attestation can be
requested at any time by the enterprise's Mobile Device Management (MDM)
system. All security critical operations of attestation are performed in
Trustzone.
When requested, the Attestation feature reads the previously stored
measurement information and the fuse value (see Trusted Boot above) and
combines these data to produce an Attestation "verdict". This verdict,
which essentially an indicate for whether tampering has occured, is
simply returned to the requesting MDM. The Attestation result is
returned to the requesting MDM server with a signature based on the
device's unique "Attestation Certificate" that is configured in the
device during the manufacturing process. This ensures that the
Attestation verdict cannot be altered during transfer.
Any further action is determined by the enterprise's MDM security
policy. It might choose to detach from the device, erase the contents of
the secure application container, ask for the location of the device, or
any of many other possible security recovery procedures.
The KNOX Container
...
The enterprise can manage the container like any other IT asset using an
MDM solution. Samsung KNOX supports many of the leading MDM solutions on
the market. Container management is affected by setting policies in the
same fashion as those traditional MDM policies. Samsung KNOX Container
includes a rich set of policies for authentication, data security, VPN,
email, application blacklisting, whitelisting, etc.
...
The new container also allows enterprise IT administrators to control
the flow of information between the container and the rest of the
device. This allows enterprises to strike the right balance between
security and user productivity. Users can also control the data sharing
capability based on their personal preferences, within the limits
specified by the enterprise IT administrator.
Mobile Device Management (MDM)
Enrolling an Android device into a company’s MDM system typically begins
with the user downloading the agent application from the Google Play
store and then configuring it for work. Enterprises are facing
increasing help desk calls as more and more users are activating mobile
devices for work and run into issues during this process. In addition
the user is presented with prompts, privacy policies and license
agreements at various stages resulting in a poor overall experience.
The KNOX platform provides a unified enrollment solution that is simple
and intuitive, and eliminates many steps in the enrollment process.
The process begins with the employee navigating to a web page and
clicking on an enrollment link. The link to the original web page may be
provided to the employee via an e-mail or SMS, or via the company’s
internal or external website. Clicking on the enrollment link brings up
a screen that prompts for the user’s corporate email address. The device
then displays all notices for the user to accept, which include privacy
policies and agreements from Samsung, the MDM vendor and the enterprise.
Upon accepting the terms, the user is directed to a screen to enter the
password for the corporate account. If authentication is successful the
enrollment is complete. Any agent application required by the MDM server
is automatically downloaded and installed, without user intervention.
MDM vendors can take advantage of this feature and simplify the
onboarding process for enterprise users and significantly improve the
user experience and reduce support costs.
In a nutshell, this is legalized control and spying.
I believe the quoted features have to be enabled by the company paying for the subscription (ie employer providing the devices), which is pretty standard MDM. If you are going to agree to use a MDM (as such an employee would have to) I see no issue here unless I am missing something.
I would be much more worried about abuse of the baseband, than MDM software which isn't enabled by default. Much more likely, and better target.
E:V:A said:
The Main Problem with KNOX
Is that end-users are left-out cold without any form of privacy control.
As cool as MDM is to the "enterprise" developer and from a hacker's
perspective, there's nothing attractive with this to the end-user. How
can the end-user be certain that his store-bought KNOX enabled device,
hasn't already been compromised by some "enterprise"?
Without fully transparent, open source and public KNOX documentation,
this will be practically impossible to answer. As far as we know from
recent past experiences, on how "curious" enterprises like Google,
Samsung and NSA have been, why should we trust them this time? Or what
about the mobile service providers themselves? We know from many recent
examples how companies like Verizon and AT&T have been spying on their
customers before.
What follows is a few enlightening excerpts from the latest KNOX
white-paper. Before reading this and having recent major KNOX related
developer issues, I have gone from a "KNOX-who-cares" person, to a vivid
Anti-KNOX-er! I will most likely stay that way, at least until our
devices are sold without KNOX, and only available as a voluntary device
add-on/feature, using open source as it's basis.
What about you? Would you be happy to walk around the streets with a
laptop that has a remote access tool that constantly tracks your every
move, picture, sound and friends you meet and call, all while not
informing of any of that? While being way beyond you control? In fact,
you will not even have any choice, if Godzilla and Samsung gets their
way, in the next year.
Attestation
Attestation offers verification of a mobile device's core system
software i.e, the boot loaders and the kernel, at runtime based on the
measurement data collected during trusted boot. Attestation can be
requested at any time by the enterprise's Mobile Device Management (MDM)
system. All security critical operations of attestation are performed in
Trustzone.
When requested, the Attestation feature reads the previously stored
measurement information and the fuse value (see Trusted Boot above) and
combines these data to produce an Attestation "verdict". This verdict,
which essentially an indicate for whether tampering has occured, is
simply returned to the requesting MDM. The Attestation result is
returned to the requesting MDM server with a signature based on the
device's unique "Attestation Certificate" that is configured in the
device during the manufacturing process. This ensures that the
Attestation verdict cannot be altered during transfer.
Any further action is determined by the enterprise's MDM security
policy. It might choose to detach from the device, erase the contents of
the secure application container, ask for the location of the device, or
any of many other possible security recovery procedures.
The KNOX Container
...
The enterprise can manage the container like any other IT asset using an
MDM solution. Samsung KNOX supports many of the leading MDM solutions on
the market. Container management is affected by setting policies in the
same fashion as those traditional MDM policies. Samsung KNOX Container
includes a rich set of policies for authentication, data security, VPN,
email, application blacklisting, whitelisting, etc.
...
The new container also allows enterprise IT administrators to control
the flow of information between the container and the rest of the
device. This allows enterprises to strike the right balance between
security and user productivity. Users can also control the data sharing
capability based on their personal preferences, within the limits
specified by the enterprise IT administrator.
Mobile Device Management (MDM)
Enrolling an Android device into a company’s MDM system typically begins
with the user downloading the agent application from the Google Play
store and then configuring it for work. Enterprises are facing
increasing help desk calls as more and more users are activating mobile
devices for work and run into issues during this process. In addition
the user is presented with prompts, privacy policies and license
agreements at various stages resulting in a poor overall experience.
The KNOX platform provides a unified enrollment solution that is simple
and intuitive, and eliminates many steps in the enrollment process.
The process begins with the employee navigating to a web page and
clicking on an enrollment link. The link to the original web page may be
provided to the employee via an e-mail or SMS, or via the company’s
internal or external website. Clicking on the enrollment link brings up
a screen that prompts for the user’s corporate email address. The device
then displays all notices for the user to accept, which include privacy
policies and agreements from Samsung, the MDM vendor and the enterprise.
Upon accepting the terms, the user is directed to a screen to enter the
password for the corporate account. If authentication is successful the
enrollment is complete. Any agent application required by the MDM server
is automatically downloaded and installed, without user intervention.
MDM vendors can take advantage of this feature and simplify the
onboarding process for enterprise users and significantly improve the
user experience and reduce support costs.
In a nutshell, this is legalized control and spying.
Click to expand...
Click to collapse
jcase said:
I believe the quoted features have to be enabled by the company paying for the subscription (ie employer providing the devices), which is pretty standard MDM. If you are going to agree to use a MDM (as such an employee would have to) I see no issue here unless I am missing something.
I would be much more worried about abuse of the baseband, than MDM software which isn't enabled by default. Much more likely, and better target.
Click to expand...
Click to collapse
I don't know to what extent you're playing devils advocate, but I am still a bit surprised, you can't see any issues with this.
The issue is, that we're not able to see how this enabling mechanism work, and therefore cannot even make any half-baked guess if this is actually secure, or can be easily broken, abused or circumvented, if not so, already. In addition the MDM software is enabled by default, at least as far as my processes and device drivers present, shows. It's just not visibly activated, until you go through the signup procedures. Furthermore it seem that the MDM features are very well weaved into the baseband functionality. Not that baseband is using MDMD, but that MDM makes extensive use of the baseband and features not documented. But to what extent that is true, I can 't really say at this time, as I have not spent any time on it.
One more thing. They say that KNOX is a security "addition" to the default SELinux policies, but that is not the whole story. Actually it seem more that KNOX is replacing or overriding the SEL policies already present. How can we actually test and see this, when we're not even allowed (or given) the tools to do so?
E:V:A said:
I don't know to what extent you're playing devils advocate, but I am still a bit surprised, you can't see any issues with this.
The issue is, that we're not able to see how this enabling mechanism work, and therefore cannot even make any half-baked guess if this is actually secure, or can be easily broken, abused or circumvented, if not so, already. In addition the MDM software is enabled by default, at least as far as my processes and device drivers present, shows. It's just not visibly activated, until you go through the signup procedures. Furthermore it seem that the MDM features are very well weaved into the baseband functionality. Not that baseband is using MDMD, but that MDM makes extensive use of the baseband and features not documented. But to what extent that is true, I can 't really say at this time, as I have not spent any time on it.
One more thing. They say that KNOX is a security "addition" to the default SELinux policies, but that is not the whole story. Actually it seem more that KNOX is replacing or overriding the SEL policies already present. How can we actually test and see this, when we're not even allowed (or given) the tools to do so?
Click to expand...
Click to collapse
I'm not playing devils advocate, I'm saying that I don't think this is the route the NSA would take.
puzzled
I don't get it - I thought "knox" was just that thing that counts how many times you've flashed a custom rom (which can easily be removed and reset).
b
jcase said:
I'm not playing devils advocate, I'm saying that I don't think this is the route the NSA would take.
Click to expand...
Click to collapse
We are not able to see how any closed source security component works, and you investigate it the same way you investigate any closed source feature.
jcase said:
I'm not playing devils advocate, I'm saying that I don't think this is the route the NSA would take.
Click to expand...
Click to collapse
I think it's pointless to speculate in which route they would take, as they would certainly take whatever route available to accomplish their mission. Together with Google own INSTALL ASSET methods, MDM makes that even more simple on Samsungs.
I'm sure we'll see more posts like this in the near future.
FYI - How the NSA can 'turn on' your phone
E:V:A said:
I think it's pointless to speculate in which route they would take, as they would certainly take whatever route available to accomplish their mission. Together with Google own INSTALL ASSET methods, MDM makes that even more simple on Samsungs.
I'm sure we'll see more posts like this in the near future.
FYI - How the NSA can 'turn on' your phone
Click to expand...
Click to collapse
I'll make sure to remove such paranoia posts in the future, one is enough. I think a baseband attack is more likely, as it is more likely to impact more phones, from more OEMs, running more firmwares etc. The baseband is much harder to investigate as well, less people looking at it, more potential for bugs living longer, easier not to get noticed.
jcase said:
I'll make sure to remove such paranoia post in the future, one is enough. I think a baseband attack is more likely, as it is more likely to impact more phones, from more OEMs, running more firmwares etc. The baseband is much harder to investigate as well, less people looking at it, more potential for bugs living longer, easier not to get noticed.
Click to expand...
Click to collapse
Well, I'm not sure that post fulfill all the criteria of "paranoia", especially since it is mostly grounded in truth, apart from the CNN journalism. But my point is already there. When people have no insight or control over what's happening in their pockets, they start getting religiously paranoid. I guess from an anthropological point of view, paranoia has some kind of good survival function for the group. So it serves well as a counter balance to being completely ignorant.
E:V:A said:
Well, I'm not sure that post fulfill all the criteria of "paranoia", especially since it is mostly grounded in truth, apart from the CNN journalism. But my point is already there. When people have no insight or control over what's happening in their pockets, they start getting religiously paranoid. I guess from an anthropological point of view, paranoia has some kind of good survival function for the group. So it serves well as a counter balance to being completely ignorant.
Click to expand...
Click to collapse
It has been removed from the security forum, it is a copy paste of an article reportedly from cnn (no source link to back that), without any citations to the claims made. I will make a better effort to keep the forum accurate, and fud free in the future.
It has factual inaccuracies, and seems to be just a promo piece for a custom Android ROM that indeed has it's own issues.
@E:V:A
I do appreciate your posts, they are welcome here, but some of the posts ive been removing are just FUD, way out there or unsourced.
when I got my phone rooted and opened supersu, it suggested to disable KNOX. Before then, I didn't even know what KNOX is. I searched some information about it, looks like it is just security solution.
explanation
yueyejinghun said:
when I got my phone rooted and opened supersu, it suggested to disable KNOX. Before then, I didn't even know what KNOX is. I searched some information about it, looks like it is just security solution.
Click to expand...
Click to collapse
It's just a feature that counts how many times you've flashed a custom rom to your phone; easily removed and reset.
FIRST Read the OP and then the KNOX whitepaper.
and maybe someone will open this thread again...or remove it.
Is this something we have to worry about? Or, is it just click-bait?
http://www.wired.com/2016/01/hack-brief-years-old-linux-bug/
AN ISRAELI SECURITY research firm has come forward with a troubling discovery. A zero-day vulnerability in the Linux kernel has left “tens of millions” of Linux PCs and servers exposed, along with 66 percent of Android phones and tablets. And it’s been there for nearly three years.
The Hack
In a blog post detailing the issue, Perception Point researchers say that problem stems from the Linux keyring facility, essentially a locker where apps can stash authentication and encryption keys, security data, and other sensitive info. The bug, outlined in more depth here but described as “fairly straightforward,” can ultimately allow an attacker to pose as a local user and gain root access to a device.
This is bad! Root access can allow an attacker to do everything from installing malicious programs to deleting files to reading sensitive information on the device. Gaining access is also a simple enough matter; an attacker could use a simple phishing link to infiltrate the device.
Who’s Affected?
As far as Perception Point can tell, nobody so far. That’s some comfort, but maybe not much given the large number of potential targets.
“While neither us nor the Kernel security team have observed any exploit targeting this vulnerability in the wild,” says the Perception Point post, “we recommend that security teams examine potentially affected devices and implement patches as soon as possible.”
In addition to the “tens of millions” of Linux PCs and servers running Linux Kernel version 3.8 and higher, because Android shares some code with Linux, the vulnerability affects any Android device running version 4.4 or later. As of January 4, that adds up to 69.4 percent of all Android devices, even more than the researchers estimated. Basically, if you’ve bought or upgraded your Android device within the last two years or so, that device is vulnerable.
Update: Google has responded to Perception Point’s claims; in short, the company has prepared a patch and will make it available to partners today, and says that the range of affected devices may be “significantly smaller than initially reported.”
“We believe that no Nexus devices are vulnerable to exploitation by 3rd party applications,” writes Google’s Adrian Ludwig. “Further, devices with Android 5.0 and above are protected, as the Android SELinux policy prevents 3rd party applications from reaching the affected code. Also, many devices running Android 4.4 and earlier do not contain the vulnerable code introduced in linux kernel 3.8, as those newer kernel versions not common on older Android devices.”
How Serious Is This?
That something this potentially devastating went unnoticed for years is absolutely serious, especially given that Perception Point was able to put together a proof of concept exploit. In terms of actual exposure, the answer is mixed.
Things are already looking up on the enterprise side. Red Hat and Ubuntu have released their updates already, so now it’s just up to admins to implement them.
Android’s a slightly tricker story. While Google recently kicked off a monthly security update program, the company hasn’t yet said if a fix for this particular bug will be included in February’s, if not sooner. Even if it is, the update will need to work its way through the labyrinthine processes of the various carriers and hardware manufacturers that customize the operating system to their own liking. In short, there’s no telling how long it might take for all Android devices to be in the clear, if ever.
The good news is that all you really need to do to protect yourself is avoid suspicious links that might give a malicious actor access to your device. And if and when that security update does come through, install it. ASAP.
Before I begin, I'm not here to flame tbe devs as I would love this app if these issues weren't present and do hope this problem is resolved as a result of bringing it to the attention of the community and hopefully this app's devs.
This application has serious vulnerabilities, some of which should be quite easily patched yet have not been for months to a year or so of them having been made public by a reputable security researcher working for Zimperium.
Login information via the browser is not utilizing a secure form of encryption for both web.airdroid.com or when accessing via local IP despite their SSL cert being valid for *.airdroid.com. The key for the DES encryption being used to hash the password and e-mail being hardcoded into the application despite having a POC for an attack on their users is inexcusable and shows a blatant disregard for their application's level of access as well as their user's safety and security.
My finding (as a security noob) has also deeply disturbed me following no response to bug reports or email contact. While attempting to check out their Windows desktop client, my antivirus discovered the installer attempting to download a variant of adware which monitored the user's activities and provides monetary incentives to developers which include it within their programs and applications. I do understand that if something is free, the product is you. However, I am a paying customer of this service as I'm sure many who use xda would be in an effort to support development of software and applications we enjoy. This adware was ran through and confirmed with VirusTotal and certainly is not a false positive. This desktop client also does not use SSL for communication.
Due to discovering these problems, I immediately discontinued use (the same day I renewed my yearly subscription). However, I was unable to remove the application from my phone without a full factory reset even after both application updates and upgrading android versions. With it set as a device administrator, it's access must first be revoked before uninstalling. However, across multiple devices and versions of android, attempting to remove it from device administrators causes a crash of the android settings app.
I had planned to do a POC for what I feel is an extremely likely scenario based off both public vulnerabilities as well as what I had discovered myself, but I have been far too busy with a few other projects as well as work to complete it yet. I had just stumbled across this section of the xda forums while looking for something else and hoped to get a response from the devs of this app.
I would love to be able to utilize an app with this functionality. However, there needs to be far more focus on security in its design before I would ever feel comfortable utilizing it again.
In theory, it would be entirely possible for an unstable, technically inclined person at a local coffee shop (or other public location with unsecured an wireless network) to hijack a user's login information with minimal skill level required then giving them full, unadulterated access to the application's functions such as forcing gps or camera on to track or watch someone without their consent as all connections aren't even requiring the user to accept the incoming connection on their phone to perform these actions. That is not a farfetched scenario and presents a possible threat to someone's physical safety.
Link to said researcher's findings can be found on his blog by searching Zimperium airdroid multiple vulnerabilities as I just created this account for this post and can not yet post outside links.
Thanks a lot for all this information. I really appreciate it.
Why hasn't this been addressed yet?
I remember reading this a while ago, realizing that it is a serious issue, and just how little the devs care about security on their app.
This is mainly because most end-users don't dive this deep into an app, and don't fully comprehend the severity of such vulnerabilities until it is too late.
We should make a bigger fuss about these things!
I've always been very careful with RAT-type apps and so I was when checking out AirDroid. I've uninstalled it after 30 minutes of using, just because I didn't like the fact, there's a chance some undesirable person could start spying on me. As I read this thread, I'm realising how right I was that time.
From https://source.android.com/security/bulletin/2017-12-01 --
The most severe vulnerability in this section could enable a remote attacker using a specially crafted file to execute arbitrary code within the context of a privileged process.
Thoughts on this one, guys?
Any possibility this could be mitigated somehow, short of tossing the Android device in the trash and buying an iPhone instead?
In particular, is there any way to just disable the mediaserver or whatever altogether? It would be much better to not be able to play videos, than the possibility of any video pwning your entire device, no?
Vulnerabilities like these are patched almost every month (just have a look at the bulletins of the months before), so this one doesn't seem any worse than those that have been there before. To the best of my knowledge, neither of these have ever been exploited in the wild - not even Stagefright back in 2015, according to Google: https://www.theregister.co.uk/2017/02/15/google_stagefright_android_bug_zero_success/
Note that the security bulletin you linked to also states the following:
"The severity assessment is based on the effect that exploiting the vulnerability would possibly have on an affected device, assuming the platform and service mitigations are turned off for development purposes or if successfully bypassed."
Click to expand...
Click to collapse
I hope they can't be bypassed too easily...
What I don't understand is what 'privileged' means here. Does it mean 'root' or does it relate to Android app permissions? The former sounds much worse, and I'd find it alarming if the media framework stuff would (still) run as root (or something similar). Would be great if someone could clarify this.
As I tend to be kinda paranoid when it comes to computer security, I'm also always worried by issues like these, but my impression is it's probably something we have to live with :-/
In particular, I don't see a reason to believe the iPhone is more secure (apart from the fact that it receives regular updates in contrast to most Android phones...)
One would probably be better off with a system that is so exotic that no one would bother to develop an exploit for it - unfortunately, I haven't found one so far...