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.
Related
I came across this article while surfing the internet. I wanted to share this with you guys, and see what your feelings were on this.
"Mobile Device Security and Android File Disclosure
Back in November, Thomas Cannon brought to light an issue within the Android operating system. Specifically, he found that it was possible to obtain the contents of files on an Android device by simply persuading its owner to visit a web site under attacker control. The issue only garners a 3.5 CVSS score, but yet it’s still fairly serious.
Thomas reported this issue responsibly to Google and they took it seriously. However, since then they have come back with a ridiculous remediation plan. Granted, its probably not entirely Google’s fault, but the overall situation looks very bleak for Android.
The problem is that Google stated that a fix will be available as part of an update to the upcoming Android 2.3. While that, in itself, may not be totally ridiculous, the reality of the situation is that Google is only one party involved in Android. There are two other groups, namely OEMs and Carriers, that must also do their part in getting the fix to users. Although Android devices are becoming increasingly functional, the security posture remains abysmal.
The security posture for desktop applications has improved vastly with all of the sand-boxing, automatic updates, and various other exploit mitigation technologies. Meanwhile, Android includes almost none of existing security protections. In fact, mobile users are being left out in the cold, unable to get a patch for a trivially exploitable cross-zone issue. For that matter, they can’t even control whether their device’s browser automatically downloads files or not.
This situation is not news, rather it is a sad fact. It is totally unfair for end users to be left out to fend for themselves. After all, they are paying a small fortune for these devices and the service to be able to use them. Hopefully the vendors involved will wake up before a network worm outbreak occurs.
Originally, Thomas disclosed the details of his bug on his blog. Later, he removed some details to help protect users. I believe that responsible disclosure is a two-way street that requires responsibility on both sides. Since Google, OEMs, and carriers all continue to act irresponsibly, it is necessary bring more attention to this issue and the situation as a whole.
I spent a little time and managed to recreate the issue with nothing more than HTML and JavaScript. As of today, I have released a Metasploit module to take advantage of the flaw. It is available in the latest copy of our Framework product, or you can view the source via the link to our Redmine project tracker above.
Before I go deeper into the consequence of this bug, I want to point out that Thomas outlined several workarounds for this vulnerability in his blog.
Now, take a deep breath give some thanks to the fact that, under Android, most every process runs under a separate, confined, unix-style user account. This design feature partially mitigates this issue, lowering confidentiality impact to “Partial” and bringing the CVSS score from 5 to 3.5. That said, an attacker can still gain access to some pretty interesting stuff.
For starters, an attacker can steal any world-readable file. In my tests it was possible to get potentially sensitive information from the within the “proc” file system. This type of information could include kernel versions, addresses, or configuration that can be used enhance further attacks.
Also, you can snarf any files that are used by the browser itself. This includes bookmarks, history, and likely more. This kind of information could potentially be embarrassing or possibly even give an attacker access to any saved passwords or session cookies you might have stored.
Perhaps the easiest win though, is that you can grab anything off of the SD card. You might ask, “Anything?! What about the user separation?” Well, because the SD card has been formatted with the “vfat” (aka “fat32”) file system, there is no concept of ownership. All files are owned by the same user id since the file system itself cannot encapsulate who created which file. As Thomas said, files in the SD card that have predictable names are ripe for the picking. This includes pictures and movies. These may in fact be some of the most private data on your device.
In conclusion, I hope that the Android security debacle will get resolved as soon as possible. If Google, OEMs, and carriers can’t work it out, perhaps another party will step in to maintain the operating system. I believe this could be very similar to the way various Linux distributions operate today. If the situation is not resolved, I fear the Android device pool could become a seething cesspool of malicious code..."
Here is the address
http://blog.metasploit.com/2011/01/mobile-device-security-and-android-file.html
Sent from my PC36100 using XDA App
Shocking. Thanks for the info.
Nice find. You are right that oems and manufactures need to stay on top to mantain security. Hopefully meaningful post like this will make users aware of the possible dangers of the internet, data, and phone usage
Sent from my ADR6300 using Tapatalk
Ouch. Wish Android updates were like iOS..
Android is open, one of the main assumptions is that there is no single company, which controls it. I could create my own phone with Android, sell it to people and give them no support at all - Google can't do anything about it.
There is only one solution to this problem: people have to choose their phones wisely. People look at phone specs, at CPU, RAM, camera, but they ignore future support and openess. Recently Motorola has stated they will lock bootloaders in their future phones. People will go for these phones anyway and then they will complain they can't do anything with some horrible bugs, they will complain about Android and Google, but they should complain about Motorola and themselves. While Nexus S owners will have same bugs fixed by both Google and community.
Choose your phones wisely.
SD with vfat...good catch. Horrible bug while many users trying to move their apps to SD. And maybe 80-90% of the apps in the market require modify SD card perm? Horrible. Verizon SGS is screwed since that phone have little internal and lots of external SD.
I'm so glad you guys came across this thread, and it didn't get lost in all the other threads. I hope some of the devs see it. Can a fix be implemented at the Rom or kernal level?
Sent from my PC36100 using XDA App
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.
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
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...
RAMpage – A Vulnerability Affecting Every Android Device Built Since 2012
We already know about the infamous Rowhammer vulnerability in DRAM (dynamic random access memory). Now, researchers have discovered another hardware vulnerability working similarly. The newly identified RAMpage vulnerability could allow hackers to take complete control of your smartphones. Posing a threat to all Android devices for the past six years.
RAMpage Vulnerability – A Rowhammer Variant
A team of eight researchers have discovered a hardware flaw that puts all Android devices at the risk of hacking. The team calls it RAMpage as it exploits memory pages in RAM. RAMpage primarily makes Android phones vulnerable to hacking attacks as it provides apps unauthorized access to the device.
Researchers have published a research paper (https://vvdveen.com/publications/dimva2018.pdf) in which they have explained about the flaw, and have proposed a solution too. The paper is available online in a separate link. one statement from it states:
“While apps are typically not permitted to read data from other apps, a malicious program can craft a rampage exploit to get administrative control and get hold of secrets stored in the device.”
This vulnerability could leak almost all of your personal data to hackers. This includes everything from saved passwords and emails to messages, business documents, and photos.
Though RAMpage mainly targets Android phones and tablets, the iOS-based gadgets do not remain significantly safe from this flaw.
The Threat Has Been Around Since 2012
The researchers clearly stated that the RAMpage has been around for the past six years. According to them, all android devices with vulnerable memory.
“More technically, every mobile device that is shipped with LPDDR2, LPDDR3, or LPDDR4 memory is potentially affected, which is effectively every mobile phone since 2012.”
Regretfully, no patch is yet available for RAMpage vulnerability. Moreover, one cannot precisely state desktops to be safe from it.
Google has recognized this flaw (CVE-2018-9442). Yet, they do not presently recognize it to be as important as the researchers believe it is.
“We’ve worked closely with the research team and thought this vulnerability isn’t a practical concern for the overwhelming majority of users.”
Google also claims that present Android devices are already safe from this flaw.
“While we recognize the theoretical proof of concept from the researchers, we also recognize that newer devices contain memory with Rowhammer specific protections (for example the researcher proof of concept for this issue does not work on any currently supported Google Android devices).”
As a conclusion, is this a method to get the much desired root in devices with boot loader blocked?
Credits: https://latesthackingnews.com
The first question which comes to mind is: Is acceptable having to rely on exploits to be able to administrate expensive devices for which we paid hundreds of dollars/euros/whatever?
I think it is plainly wrong. The community should stand up and demand vendors to stop closing our devices as they currently do.
Criminals always find ways (they dedicate their time to it), reducing administrative rights affect enthusiasts and even common users instead, crippling our experiences. At the end, our rights are at stake...
There is an app at http://rampageattack.com you could install and run to test your device for the vulnerability.