Related
Researchers at Bluebox Security have revealed a disturbing flaw in Android's security model, which the group claims may affect up to 99 percent of Android devices in existence. According to Bluebox, this vulnerability has existed since Android 1.6 (Donut), which gives malicious app developers the ability to modify the code of a legitimate APK, all without breaking its cryptographic signature -- thereby allowing the installation to go unnoticed. To pull off the exploit, a rotten app developer would first need to trick an unknowing user into installing the malicious update, but hackers could theoretically gain full control of a user's phone if the "update" posed as a system file from the manufacturer.
Bluebox claims that it notified Google of the exploit in February. According to CIO, Bluebox CTO Jeff Forristal has named the Galaxy S 4 as the only device that's currently immune to the exploit -- which suggests that a security patch may already exist. Forristal further claims that Google is working on an update for its Nexus devices. In response to our inquiry, Google told us that it currently has no comment. We certainly hope that device manufacturers do the responsible thing and distribute timely security patches to resolve this issue. Absent that, you can protect yourself by installing updates through the Play Store and Android's built-in system update utility.
Source:
http://www.engadget.com/2013/07/04/bluebox-reveals-android-security-vulnerability/
They ust read this here and on an Australian news website, news.com.au, they recommend;
So what can I do about this?
- Do not allow apps from unkown sources. To do this go to Settings, Security and untick "allow unknown sources".
- Well, the news isn't good. Until further notice, news.com.au recommends that you don't download any non-Google apps.
- Bluebox has recommended that users update their operating system to the latest version.
- Also, if you have any apps which store your personal information such as credit card or PayPal information (like eBay, Amazon or Etsy), you should remove this information immediately.
- Remove any personal information from your phone (do you have your credit card pin stored in your notes? Get rid of it)
Crap advice for majority of users I feel.
Most users will have 'unknown sources' off by default but they advise not download any non Google app even from the play market as mentioned elsewhere in article.
They say to update your phone, how easy is that to do when carriers and manufacturers don't release up to date firmware for phones..
That is fine for people like us that flash new Roms all the time but for normal folk it's not a viable solution.
I don't really think the threat is so great, going by those that report such though we all had better stop using android..
I am more concerned with apps using other apps permissions/data flaw
and google play update/install protocall being not encrypted/catchable and falsifyable.
Regarding what is stated in article, this was known almost day 1 which is why from beginning android said dont install non market stuff. And it has also been known crapware has entered market.
So all in all, its an obvious article.
Sent from my GT-N7000 using Tapatalk 2
I totally agree baz77, this has been know for a very long time now. There are also quite a few apps in Play that are "crapware".
The issue has been fixed on Google's side and CyanogenMod (08/07 nightly and yesterday's security release CM10.1.1.)
Now, it is up to the OEMs to follow
I guess I got it wrong, it is a separate issue, glad the pros getting it fixed, they need to be applauded! Salute!
Sent from my GT-N7000 using Tapatalk 2
Vulnerability Allows Attackers to Modify Android Apps Without Breaking Their Signatures
This might be the reason why the new MF2 and ME6 are not downgradable and why the 4.2.2 update was delayed.
Source->http://www.cio.com/article/735878/V...ndroid_Apps_Without_Breaking_Their_Signatures
IDG News Service — A vulnerability that has existed in Android for the past four years can allow hackers to modify any legitimate and digitally signed application in order to transform it into a Trojan program that can be used to steal data or take control of the OS.
Researchers from San Francisco mobile security startup firm Bluebox Security found the flaw and plan to present it in greater detail at the Black Hat USA security conference in Las Vegas later this month.
The vulnerability stems from discrepancies in how Android apps are cryptographically verified, allowing an attacker to modify application packages (APKs) without breaking their cryptographic signatures.
When an application is installed and a sandbox is created for it, Android records the application's digital signature, said Bluebox Chief Technology Officer Jeff Forristal. All subsequent updates for that application need to match its signature in order to verify that they came from the same author, he said.
This is important for the Android security model because it ensures that sensitive data stored by one application in its sandbox can only be accessed by new versions of that application that are signed with the original author's key.
The vulnerability identified by the Bluebox researchers effectively allows attackers to add malicious code to already signed APKs without breaking their signatures.
The vulnerability has existed since at least Android 1.6, code named Donut, which means that it potentially affects any Android device released during the last four years, the Bluebox researchers said Wednesday in a blog post.
"Depending on the type of application, a hacker can exploit the vulnerability for anything from data theft to creation of a mobile botnet," they said.
The vulnerability can also be exploited to gain full system access if the attacker modifies and distributes an app originally developed by the device manufacturer that's signed with the platform key -- the key that manufacturers use to sign the device firmware.
"You can update system components if the update has the same signature as the platform," Forristal said. The malicious code would then gain access to everything -- all applications, data, accounts, passwords and networks. It would basically control the whole device, he said.
Attackers can use a variety of methods to distribute such Trojan apps, including sending them via email, uploading them to a third-party app store, hosting them on any website, copying them to the targeted devices via USB and more.
Some of these methods, especially the one involving third-party app stores, are already being used to distribute Android malware.
Using Google Play to distribute apps that have been modified to exploit this flaw is not possible because Google updated the app store's application entry process in order to block apps that contain this problem, Forristal said. The information received by Bluebox from Google also suggests that no existing apps from the app store have this problem, he said.
However, if an attacker tricks a user to manually install a malicious update for an app originally installed through Google Play, the app will be replaced and the new version will no longer interact with the app store. That's the case for all applications or new versions of applications, malicious or non-malicious, that are not installed through Google Play, Forristal said.
Google was notified of the vulnerability in February and the company shared the information with their partners, including the members of the Open Handset Alliance, at the beginning of March, Forristal said. It is now up to those partners to decide what their update release plans will be, he said.
Forristal confirmed that one third party device, the Samsung Galaxy S4, already has the fix, which indicates that some device manufacturers have already started releasing patches. Google has not released patches for its Nexus devices yet, but the company is working on them, he said.
Google declined to comment on the matter and the Open Handset Alliance did not respond to a request for comment.
The availability of firmware updates for this issue will differ across device models, manufacturers and mobile carriers.
Whether a combination of device manufacturers and carriers, which play an important role in the distribution of updates, coincide to believe that there is justification for a firmware update is extremely variable and depends on their business needs, Forristal said. "Ideally it would be great if everyone, everywhere, would release an update for a security problem, but the practical reality is that it doesn't quite work that way, he said."
The slow distribution of patches in the Android ecosystem has long been criticized by both security researchers and Android users. Mobile security firm Duo Security estimated last September, based on statistics gathered through its X-Ray Android vulnerability assessment app, that more than half of Android devices are vulnerable to at least one of the known Android security flaws.
Judging by Android's patch distribution history so far, the vulnerability found by the Bluebox researchers will probably linger on many devices for a long time, especially since it likely affects a lot of models that have reached end-of-life and are no longer supported.
Click to expand...
Click to collapse
I really thought more people would be interested in knowing this. I would really like to know what you guys think about this.
Key phrase here is "for apps not installed through the google store". Hence not an issue for a large fraction of users. Total case of FUD. Someone must be wanting to sell some av software.
Sent from my GT-N7100 using Tapatalk 4 Beta
Kremata said:
I really thought more people would be interested in knowing this. I would really like to know what you guys think about this.
Click to expand...
Click to collapse
Well, X-Ray scanner either does not detect this latest security flaw or N7100 (as of DM6) is allready patched.
Kremata said:
I really thought more people would be interested in knowing this. I would really like to know what you guys think about this.
Click to expand...
Click to collapse
This is the first link I found for XDA on this.
I think it's not that interesting because it's old, old news and exactly why it's being touted as a "new" discovery is beyond me, it's far from new.
We here at XDA have been using this method for years to modify stock Android and OEM system apps with great success. Here's an example by me from 2011: http://forum.xda-developers.com/showthread.php?t=994544 there's a literally hundreds of examples all over XDA.
The real question here is how Bluebox security got everybody to act as a PR machine for them. If they turn up at Black Hat with this "amazing discovery" they're going to get laughed off the stage.
djmcnz said:
This is the first link I found for XDA on this.
I think it's not that interesting because it's old, old news and exactly why it's being touted as a "new" discovery is beyond me, it's far from new.
We here at XDA have been using this method for years to modify stock Android and OEM system apps with great success. Here's an example by me from 2011: http://forum.xda-developers.com/showthread.php?t=994544 there's a literry hundreds of examples all over XDA.
The real question here is how Bluebox security got everybody to act as a PR machine for them. If they turn up at Black Hat with this "amazing discovery" they're going to get laughed off the stage.
Click to expand...
Click to collapse
Ahh! Thats the answer I was waiting for (and from a Recognized Developer). I knew XDA Devs were using this method. My new question is.. If they fix it will it be harder to create Mods? Will it slow down development?
Shouldn't this be posted in the generals forum?
Kremata said:
If they fix it will it be harder to create Mods? Will it slow down development?
Click to expand...
Click to collapse
I suspect so. If they fix it properly it would become impossible to change any aspect of the app without signing it again. If you wanted to maintain compatibility with the original then you'd need the developer's keys.
At the moment really only the manifest and some metadata within the apk is signed, if they extended that to the entire contents of the apk many mods (think themes for stock Google apps etc) are screwed unless users are happy to relinquish Play Store links and updates (i.e. backward compatibility).
Google may not go this far and may only choose to authenticate the code (smali) rather than all of the apk contents (graphics, strings etc), this approach would leave room for some mods to survive. Remains to be seen.
It looks like Marshmallow is following the usual pattern of Android "x.0" alpha release to the public, followed by "x.0.1" beta release with initial defect ('bug") corrections starting with Nexus beta testers (I.e. Nexus users in general).
Reading about the MM 6.0 problems on MXPE, I'm sitting out the 6.0 alpha testing on the sideline with LP 5.1.1. Most trouble-free phone I've had yet, and I don't yet need the only compelling feature I see with MM on the MXPE (T-Mobile Band 12 support).
Any noises yet about MM beyond 6.0.1? (I know I can look for this elsewhere too, but thinking maybe some of the XDA community may have inside info from the Android community.)
TIA...
The marshmallow update give me some new features and better battery life (though I do own the X Style, not pure). Unless you are dead set on being intentionally obtuse, then this isn't considered an alpha update.
Also the 6.0.1 update is quite minor, the largest change being some ART performance improvements, the rest is adding bands to the Nexus line and some emoji's: http://www.androidheadlines.com/2015/12/google-posts-android-6-0-1-changelog.html
I know the label "alpha" is not not the official label for something like 6.0. But with so many substantial defects, and multiple forthcoming revisions to correct those defects a certainty, that's really what it is IMO. Maybe "public release alpha" would be a better description, since pre-release revisions go through even more defect-ridden levels including pre-release alpha, prior to public release.
Similar situation with previous Android versions, and in fact most software foisted on the public these days (I'm looking at you, Microsoft and Apple). Look at Lollipop and the multiple public release revisions it took to iron out most of the substantial defects, finally, with 5.1.1.
6.0.1 is not just "...some ART performance improvements, the rest is adding bands to the Nexus line and some emoji's...", it also includes defect corrections. (Bluetooth, anyone?) And if the changelog doesn't list a significant number of defect corrections, that doesn't necessarily mean it is already polished at 6.0.1. The fragmented Android ecosystem and separation between Google, phone manufacturers, carriers, and users guarantees a plethora of various non-trivial defects in the ecosystem, many of which Google will address only slowly or even never for most phones.
For example, the memory leak defect in LP was not fixed until 5.1.1. How may revisions and months did that take? How many phones still run pre-5.5.1 with this defect?
One reason I bought the MXPE was the idea that it would be one of the first to get the updates. That turned out to be overly optimistic. It looks like Nexus is the only one still close enough to the source to get timely updates, and it also looks like Google is not pursuing Android defect corrections with any kind of urgency at all nowadays, maybe because the hardware ecosystem is becoming way too diverse to adequately support any more (or maybe because the profits roll in no matter what). Motorola phones, with the Moto alterations to Android, outsider status with carriers, and now hollowed-out Motorola support, appear to be no closer to adequate Android support from Google than any other non-Nexus phone.
"Obtuse"? A "bug" is a euphemism for a defect. Let's stop being obtuse, and call it what it is.
Any other info also appreciated.
You're being obtuse by insisting that we're all public alpha testers.
You obviously have no idea about software development, nor about Android Open Source development. Not your fault, but running your mouth is.
You bemoan the memory leak fix took several revisions to fix. So, you think that Google dedicated the whole team to fixing that one bug? What then? No other bugfixes or features are introduced in the meantime? The likely case is (and this is from experience) that bug took some revisions to fix, in the meantime, Google were also pushing ahead with other fixes. Regardless to what the uneducated (about SW development), throwing 15 developers onto one problem doesn't solve it any quicker. 5.0.1 came, adn 5.0.2 came, then 5.1 came in the meantime. While that memory leak was being worked on, more releases come fixing other things. Be grateful they didn't listen to you and leave it at 5.0 for several months while they fixed one issue.
Whatever bluetooth fixes that you think are in 6.0.1 are pure fantasy, because none exist in AOSP 6.0.1: http://aosp.changelog.to/android-6.0.0_r5-to-android-6.0.1_r1.html <-- That's the FULL changelog of commits between 6.0.0_r5 and 6.0.1_r1.
It is not Google's job to fix a problem in anything other than their own devices. At all. Google's job is to make AOSP run smoothly on Nexus devices and release the source. Samsung, HTC, LG, Motorola et al all take the source code, just like CM, AICP, Slim and the rest do, and make modifications for their devices, using the sources given to them by their hardware partners and themselves. So if BT works in Nexus devices, but not others, then it's not Google's problem (usually). An AOSP issue will persist several devices, including Nexii devices.
Google also have taken on the quite large undertaking of monthly security updates for their devices, which I can tell you will be taking up some of the development teams time (it's what, 3-4 months into that project?).
No software ever released on this planet comes without bugs and issues. This is software development. You can check the status of AOSP development here: https://android-review.googlesource.com/#/q/status:open and feel free to download, code and submit your own features.
MattBooth said:
You're being obtuse by insisting that we're all public alpha testers.
You obviously have no idea about software development, nor about Android Open Source development. Not your fault, but running your mouth is.
You bemoan the memory leak fix took several revisions to fix. So, you think that Google dedicated the whole team to fixing that one bug? What then? No other bugfixes or features are introduced in the meantime? The likely case is (and this is from experience) that bug took some revisions to fix, in the meantime, Google were also pushing ahead with other fixes. Regardless to what the uneducated (about SW development), throwing 15 developers onto one problem doesn't solve it any quicker. 5.0.1 came, adn 5.0.2 came, then 5.1 came in the meantime. While that memory leak was being worked on, more releases come fixing other things. Be grateful they didn't listen to you and leave it at 5.0 for several months while they fixed one issue.
Whatever bluetooth fixes that you think are in 6.0.1 are pure fantasy, because none exist in AOSP 6.0.1: http://aosp.changelog.to/android-6.0.0_r5-to-android-6.0.1_r1.html <-- That's the FULL changelog of commits between 6.0.0_r5 and 6.0.1_r1.
It is not Google's job to fix a problem in anything other than their own devices. At all. Google's job is to make AOSP run smoothly on Nexus devices and release the source. Samsung, HTC, LG, Motorola et al all take the source code, just like CM, AICP, Slim and the rest do, and make modifications for their devices, using the sources given to them by their hardware partners and themselves. So if BT works in Nexus devices, but not others, then it's not Google's problem (usually). An AOSP issue will persist several devices, including Nexii devices.
Google also have taken on the quite large undertaking of monthly security updates for their devices, which I can tell you will be taking up some of the development teams time (it's what, 3-4 months into that project?).
No software ever released on this planet comes without bugs and issues. This is software development. You can check the status of AOSP development here: https://android-review.googlesource.com/#/q/status:open and feel free to download, code and submit your own features.
Click to expand...
Click to collapse
t
No new or useful information there. Thanks anyway, despite the ad hominem. I guess that comes with the territory (forums).
Yep, the Google-Android-(independent hardware makers) ecosystem is seriously flawed. Too much disconnect between the OS owner (Google), the hardware makers, the carriers, and the customer. And the first three in the chain (not including the customer) have different incentives/disincentives, and there are a bazillion hardware variations, of course it is broken. We know all this.
Reminds me of the original PC/Windows mess. Except worse because the carriers interpose an additional dysfunctional layer hindering OS updates/support. (Before anyone says "just DIY with one of the many available ROMs, I started this "Q" thread about stock MM, not third party ROMs.)
Still hoping for any useful information on anything happening to fix the MM defects, to get an idea when it might be past public beta and worth installing to MXPE.
TIA...
Tinkerer_ said:
t
No new or useful information there. Thanks anyway, despite the ad hominem. I guess that comes with the territory (forums).
Yep, the Google-Android-(independent hardware makers) ecosystem is seriously flawed. Too much disconnect between the OS owner (Google), the hardware makers, the carriers, and the customer. And the first three in the chain (not including the customer) have different incentives/disincentives, and there are a bazillion hardware variations, of course it is broken. We know all this.
Reminds me of the original PC/Windows mess. Except worse because the carriers interpose an additional dysfunctional layer hindering OS updates/support. (Before anyone says "just DIY with one of the many available ROMs, I started this "Q" thread about stock MM, not third party ROMs.)
Still hoping for any useful information on anything happening to fix the MM defects, to get an idea when it might be past public beta and worth installing to MXPE.
TIA...
Click to expand...
Click to collapse
What ad hominem? Your uneducated state affects your ability to understand the nature of Android and software development. It's a perfectly legitimate response to your position. You lack the ability to understand and therefore your argument is flawed. I'm not attacking you, I actually tried to give you some insight into how it works, but you're not really interested and would rather insist on this "public beta" bull.
As far as fixing any "defects" you suppose, you haven't actually listed any so no-one is going to be able to help you with temporary work around without a list of what you feel is broken. I also showed you the changelog, so you can do your own homework to see if your supposed defects are fixed in 6.0.1.
The various hardware configurations doesn't even matter because Android is built to deal with it. So long as the hardware vendors of chips and modules support them properly and give out functioning binaries to OEM's, or proper source code, it's irrelevant. The exact opposite of what you said is true, Google has a very close relationship with it's partners (anyone signed up to their Google programs, to preinstall Google apps). The problem is carriers, who really shouldn't have a say in software on the phones, but that seems to be a chiefly North American problem.
Google doesn't need to have any connection to Android users as customers. Google does not sell Android, therefore you are not Google's customer unless you use a Nexus phone. Google sell the Google Experience, with the Nexus. You are Motorola's customer, and you are using Motorola's branched version of Android. Google doesn't owe Motorola any fixes or patches for their device. Motorola must maintain their own device tree and maintain their own relationships with their partners.
EDIT:
Also, Motorola's problem is resources. They have four version of the Moto X 2015 to deal with, three versions of the Moto X 2014, the new X Force, then the various versions of the G and E to deal with, along with two smart watches, and so forth. Their line up is increasing whist I imagine their development team is not. There was outrage (rightly so) when news broke that the Moto G 2015 wasn't getting the MM update, despite being a couple of months old, and Motorola listened and OTA's are rolling out.
I am asking if anyone can offer any info on anything being done to move toward MM revision with the many significant defects of 6.0 corrected. Read the forums, there are way too many defects with 6.0, it is patently a de facto public alpha, and we are tracking the usual pattern where it takes 3 to 5 revisions before an OS major rev is ironed out enough that upgrading will not cause more problems than it fixes.
There are always excuses made for why there are so many defects in software. There is a euphemism for "defect" everybody uses, "bug". Everyone has been making excuses for so long about shoddy workmanship and inadequate testing and correction of software, with the "bug" euphemism to minimize the reality that these are defects, that we are all just to suppose to accept systems ridden with faults without complaint. It's unacceptable. It can be done better. Part of why it doesn't get better is because everybody says "that's just the way it is, deal with it". With mountains of byzantine excuses and even ad hominem attacks (as here).
This thread was not started to start a tit for tat ad hominem back and forth, nor to post long essays detailing excuses for the pathetic status quo of the fragmented Android ecosystem with respect to defect causes and distributions. It was started looking for any info about work being done to fix the stock MM defects. Still seeking info.
TIA.
You should probably check the definition of ad hominem. There was no attack on you as a person, just pointing out that your uneducated state with regards to knowledge about software development affects your ability to call judgement on this.
But you haven't listened to a single word I've said and still maintain a shoddy position, so I would suggest to anyone else who reads this to simply ignore you as a troll.
Tinkerer_ said:
It looks like Marshmallow is following the usual pattern of Android "x.0" alpha release to the public, followed by "x.0.1" beta release with initial defect ('bug") corrections starting with Nexus beta testers (I.e. Nexus users in general).
Reading about the MM 6.0 problems on MXPE, I'm sitting out the 6.0 alpha testing on the sideline with LP 5.1.1. Most trouble-free phone I've had yet, and I don't yet need the only compelling feature I see with MM on the MXPE (T-Mobile Band 12 support).
Any noises yet about MM beyond 6.0.1? (I know I can look for this elsewhere too, but thinking maybe some of the XDA community may have inside info from the Android community.)
TIA...
Click to expand...
Click to collapse
I think we'll close this debate. There are no real "Android" insiders on XDA, so asking for update info which is privy to Google is perhaps somewhat futile.
On a related note, XDA have a few dedicated "Android Fora", such as this complete Category where non-device specific discussion and indeed conjecture takes place. Perhaps you could take a look there and see what transpires?
Thanks
I hear Verizon and Google have released a ota of the Sept security patch for Verizon's pixels yesterday.. if you have a Verizon be sure to check for update manually in settings, about phone, software update..
I saw it on my Pixel XL this morning but not on my wife's Pixel. I have no details except the size of ~55MB since that is all that shows. It is not available for download in the OTA images or the factory images section. I assume it will not work over the standard OTA mechanism since the phones are rooted, and I have no interest in taking the patch blindly anyways.
The september 2017 Security Patch should have been released already. But due to some reasons, Google has delayed the upcoming monthly security update. The reason for the delay could be the release of a new stable Android 8.0.0 Oreo firmware update for Google Pixel and Nexus phone. Under the AOSP project, Google released 3 sets of monthly updates. One for the latest Android 8.0 Oreo, another for 7.1 Nougat, and finally the Marshmallow. Today, the Google Pixel XL device is receiving the September 2017 security patch OTA.
The first Google devices to receive the September 2017 Security Patch are the Unlocked Pixel XL 128 GB on AT&T and Verizon. That means, the US carriers shall receive the OTA update before the global roll out. The international variant of Pixel, Pixel XL, Nexus 6P, and Nexus 5X may receive the next security patch as soon as today. So stay tuned as we will list the update here.
The OTA update for AT&T Pixel XL brings the firmware build number OPR3.170623.007 dated September 5th 2017 level based on Android 8.0.0 Oreo. This an upgrade over the previous OPR6.170623.012 August 5th 2017 8.0.0 Patch.
This September OTA update comes in a very small OTA package. It weight about 50.61 MB in size. The changelog states the following.
This update fixes critical bugs and improves the performance and stability of your Pixel XL. If you download updates over the cellular network or while roaming, additional charges may apply. Update size 50.6 MB
Note: Google Pixel XL users have reported that the OTA notification shows that it is based on Android 7.1.2 Nougat, whereas the Pixel devices are already running 8.0.0 Oreo. However, upon update, the Android version is based on 8.0.0 Oreo and September 2017 security patch level. So it could be an error from Google’s side.
Download Google Pixel (XL) September 2017 Security Patch OTA update
One of the users for Google Pixel XL have managed to capture the latest OTA update from the LogCat file. September 2017 security patch.
AT&T Google Pixel XL 128 GB | OTA Download | google_marlin_marlin
Verizon carrier Pixel XL | OTA download |
8.0.0/OPR3.170623.007 from 8.0.0/OPR6.170623.012
Android 8.0 – Oreo for Pixel XL
Official factory images
Official full OTA images
Build for Global, Bell, Telus, Telstra, TMoUS, Sprint, USCC, Rogers/Fido
Android 8.0 – Oreo for Pixel
Official factory images
Official full OTA images
Build for Global, Bell, Telus, Telstra, TMoUS, Sprint, USCC, Rogers/Fido
Soon the official factory images for September 2017 Security Patch will show up. Also, download OTA update image from above and install it via ADB sideload method.
What's in the security patch
There are 30 issues resolved in the security patch dated 2017-09-01 and 51 in the 2017-09-05 one. Google notes that the two security patch level strings provide “Android partners with the flexibility to more quickly fix a subset of vulnerabilities that are similar across all Android devices.”
Google devices will receive the latter patch, while devices from other manufacturers will also feature OEM-specific fixes. This month’s bulletin also includes a new section that lists patches that are specific to Google devices.
Vulnerabilities range from moderate to critical, with the most severe possibly enabling remote code execution when browsing, using email, or MMS. However, Google notes that there are no reports of customers being affected by these security issues.
Still not interested? Some people are willing to give up root for a little while in order to improve their security... Only someone who thinks having root 24/7 is better than improving security is something different.. I know with this patch it stops people from remotely controlling you're device... I think if I was rooted I'd unroot and add this security protection...
Pixelxluser said:
Still not interested? Some people are willing to give up root for a little while in order to improve their security... Only someone who thinks having root 24/7 is better than improving security is something different.. I know with this patch it stops people from remotely controlling you're device... I think if I was rooted I'd unroot and add this security protection...
Click to expand...
Click to collapse
If someone is rooting, why not apply the update and reroot. We all do that every month. I just did mine for this update. I get the loss of security if you root but you dont need to give up root to update.
Pixelxluser said:
The first Google devices to receive the September 2017 Security Patch are the Unlocked Pixel XL 128 GB on AT&T and Verizon. That means, the US carriers shall receive the OTA update before the global roll out.
The OTA update for AT&T Pixel XL brings the firmware build number OPR3.170623.007 dated September 5th 2017 level based on Android 8.0.0 Oreo. This an upgrade over the previous OPR6.170623.012 August 5th 2017 8.0.0 Patch.
AT&T Google Pixel XL 128 GB | OTA Download | google_marlin_marlin
Click to expand...
Click to collapse
I would like to know where you copied & pasted this info since at&t does not sell the pixel, so, I can't see them releasing a ota.
Last I knew, google controls this
Sent from my Pixel using XDA-Developers Legacy app
I was rooted on Oreo and updated to this new build and my service still sucks? I'm right next to a cell tower and my phone is going from -64 to -80dbm and its making my battery tank. I'm about to go back to 7.1.2.
I think a big misconception is trying to pull people away from improving their own security and safety by using the whole oh you will lose root if you do that and may lock you're bootloader.. just because you personally don't care about you're own safety doesn't mean you should try to prevent someone else from improving their own safety.. come on the fact is it's just root you will be fine to live without it for a little while it's not going to hurt you to give it up for a few...
And another thing is all the new pixels and Pixel XL are gonna come preinstalled with these new security patchs so you all might as well get used to it...
I don't understand why Google doesn't post these on their website immediately. I have a Pixel on Verizon and have no way of accessing it until they finally publish the update to their site or zi just start receiving it. It's always this awkward way with a lot if confusion. It would also be nice if they fixed the few small bugs in Oreo (i.e. picture in picture mode causing reboots when you turn the screen off/back on). It's just a little annoying.
The Sept security patch also fixes a Bluetooth problem. It's recommend to update to any software with Sept security patch and later security patch
Google is still working on getting the September security patches out the door, but it has posted a security bulletin detailing the changes. Several of the flaws noted in the bulletin are part of an enormous Bluetooth vulnerability discovered by Armis Labs, which bills itself as an IoT security firm. The "BlueBorne" attack exposes billions of Android devices to complete takeover by hackers, but it's not only Android. The same flaw exists in Windows, Linux, and some versions of iOS.
BlueBorne is dangerous because most devices have Bluetooth active even when it's not actively being used, and an attacker does not need to pair with the target device to completely take it over. There are eight vulnerabilities listed by Armis, four of which are critical (though Google's classifications differ). The most severe issues are the two remote code executions, which allow an attacker to completely own a device without the user even knowing. These flaws are present in the Bluetooth Network Encapsulation Protocol (BNEP) service, which is used for internet sharing and networking.
You don't even need an internet connection to infect a device, and the Android demo above is wild. If one of the affected devices has Bluetooth on, it's a target. The attacker can gain complete control of the phone to launch any app, install malware, and exfiltrate data. Armis estimates that about 8 billion devices are vulnerable, including 2 billion Android phones, tablets, set top boxes, and watches. There are another 2 billion Windows devices and around 1 billion iOS phones and tablets affected. BlueBorne doesn't work on iOS 10, so the damage is mitigated there.
BlueBorne vulnerabilities in the security bulletin
Most of the vulnerabilities in Android reported by Armis affect all recent builds of the OS, so Google is adding a lot of patches to AOSP. It's up to OEMs to push those out to devices, though. Anything with a patch level of September 1st, 2017 or later will have the necessary fixes. It's going to take time for this patch to roll out, and in the meantime, there are a lot of vulnerable devices.
This was took from Android polices website
It's also recommend that the devs here on xda get rid of the software which is vuneralable to theses problems.. it doesn't really show good faith of a Dev if they know there's security problems in the roms but yet keep them posted for someone to download and install...
Pixelxluser said:
It's also recommend that the devs here on xda get rid of the software which is vuneralable to theses problems.. it doesn't really show good faith of a Dev if they know there's security problems in the roms but yet keep them posted for someone to download and install...
Click to expand...
Click to collapse
Boring.......
Pixelxluser said:
It's also recommend that the devs here on xda get rid of the software which is vuneralable to theses problems.. it doesn't really show good faith of a Dev if they know there's security problems in the roms but yet keep them posted for someone to download and install...
Click to expand...
Click to collapse
Do you even know what the ... ah not worth it
Sent from my Pixel using XDA-Developers Legacy app
In recent news, a new vulnerability came to light that affects Wifi on OS's like Windows, Linux, and more specifically: Android 6.0 and higher
https://www.krackattacks.com/
Just wanted to put it out, because this could most likely also affect our devices.
It seems like there are already patches/software updates rolling out.
What are your thoughts?
(Might be in the wrong place, feel free to move this post)
The official ROM still runs September 1st 2016 security patch, I doubt we will ever see the november 2017 patch that will fix this