App developer says can't allow screenshots because of Android security issue - General Questions and Answers

Hi there, my organization is a paid user of an app. Prior to the latest version of that app, screenshot ability was possible on Android and iOS devices. However, a recent update disabled the ability to take a screenshot only on Android but not iOS. When I try to take a screenshot, this is the message that a appears on screen: "This action isn't allowed by the app or your organization" I've contacted the app developers and they have said they're working on a solution. This was over a year ago. I've reached out to them recently, and this is their response: "Unfortunately, screenshots are still not available on Android devices. As [name] may have already told you, this lack of functionality is because of a known security issue in Google's OS. We are still actively waiting for Google to update this security flaw so that we can add the feature to our Android app."
Is anyone aware of this security flaw in Android OS that would necessitate the inability to take a screenshot?

Related

Has anyone else received this?

[email protected]
to me
You are receiving this message to inform you of a critical issue affecting your Android Market account.
Hello,
We recently discovered applications on Android Market that were designed to harm devices. These malicious applications ("malware") have been removed from Android Market, and the corresponding developer accounts have been closed.
According to our records, you have downloaded one or more of these applications. This malware was designed to allow an unauthorized third-party to access your device without your knowledge. As far as we can determine, the only information obtained was device-specific (IMEI/IMSI, unique codes which are used to identify mobile devices, and the version of Android running on your device).
However, this malware could leave your device and personal information at risk, so we are pushing an Android Market security update to your device to remove this malware. You will soon be receiving a notification on your device that says "Android Market Security Tool March 2011" has been installed. You are not required to take any action from there, the update will automatically run. You may also receive notification(s) on your device that an application has been removed. Within 24 hours of receiving the update, you will receive a second email confirming its success.
To ensure this update is run quickly, please make sure that your device is turned on and has a strong network connection.
For more details, please visit the Android Market Help Center at
http://market.android.com/support/bin/answer.py?answer=1207928
Regards,
The Android Market Team
©2011 Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
Email preferences: You are receiving this email to notify you of a critical issue affecting your Android Market account.
It's legit. I read that Google was going to push an update to anyone's phone who they determined had downloaded the malware. You can find info about it on the web. I read it on Drudge yesterday.
Sent from my HTC Glacier using XDA App
Have not received that but just saw a report about it on the news...
Legit. It was on Engaget.com.
Sent from my HTC Glacier using XDA App
What really cracks me up is they never have told me what item I downloaded from the Market that has an exploit. It probably was that damn Kongergate app. I knew that damn bunny on those commercials had a sinister plot!!!!
I use Lookout as a good backup/security program that caught a malware that woke my phone about 2am to call a foreign country...

What Google should really do to remove fragmentation across Android

What Android needs to do in order to control/remove the fragmentation, is have it MANDATORY that all handsets run VANILLA ANDROID as the base, BUT allow system overlays (Samsung/Moto/HTC/LG etc.) to be installed as SYSTEM APPS or perhaps even user apps.
With this in place, the code would not have to be modified heavily by individual manufactures prior to reaching each handset, each update could in fact roll-out DIRECTLY from GOOGLE to the phone and THEN the manufactures can update their system apps via another route or perhaps have a "system app update section" available through the Play Store.
The major change currently being integrated into Android on KitKat+ to reduce fragmentation is the moving of as much of the Android content to Apps on the Play Store anyway, so that handsets running older versions of Android can still have access to the new UI with up-to-date apps.
Apply this SAME technique to the Overlays produced by each manufacture and almost every handset could be on a Vanilla Android Base, with system/user apps over top.
Is fragmentation all that bad?
Its really just another word to describe the diversity in the android ecosystem. This freedom of diversity leads to innovation.
Lack of updates and unfixed bugs? I wouldn't call that diversity. Many Android users never get to experience Android at its best because they choose a 3rd party handset and get stuck back in time. This is a major major flaw IMO.
Sent from my Nexus 4 using Tapatalk 4

[official][discussions] leaked version of BBM"black berry messnger" /Update #3

[official][discussions] leaked version of BBM"black berry messnger" /Update #3
General discussion of the BBM application for Android.
Last update on 09/23/2013
Quote:
hi Android and iPhone users,
This is Andrew Bocking, head of BBM at BlackBerry. As a follow up to our first blog post on Saturday, I want to take a moment to provide you with an update on the rollout of BBM on Android and iPhone.
Last week, an unreleased, older version of the BBM for Android app was posted on numerous file sharing sites. We were aware of an issue with this unreleased version of the BBM for Android app. This older version resulted in volumes of data traffic orders of magnitude higher than normal for each active user and impacted the system in abnormal ways. The version we were planning to release on Saturday addressed these issues, however we could not block users of the unreleased version if we went ahead with the launch.
We attempted to address the problems caused by the unreleased version throughout the day on Saturday, but as active users of the unreleased app neared a million – and accelerated – it became clear that the only way to address the issue was to pause the rollout for both Android and iPhone.
The team is now focused on adjusting the system to completely block this unreleased version of the Android app when we go live with the official BBM for Android app. We are also making sure that the system is reinforced to handle this kind of scenario in the future. While this may sound like a simple task – it’s not. This will take some time and I do not anticipate launching this week.
Thank you for your patience while we take the time needed to deliver the experience you expect from BBM. We will continue to provide you with updates here on InsideBlackBerry.com and through @BBM on Twitter. We will notify everyone who has pre-registered on BBM.com when BBM is available on Android and iPhone."-Andrew Bocking, EVP, BBM
Click to expand...
Click to collapse
Don't wait my friend,,,
Sent from my Xperia Arc S using xda app-developers app

CyanogenMod for Archos Platinum 45??

Is there a cm rom version that will work on Archos 45 plat?? Or any other good rom??
ZuEma said:
Is there a cm rom version that will work on Archos 45 plat?? Or any other good rom??
Click to expand...
Click to collapse
In case you might want to give it a try, you could start with rooting according to this thread:
http://forum.xda-developers.com/showthread.php?t=2573743
NOTE:- Archos 45 Platinum too has similar device specifications. The same CWM version worked for @best98 who is using an Archos 45 Platinum.
Click to expand...
Click to collapse
I guess there is a need now to step up to KitKat or newer, if the Webos security hole is not hashed out by other ways on devices running JB 4.3 or lower
Tod Beardsley
Google No Longer Provides Patches for WebView Jelly Bean and Prior
Gepostet von Tod Beardsley in Metasploit auf 12.01.2015 00:19:38
Over the past year, independent researcher Rafay Baloch (of "Rafay's Hacking Articles") and Rapid7's Joe Vennix have been knocking out Android WebView exploits somewhat routinely, based both on published research and original findings. Today, Metasploit ships with 11 such exploits, thanks to Rafay, Joe, and the rest of the open source security community. Generally speaking, these exploits affect "only" Android 4.3 and prior -- either native Android 4.3, or apps built with 4.3 WebView compatibility. sadjellybeans_t.png
WebView is the core component used to render web pages on an Android device. It was replaced in Android KitKat (4.4) with a more recent Chromium-based version of WebView, used by the popular Chrome browser.
Despite this change, though, it’s likely there will be no slow-down of these Android security bugs, and they will probably last a long time due to a new and under-reported policy from Google's Android security team: Google will no longer be providing security patches for vulnerabilities reported to affect only versions of Android's native WebView prior to 4.4. In other words, Google is now only supporting the current named version of Android (Lollipop, or 5.0) and the prior named version (KitKat, or 4.4). Jelly Bean (versions 4.0 through 4.3) and earlier will no longer see security patches for WebView from Google, according to incident handlers at [email protected].
Up until recently, when there's a newly discovered vulnerability with Android 4.3, the folks at Google were pretty quick with a fix. After all, most people were on the "Jelly Bean" version of Android until December of 2013. Jelly Bean's final release was just over a year ago in October of 2013. This is why this universal cross-site scripting bug was fixed, as seen in the Android changelog and Rafay's blog, Rafay Hacking Articles.
Google on Patching pre-KitKat
However, after receiving a report of a new vulnerability in pre-4.4 WebView, the incident handlers at [email protected] responded with this:
If the affected version [of WebView] is before 4.4, we generally do not develop the patches ourselves, but welcome patches with the report for consideration. Other than notifying OEMs, we will not be able to take action on any report that is affecting versions before 4.4 that are not accompanied with a patch.
So, Google is no longer going to be providing patches for 4.3. This is some eyebrow-raising news.
I've never seen a vulnerability response program that was gated on the reporter providing his own patch, yet that seems to be Google's position. This change in security policy seemed so bizarre, in fact, that I couldn't believe that it was actually official Google policy. So, I followed up and asked for confirmation on what was told to the vulnerability reporter. In response, I got a nearly identical statement from [email protected]:
If the affected version [of WebView] is before 4.4, we generally do not develop the patches ourselves but do notify partners of the issue[...] If patches are provided with the report or put into AOSP we are happy to provide them to partners as well.
When asked for further clarification, the Android security team did confirm that other pre-KitKat components, such as the multi-media players, will continue to receive back-ported patches.
Sorry, Jelly Bean, You're Too Old
Google's reasoning for this policy shift is that they "no longer certify 3rd party devices that include the Android Browser," and "the best way to ensure that Android devices are secure is to update them to the latest version of Android." To put it another way, Google's position is that Jelly Bean devices are too old to support -- after all, they are two versions back from the current release, Lollipop.
On its face, this seems like a reasonable decision. Maintaining support for a software product that is two versions behind would be fairly unusual in both the proprietary and open source software worlds; heck, many vendors drop support once the next version is released, and many others don't have a clear End-Of-Life (EOL) policy at all. (An interesting side note: neither Google nor Apple have a published EOL policy for Android or iOS, but Microsoft and BlackBerry provide clear end of life and end of sales dates for their products).
Most Android Devices Are Vulnerable
While this may be a normal industry standard, what's the situation on the ground? Turns out, the idea that "pre-KitKat" represents a legacy minority of devices is easily shown false by looking at Google's own monthly statistics of version distribution:
As of January 5, 2015, the current release, Lollipop, is less than 0.1% of the installed market, according to Google's Android Developer Dashboard. It's not even on the board yet.
The next most recent release, KitKat, represents about two fifths of the Android ecosystem. This leaves the remaining 60% or so as "legacy" and out of support for security patches from Google. In terms of solid numbers, it would appear that over 930 million Android phones are now out of official Google security patch support, given the published Gartner and WSJ numbers on smartphone distribution).
The Economics of Upgrading
Beside the installed bases, I posit that the people who are currently exposed to pre-KitKat, pre-Chromium WebView vulnerabilities are exactly those users who are most likely to not be able to "update to the latest version of Android" to get security patches. The latest Google Nexus retails for about USD$660, while the first hit for an "Android Phone" on Amazon retails for under $70. This is a nearly ten-fold price difference, which implies two very different user bases; one market that doesn't mind dropping a few hundred dollars on a phone, and one which will not or cannot spend much more than $100.
Taken together -- the two-thirds majority install base of now-unsupported devices and the practical inability of that base to upgrade by replacing hardware -- means that any new bug discovered in "legacy" Android is going to last as a mass-market exploit vector for a long, long time.
Here Come the Mass-Market Exploits
This is great news for penetration testers, of course; picking company data off of Android phones is going to be drop-dead easy in many, many cases, and I fully expect that handsets will be increasingly in-scope for penetration testing engagements. Unfortunately, this is great news for criminals for the simple reason that, for real bad guys, pretty much everything is in scope.
Open source security researchers routinely publish vulnerability details and working exploits with the expectation that this kind of public discussion and disclosure can get both vendors and users to take notice of techniques employed by bad guys. By "burning" these vulnerabilities, users come to expect that vendors will step up and provide reasonable defenses. Unfortunately, when the upstream vendor is unwilling to patch, even in the face of public disclosure, regular users remain permanently vulnerable.
Roll Your Own Patches?
It's important to stress that Android is, in fact, open source. Therefore, it's not impossible for downstream handset manufacturers, service providers, retailers, or even enthusiastic users to come up with their own patches. This does seem to happen today; a 4.3 vulnerability may affect, say, a Kyocera handset, but not a Samsung device with the "same" operating system.
While this is one of the core promises of open source in general, and Android in particular, it's impossible to say how often this downstream patching actually happens, how often it will happen, and how effective these non-Google-sourced patches will be against future "old" vulnerabilities.
The update chain for Android already requires the handset manufacturers and service carriers to sign off on updates that are originated from Google, and I cannot imagine this process will be improved once Google itself has opted out of the patching business. After all, is AT&T or Motorola really more likely to incorporate a patch that comes from some guy on the Internet?
No Patches == No Acknowledgement
To complicate matters, Google generally does not publish or provide public comment on Android vulnerabilities, even when reported under reasonable disclosure procedures. Instead, Android developers and consumers rely on third party notifications to explain vulnerabilities and their impact, and are expected to watch the open source repositories to learn of a fix.
For example, Google's only public acknowledgement of CVE-2014-8609, a recent SYSTEM-level information disclosure vulnerability was a patch commit message on the Lollipop source code repository. Presumably, now that Google has decided not to provide patches for "legacy" Android WebView, they will also not be providing any public acknowledgement of vulnerabilities for pre-KitKat devices at all.
Please Reconsider, Google
Google's engineering teams are often the best around at many things, including Android OS development, so to see them walk away from the security game in this area is greatly concerning.
As a software developer, I know that supporting old versions of my software is a huge hassle. I empathize with their decision to cut legacy software loose. However, a billion people don't rely on old versions of my software to manage and safeguard the most personal details of their lives. In that light, I'm hoping Google reconsiders if (when) the next privacy-busting vulnerability becomes public knowledge.
Click to expand...
Click to collapse

Android Marshmallow permissions dialog tapjacking vulnerability

For a long time Android had a number of “tapjacking” vulnerabilities. They were supposed to be fixed in Marshmallow but they didn’t. Instead users got some awkward permission dialog which can be easily bypassed.
Tapjacking got especially dangerous in Marshmallow with introduction of runtime permission. Now the permission dialog can be hijacked by the malicious app.
You can see a demo of such exploit on my GitHub.
It’s just a demo so not all the alignment, synchronization are perfect but it clearly shows that it’s possible to hijack Marshmallow permission dialogs.
I reported this issue to Google long ago and submitted patches to AOSP Gerrit but apparently they’re not taking it seriously. Maybe by sharing it here at least it’ll get fixed in some open-source ROMs.

Categories

Resources