Android bug: MMS attack affects 'one billion' phones - http://www.bbc.co.uk/news/technology-33689399
Can the patch be manually downloaded from somewhere and manually installed in rooted phones? Where?
Prefer to not go the OTA route because I am rooted and use xposed framework.
Is the patch issued out and available by Google yet?
Running Cataclysm, but don't see an update for it yet for the MMS bug.
Patched stagefright libraries for AOSP 5.1.1
For those who are interested: I patched AOSP 5.1.1 (LMY48B) with the code changes that were submitted to CM by the researcher who detected the flaw, see e.g. here. The attached archive contains the 17 (!) modified libraries. I just pushed the files to my device running stock 5.1.1 and it boots fine. I do not not have any information on whether the patch actually does what it is supposed to do or whether the new libs result in breakage somewhere else.
Update: added three additional patches to libstagefright submitted to CM by the same security researcher (jduck) as detailed here.
Update (August 14): added latest stagefright vulnerability patch as described here
From what I have read this should not really affect our devices. It is more older devices that have issues.
wangdaning said:
From what I have read this should not really affect our devices. It is more older devices that have issues.
Click to expand...
Click to collapse
Well, from what I've read/seen it appears that the Nexus 5 on 5.1.1 is fully exploitable. However, sandboxing and "address space layout randomization" make it a lot more difficult to actually achieve anything with the exploit, but the probability is not zero. We will probably know more after the hacker conference next week.
Note that I have updated the patched libraries that I attached to my previous post. In the update I added three additional patches to libstagefright that have been submitted to CM by the security researcher who has found the exploit back in April, see here
chdloc said:
For those who are interested: I patched AOSP 5.1.1 (LMY48B) with the code changes that were submitted to CM by the researcher who detected the flaw, see e.g. here. The attached archive contains the 17 (!) modified libraries. I just pushed the files to my device running stock 5.1.1 and it boots fine. I do not not have any information on whether the patch actually does what it is supposed to do or whether the new libs result in breakage somewhere else.
Edit: added three additional patches to libstagefright submitted to CM by the same security researcher (jduck) as detailed here.
Click to expand...
Click to collapse
Added the patched libs and my phone didn't blow up so that's a good sign. Too bad there isn't a good way to test it.
chdloc said:
Well, from what I've read/seen it appears that the Nexus 5 on 5.1.1 is fully exploitable. However, sandboxing and "address space layout randomization" make it a lot more difficult to actually achieve anything with the exploit, but the probability is not zero. here
Click to expand...
Click to collapse
Is the rooted nexus 5 on 4.4.4 (with xposed) any safer?
How to sandbox? Is there an app for that?
Thanks.
Anderson2 said:
Is the rooted nexus 5 on 4.4.4 (with xposed) any safer?
Click to expand...
Click to collapse
A rooted device is less secure than a non-rooted device. A device with Xposed is theoretically less secure than that.
Anderson2 said:
How to sandbox? Is there an app for that?
Click to expand...
Click to collapse
Application sandboxing is done by default in Android.
chdloc said:
For those who are interested: I patched AOSP 5.1.1 (LMY48B) with the code changes that were submitted to CM by the researcher who detected the flaw, see e.g. here. The attached archive contains the 17 (!) modified libraries. I just pushed the files to my device running stock 5.1.1 and it boots fine. I do not not have any information on whether the patch actually does what it is supposed to do or whether the new libs result in breakage somewhere else.
Update: added three additional patches to libstagefright submitted to CM by the same security researcher (jduck) as detailed here.
Click to expand...
Click to collapse
Just an fyi; if you're waiting for your rom to be updated, swapping in these patched libs will close the hole (at least according to zImperium's Stagefright check app).
FYI, added latest stagefright vulnerability patch as described here to post #3.
As before, you need to push the libraries manually to /system/lib/, followed by an adjustment of permissions (644), if required.
The latest Zimperium Stagefright Detector app, updated today, returns "not vulnerable" to the (as of today) seven known security vulnerabilities of stagefright.
chdloc said:
FYI, added latest stagefright vulnerability patch as described here to post #3.
As before, you need to push the libraries manually to /system/lib/, followed by an adjustment of permissions (644), if required.
The latest Zimperium Stagefright Detector app, updated today, returns "not vulnerable" to the (as of today) seven known security vulnerabilities of stagefright.
Click to expand...
Click to collapse
Works like a charm... until the next hole is discovered.
chdloc said:
I just pushed the files to my device running stock 5.1.1 and it boots fine. I do not not have any information on whether the patch actually does what it is supposed to do or whether the new libs result in breakage somewhere else.
Click to expand...
Click to collapse
Thanks so much for doing this! I've unzipped these to Dirty Unicorns OFFICIAL-v9.5 (5.1.1) and things appear to be booting/running OK. Zimperium detector also says everything is now good.
I am on rooted nexus 5, version 5.1.1
By manually pushing it do you mean through custom recovery or for example by using flashify app to flash the file, or directly copy pasting it?
And by adjusting permission if required, can you explain how that is done?
Thank you
+1
Are they the same patches for 4.4.4?
persianrisk said:
I am on rooted nexus 5, version 5.1.1
By manually pushing it do you mean through custom recovery or for example by using flashify app to flash the file, or directly copy pasting it?
And by adjusting permission if required, can you explain how that is done?
Thank you
Click to expand...
Click to collapse
To be safe, backup your device before proceeding.
By "pushing files to phone" I mean unpack the archive attached to the third post in this thread and manually copy the resulting files to your device by either using
adb push [...]
or (assuming you use Windows on your host machine)
Explorer
to copy all files to the "sdcard" on your phone.
Then use a file explorer on your phone, such as Root Explorer, to copy the files into place, i.e. /system/lib/
To adjust permissions, again, use the file explorer on your device to verify the "permissions" property of each of the new files. If you don't see rw-r--r, or 644, adjust the permissions appropriately.
Anderson2 said:
+1
Are they the same patches for 4.4.4?
Click to expand...
Click to collapse
No, the patched files posted in the third post of this thread were built on Android (AOSP) 5.1.1. They will not work on KitKat.
Are there similar patched files for 4.4.4?
Anderson2 said:
Are there similar patched files for 4.4.4?
Click to expand...
Click to collapse
Unless patches are forthcoming from Google, I don't think there will be. KK development is essentially dead.
Thank you very much. I followed your steps (used Root Explorer as ES File Manager did not work).
When I run Stage fright detector App by Zimperium INC. and the one by Michael Kohl it says that I am not vulnerable.
But, when I run the one by LookOut Security says I am vulnerable. Any thoughts?
OK, I guess I will move to 5.1.1. May sound easy to pros like you but it's a scary step to users like me. ?
Related
Inspired by SimpleSU (I really love it), which is not so simple to use after all (mainly because it is intended for shipping in the ramdisk or the likes), and closed source, I made my own superuser implementation, µSuper.
I provide it to you, mainly so you can give me some feed back or just try it, whatever you prefer.
Just like SimpleSU it uses a text file.
Unlike SimpleSU this text file contains the UIDs of the apps, not their package names (which makes µSU less vulnerable to frauds). It is also not on the hard to access /system partition, but in the private data directory of µSU, and globally set to read-only.
With only 309 SLOC (app and binary combined) I think it is safe to say that it is really tiny.
The source code is publicly available on Github.
@MarcoToo I know this has been here for ages but I'm amazed this thread has less than 600 views and You've only got 3 thanks... It's my favourite SuperUser app as it uses next to no resources. The only thing wrong is that it won't work with anything above JellyBean 4.2.2 which is a shame; I don't supposed you plan to support further Android versions? or is it easy for me to build this to support further versions?
Thanks anyway, all the people not using this are missing out
HTCDreamOn said:
@MarcoToo I know this has been here for ages but I'm amazed this thread has less than 600 views and You've only got 3 thanks... It's my favourite SuperUser app as it uses next to no resources. The only thing wrong is that it won't work with anything above JellyBean 4.2.2 which is a shame; I don't supposed you plan to support further Android versions? or is it easy for me to build this to support further versions?
Thanks anyway, all the people not using this are missing out
Click to expand...
Click to collapse
theres a reason to it, because the developer hasn't kept the app updated, while supersu is updated almost weekly. The lastest SuperSU has way more support as to this because it is outdated, and in beta at that. Safer and more compatible alternative would be SuperSU
Aiko0923 said:
theres a reason to it, because the developer hasn't kept the app updated, while supersu is updated almost weekly. The lastest SuperSU has way more support as to this because it is outdated, and in beta at that. Safer and more compatible alternative would be SuperSU
Click to expand...
Click to collapse
I see your point but I still stick with this SU: SuperSU is closed source, and even Koush' open source Superuser app is theoretically less secure than this, due to the whole granting mechanism; with µSuper the user must explicitly select which apps gain su access whether they ask for it or not, and the code is so small there's little which could go wrong. Each to their own, though , I use this because the Desire Z is lacking in memory and CPU power so every little helps, but on a more powerful device it wouldn't bother me.
HTCDreamOn said:
I don't supposed you plan to support further Android versions? or is it easy for me to build this to support further versions?
Click to expand...
Click to collapse
I think the location for app files has changed from /data/data to something else. Since µSuper's su binary uses a hardcoded path to the permissions file (using an environment variable would be quite unsafe), the only things you would have to change are the targetSdkVersion in the app's AndroidManifest.xml and (if it did change) the path to the permissions file in su.c.
MarcoToo said:
I think the location for app files has changed from /data/data to something else. Since µSuper's su binary uses a hardcoded path to the permissions file (using an environment variable would be quite unsafe), the only things you would have to change are the targetSdkVersion in the app's AndroidManifest.xml and (if it did change) the path to the permissions file in su.c.
Click to expand...
Click to collapse
Forked and synced let's see if I can fix this for later versions I don't suppose you'd know how to implement this into a ROM (using source code)? From the README I assume I'm allowed to
No one have tried the new ROM Copperhead OS ?
Can i try to install it as secondary rom in MultiRom ?
I'm on Cyanogen CAF 12.1 now...
thank you all
chickygamon said:
No one have tried the new ROM Copperhead OS ?
Can i try to install it as secondary rom in MultiRom ?
I'm on Cyanogen CAF 12.1 now...
thank you all
Click to expand...
Click to collapse
Hi! I've installed it in multirom with a stock 5.0.1 as primary and it works, just tried it for few minutes.
just be sure to have the latest bootolader (HHZ12h) or installation will fail.
Flashing a bootloader
Hi,
I have a Nexus 5 and I use Multirom with it. My default ROM is Lollipop 5.1.1 and a secondary ROM, which I mostly use, is Marshmallow 6.0 (xTraSmooth). I want to install CopperheadOS, but it says when installing, that I must have HHZ12h bootloader in order to install (as stated in a previous post). My current bootloader is HHZ11k. If I install HHZ12h bootloader by flashing a zip file which includes LMY48B_Radio+Bootloader-HHZ12h will it cause anything that prevents Lollipop or Marshmallow to work properly?
ithippi said:
Hi,
I have a Nexus 5 and I use Multirom with it. My default ROM is Lollipop 5.1.1 and a secondary ROM, which I mostly use, is Marshmallow 6.0 (xTraSmooth). I want to install CopperheadOS, but it says when installing, that I must have HHZ12h bootloader in order to install (as stated in a previous post). My current bootloader is HHZ11k. If I install HHZ12h bootloader by flashing a zip file which includes LMY48B_Radio+Bootloader-HHZ12h will it cause anything that prevents Lollipop or Marshmallow to work properly?
Click to expand...
Click to collapse
You don't need to downgrade the bootloader, just modify the updater script of the rom ( deleting the string containing the bootloader version or replacing with your current version), then it will install just fine.
Can anybody provide link on COPPERHEAD OS ? CHEERS!
Pretoriano80 said:
You don't need to downgrade the bootloader, just modify the updater script of the rom ( deleting the string containing the bootloader version or replacing with your current version), then it will install just fine.
Click to expand...
Click to collapse
Thanks! I haven't tried that yet, but I will. First I thought I can just replace HHZ12h with HHZ11k using text editor, but then I noticed there are guides which suggest that it isn't quite that easy. I might be wrong about that, will see when I have enough time to read up on the subject.
Sent from my Nexus 5 using XDA Free mobile app
ithippi said:
Thanks! I haven't tried that yet, but I will. First I thought I can just replace HHZ12h with HHZ11k using text editor, but then I noticed there are guides which suggest that it isn't quite that easy. I might be wrong about that, will see when I have enough time to read up on the subject.
Sent from my Nexus 5 using XDA Free mobile app
Click to expand...
Click to collapse
It's easy, just extract the rom, go to Meta-Inf/com/google/android and modify the "updater-script". That's all, rebuild the zip and flash in recovery.
Edit: you can do it without using a PC, by using a file manager on your device.
Ross Korolov said:
Can anybody provide link on COPPERHEAD OS ? CHEERS!
Click to expand...
Click to collapse
here it is
https://copperhead.co/android/
....
Is this rom any good?
bonedriven said:
Is this rom any good?
Click to expand...
Click to collapse
Just installed it on a Nexus 5x and it works flawless. It has most of the standard stuff but is different from the rest in that it is supposed to be security oriented. That means no default root (but rooting should be possible).
I didn't try to add Google stuff yet and probably won't even try to add that spyware but it does have the F-Droid app store.
There are some extra options to secure the memory if required, and the documentation is (so far) very good (for example the install guide and the technical overview).
Currently running it on my Nexus 5x and N5. works great. Anything you are missing you can find on F-Droid. I find the lack of data usage to be delightful; when facebook or ebaum videos auto load on other software, they are stopped on copperhead. very happy with the security.
The only thing i can not make work is voice to text, and I have a ticket in with copperhead. who cares, I have fast thumbs.
Nexus + Copperhead = Happy Gopher!
mg.degroot said:
Just installed it on a Nexus 5x and it works flawless. It has most of the standard stuff but is different from the rest in that it is supposed to be security oriented. That means no default root (but rooting should be possible).
I didn't try to add Google stuff yet and probably won't even try to add that spyware but it does have the F-Droid app store.
There are some extra options to secure the memory if required, and the documentation is (so far) very good (for example the install guide and the technical overview).
Click to expand...
Click to collapse
happy_gopher said:
Currently running it on my Nexus 5x and N5. works great. Anything you are missing you can find on F-Droid. I find the lack of data usage to be delightful; when facebook or ebaum videos auto load on other software, they are stopped on copperhead. very happy with the security.
The only thing i can not make work is voice to text, and I have a ticket in with copperhead. who cares, I have fast thumbs.
Nexus + Copperhead = Happy Gopher!
Click to expand...
Click to collapse
Thanks for the feedback. I guess manual apk installation is also possible?
I'm thinking about picking up a Nexus 5 as a backup device, and CopperheadOS seems like something fun to play with, instead of just installing CM13. Can I install TWRP as recovery on devices like the Nexus 5 that don't check for locked bootloaders? Can I run it as basically another ROM –*unlocked developer options, root, TWRP, etc.? I realize the OS exists for enhanced security, but I'd like to make a few tradeoffs.
Unfortunately, you can not run TWRP with copperhead, it wants full control of the phone for security reasons. Its not meant to be a developer OS with access to all the bits, so you kind of need to want a OS in a box that you can deal with.
But I have to say, despite its shortcomings of not having google services, it works pretty much flawless on my 5 and 5x. i miss google maps app, but it works 100% via chromium browser as a favorite, and I have only found 2 apps I can not import via apkmirror, one being Waze, the other is my local public transportation app. other than that, i feel like I'm safe from prying eyes.
Hg
happy_gopher said:
Unfortunately, you can not run TWRP with copperhead, it wants full control of the phone for security reasons. Its not meant to be a developer OS with access to all the bits, so you kind of need to want a OS in a box that you can deal with.
But I have to say, despite its shortcomings of not having google services, it works pretty much flawless on my 5 and 5x. i miss google maps app, but it works 100% via chromium browser as a favorite, and I have only found 2 apps I can not import via apkmirror, one being Waze, the other is my local public transportation app. other than that, i feel like I'm safe from prying eyes.
Hg
Click to expand...
Click to collapse
Thanks for your response. I'm a fan of CyanogenMod, and I'm not unhappy their security or features, but I wanted to play around with CopperheadOS. I understand the tradeoff between security and convenience, but I'm not willing to sacrifice TWRP in the mix. Oh, well – if I ever have need of an OS solely for its security track record, I know where to go.
It doesn't look to me like Copperhead is supporting the Nexus 5 anymore. Can somebody confirm or is there a link I'm missing somewhere to the ROM?
EDIT: Yep, I knew it was deprecated for a while now but they've even removed the deprecated ROM from the site now. I'd appreciate it if anybody has the last ROM if they could pass it my way.
NewDayRising said:
Thanks for your response. I'm a fan of CyanogenMod, and I'm not unhappy their security or features, but I wanted to play around with CopperheadOS. I understand the tradeoff between security and convenience, but I'm not willing to sacrifice TWRP in the mix. Oh, well – if I ever have need of an OS solely for its security track record, I know where to go.
Click to expand...
Click to collapse
Switch debugging OFF and don't lock bootloader after CopperheadOS install and u will be able to boot TWRP via
fastboot boot recovery.img [TWRP]
I'm currently experimenting with root privileges on CopperheadOS on Nexus 5X. Still haven’t tried xposed framework.
Security features r quite good, especially different lock code && encryption password and memory protection, but, there is a lack of fine privacy control (Privacy Guard) as in CyanogenMod and firewall, hence the need for root.
CopperheadOS on Nexus5
dnaod said:
It doesn't look to me like Copperhead is supporting the Nexus 5 anymore. Can somebody confirm or is there a link I'm missing somewhere to the ROM?
EDIT: Yep, I knew it was deprecated for a while now but they've even removed the deprecated ROM from the site now. I'd appreciate it if anybody has the last ROM if they could pass it my way.
Click to expand...
Click to collapse
I've been using CopperheadOS for a few weeks now on the Nexus5. Received the latests OTA a few days ago and applied without issue.
Installed it via TWRP. Have rooted the device with SuperSU, though have to re-root after re-flashing recovery after each OTA.
It's been working great.
Unfortunately I don't have the img any more
The one I flashed was https://builds.copperhead.co/builds/hammerhead-factory-2016.08.09.06.24.33.tar.xz
download link
dnaod said:
It doesn't look to me like Copperhead is supporting the Nexus 5 anymore. Can somebody confirm or is there a link I'm missing somewhere to the ROM?
EDIT: Yep, I knew it was deprecated for a while now but they've even removed the deprecated ROM from the site now. I'd appreciate it if anybody has the last ROM if they could pass it my way.
Click to expand...
Click to collapse
https:// builds.copperhead.co /builds/hammerhead-factory-2016.09.07.19.27.04.tar.xz
Remove spaces. I'm a new member and can't post links.
Hello,
Today I have found myself the victim of Stagefright. Specifically CVE-2015-6602. The attacker gained remote code execution and attempted to copy all my data to a server. Luckily nothing sensitive was on the phone since it was my test unit. Still, this is important to note that attackers are still looking at exploiting older phones.
The phone in question was on android 5.0 : OptimalROM 15-5, with PB1 firmware. I had applied all the available security zips, still leaving two stagefright vulnerabilities:
CVE-2015-3864 (Mediaserver)
CVE-2015-6602 (libutils)
Please be aware if you are on a locked bootloader and choose to stay on older ROMs to keep root you are putting yourself at risk.
To see if you could have suffered the same fate as me if you were the attacker's target, use Zimperium's SF detector.
https://play.google.com/store/apps/details?id=com.zimperium.stagefrightdetector
This thread aims to provide flashable zips or manual instructions to patch any additional vulnerabilities existing in 5.0 that have been fixed in newer versions or 6.0.
--
First success! 1/2/2017
Implementation to patch ALL stagefright vulns on ALL 5.0 ROMs that have vulnerabilities!
see thread:
https://forum.xda-developers.com/ve...om-patch-optimalrom-15-5-stagefright-t3530922
Resources:
https://groups.google.com/forum/#!topic/android-security-updates/iv1BF0f0XY4
^ Main information, gives us the two commits:
Commit (Vuln patch)
https://android.googlesource.com/platform/system/core/+/5b85b1d40d619c2064d321364f212ebfeb6ba185
Commit (Compile error after, fixed on this commit)
https://android.googlesource.com/platform/system/core/+/e0dce90b0de2b2b7c2baae8035f810a55526effb
This tells is the vulnerability in libutils is specifically String8.cpp
/system/lib/libutils.so is the binary file that needs to be updated.
With this info, we can compile ourselves from the latest android, but the question is what will happen on replace? Will the system reject signature?
https://android.googlesource.com/platform/system/core/+/e0dce90b0de2b2b7c2baae8035f810a55526effb
^ Compiling a new libutils.so from the above commit.
I am not vulerable. 5.0 rooted.
gayflag said:
I am not vulerable. 5.0 rooted.
Click to expand...
Click to collapse
Interesting. What ROM are you on and what firmware?
Is the ROM based on that firmware?
Edit:
Thank you for this valuable information.
Stock PB1 ROMs are not vulnerable to stagefright.
This will make things easier for ROMs based on pre-PB1!
It is because of your post that I easily found a way to patch stagefright on OG5 and below based ROMs!
https://forum.xda-developers.com/ve...om-patch-optimalrom-15-5-stagefright-t3530922
I repackaged the xposed zip to also install a patched system linker removing the pie requirement for binary execution. Just a cosmetic change cause modern binaries compiled for android meet the requirement anyways. I also can upload a tweaked kernel boot image if anyone is interested. You could also repackage the zip to install a tweaked build.prop or other patched binaries which could open some doorways for improvements to performance or device functionality. Install in TWRP recovery environment. Enjoy!
Does this zip contain only linker or something else ?
Can I use this in mediatek variant of e4 ?
EDIT: 4 views and only one thank . This is how XDA users being generous to someone's post right now . LOL Just pressed the download button and don't bother to press thanks button.
Francesco Franz said:
Does this zip contain only linker or something else ?
Can I use this in mediatek variant of e4 ?
EDIT: 4 views and only one thank . This is how XDA users being generous to someone's post right now . LOL Just pressed the download button and don't bother to press thanks button.
Click to expand...
Click to collapse
I didn't download it, but definitely thanked. Love seeing development for this phone. I installed regular Xposed and it worked ok. I was going to try it later when I further understood the benefits.
anthonykb said:
I repackaged the xposed zip to also install a patched system linker removing the pie requirement for binary execution. Just a cosmetic change cause modern binaries compiled for android meet the requirement anyways. I also can upload a tweaked kernel boot image if anyone is interested. You could also repackage the zip to install a tweaked build.prop or other patched binaries which could open some doorways for improvements to performance or device functionality. Install in TWRP recovery environment. Enjoy!
Click to expand...
Click to collapse
So what's the benefit to removing pie? Just curious because the regular Xposed 88.2 worked fine for me.
Update: ok I did some reading, and found that removing that requirement can prove useful in certain situations.
Because Google in the update from Android KitKat to Android Lollipop has introduced a new type of restriction that blocks the execution of non-PIE binary.
This block mainly forces the user to copy the binaries he wants to run in /system/bin, /system/xbin, or in /sbin.
This restriction stops executing some apps (also app no-root), this modified version removes that restriction.
Doesn't seem to be working on the xt1776 though the official zip doesn't work either.
wrong section mate,,,,move to guide section...
Exploit is here: https://bugs.chromium.org/p/project-zero/issues/detail?id=1942#c7
On my S9 Plus the exploit never completes(see attached screenshot). I'm running the Sept 2019 patch that is supposed to be exploitable.
Also attached is the exploit compiled for arm64 using the Linux version of Google's Android NDK: https://developer.android.com/ndk/downloads/index.html
Made the arm64 toolchain with: ./android-ndk-r20/build/tools/make_standalone_toolchain.py --arch arm64 --install-dir ./arm64
It compiled properly then I copied it to /data/data/jackpal.androidterm, "chmod -x poc" to make it executable from Terminal Emulator: https://play.google.com/store/apps/details?id=jackpal.androidterm&hl=en_US
My guess is that the S9 Plus is not vulnerable or I did something wrong in the above steps.
I tried your build on my Pixel XL on Android P, and it locks the phone up a while, system UI crashes, and then the phone dies...I may need to build myself with a different NDK version?
If it were to work I could root and/or write a bit to a certain partition to allow OEM unlock.
Can you post a screenshot of the output before it dies. If not, can you post what output you get before it crashes?
bads3ctor said:
Exploit is here: https://bugs.chromium.org/p/project-zero/issues/detail?id=1942#c7
On my S9 Plus the exploit never completes(see attached screenshot). I'm running the Sept 2019 patch that is supposed to be exploitable.
Also attached is the exploit compiled for arm64 using the Linux version of Google's Android NDK: https://developer.android.com/ndk/downloads/index.html
Made the arm64 toolchain with: ./android-ndk-r20/build/tools/make_standalone_toolchain.py --arch arm64 --install-dir ./arm64
It compiled properly then I copied it to /data/data/jackpal.androidterm, "chmod -x poc" to make it executable from Terminal Emulator: https://play.google.com/store/apps/details?id=jackpal.androidterm&hl=en_US
My guess is that the S9 Plus is not vulnerable or I did something wrong in the above steps.
Click to expand...
Click to collapse
i get same output on my g975u and n976v on stock firmware. I believe it means wont work for us lol
elliwigy said:
i get same output on my g975u and n976v on stock firmware. I believe it means wont work for us lol
Click to expand...
Click to collapse
The exploit writers said that these phones are vulnerable:
1) Pixel 2 with Android 9 and Android 10 preview
2) Huawei P20
3) Xiaomi Redmi 5A
4) Xiaomi Redmi Note 5
5) Xiaomi A1
6) Oppo A3
7) Moto Z3
8) Oreo LG phones (run same kernel according to website)
9) Samsung S7, S8, S9
I was hoping my S9 Plus was vulnerable but I guess with your output being the same as mine.....we both will not get root
For ****s and giggles I tried for a few hours to hack the code to get it to continue the exploit without success.
I got the same 0x1000 (instead of correct 0x2000) output on my LG V20. I played around and changed WAITQUEUE_OFFSET to 0x90 (which isn't correct, but I was just experimenting), ran it, and then it forced a reboot of the system. That's some progress, since an unprivileged app shouldn't be able to force a reboot, so there may still be a vulnerability there to be exploited.
arpruss said:
I got the same 0x1000 (instead of correct 0x2000) output on my LG V20. I played around and changed WAITQUEUE_OFFSET to 0x90 (which isn't correct, but I was just experimenting), ran it, and then it forced a reboot of the system. That's some progress, since an unprivileged app shouldn't be able to force a reboot, so there may still be a vulnerability there to be exploited.
Click to expand...
Click to collapse
i think you're on the right track. you're probably causing a kernel panic which is causing the shut down. offsets have to be updated to be kernel specific so that's why you're crashing. can you post the output you saw before the crash? crash dump if you have one?
bads3ctor said:
My guess is that the S9 Plus is not vulnerable or I did something wrong in the above steps.
Click to expand...
Click to collapse
What does
Code:
uname -a
show on your device? The poc depends on the size of struct binder_thread, and as far as I can tell digging through kernel source, at some point that size was changed. So if the S9 uses a different version of the kernel, the exploit may need modifications.
arpruss said:
So if the S9 uses a different version of the kernel, the exploit may need modifications.
Click to expand...
Click to collapse
Any suggestions will be helpful. Attached is a screenshot of the current kernel version as of the Sept 2019 update. I can easily compile the exploit with any changes to the buffer.
Got same 0x1000 on Samsung Oreo 8.0, arm64, kernel 3.18.14-13712092-*, august security patch 2019.
error Lge q710al
Has anyone tried this on the SM-G965U yet?
Update:
I tried and same results as the OP.
Phantisy said:
Has anyone tried this on the SM-G965U yet?
Update:
I tried and same results as the OP.
Click to expand...
Click to collapse
From: https://github.com/marcinguy/CVE-2019-2215/
If writev is returning 0x1000 it means the timing is off, the wait queue offset is off, the kmalloc allocation in the writev function isn't the same as the freed binder_thread, or your kernel isn't vulnerable.
bads3ctor said:
From: https://github.com/marcinguy/CVE-2019-2215/
If writev is returning 0x1000 it means the timing is off, the wait queue offset is off, the kmalloc allocation in the writev function isn't the same as the freed binder_thread, or your kernel isn't vulnerable.
Click to expand...
Click to collapse
How would we go about finding these offsets? I think it may be possible to use this exploit for our device, except that the poc may need to be tuned to samsung kernel and its offsets.
bads3ctor said:
From: https://github.com/marcinguy/CVE-2019-2215/
If writev is returning 0x1000 it means the timing is off, the wait queue offset is off, the kmalloc allocation in the writev function isn't the same as the freed binder_thread, or your kernel isn't vulnerable.
Click to expand...
Click to collapse
According to Samsung, it is vulnerable. Guess we just need to figure out what is causing it not to work.
Phantisy said:
According to Samsung, it is vulnerable. Guess we just need to figure out what is causing it not to work.
Click to expand...
Click to collapse
link to the site where it is said to be confirmed? i want to double check before i waste any time
elliwigy said:
link to the site where it is said to be confirmed? i want to double check before i waste any time
Click to expand...
Click to collapse
According to the project zero post of the cve, s7, 8 and 9 are listed under the vulnerable devices.
https://bugs.chromium.org/p/project-zero/issues/detail?id=1942
f41lbl0g said:
According to the project zero post of the cve, s7, 8 and 9 are listed under the vulnerable devices.
https://bugs.chromium.org/p/project-zero/issues/detail?id=1942
Click to expand...
Click to collapse
yea, i saw s9 but not n9 tho lol who knows
Sent from my SM-N976V using Tapatalk
Something different!
From: https://github.com/arpruss/cve2019-2215-3.18
I compiled poc98-overwrite-pipe.c which gave me the 0x1000 failure but poc98.c succeeded in overflowing the kernel buffer on my S9+(see attached screenshot).
I'm not a kernel hacker so that's as far as I can get. Seems really close to being able to su to root. I attached poc98 compiled for arm64 so others can test it.
Edit: After reading the code, the actual exploit function is commented out so I'm going to take a crack at editing it but maybe someone with some kernel experience can take a look. I doubt I can make it work...I'm just a lowly PERL hacker!
Edit2: https://github.com/arpruss/cve2019-2215-3.18 seems to be a work in progress. New code was just uploaded. I think we have to make the exploit work on our kernel version.
Edit3: I re-added clobber_addr_limit(); to poc98.c and recompiled. Running it doesn't get an exploited kernel probably because it's written for a different kernel. That's about the extent of my kernel knowledge so we need a kernel hacker to get root.
bads3ctor said:
From: https://github.com/arpruss/cve2019-2215-3.18
I compiled poc98-overwrite-pipe.c which gave me the 0x1000 failure but poc98.c succeeded in overflowing the kernel buffer on my S9+(see attached screenshot).
I'm not a kernel hacker so that's as far as I can get. Seems really close to being able to su to root. I attached poc98 compiled for arm64 so others can test it.
Edit: After reading the code, the actual exploit function is commented out so I'm going to take a crack at editing it but maybe someone with some kernel experience can take a look. I doubt I can make it work...I'm just a lowly PERL hacker!
Edit2: https://github.com/arpruss/cve2019-2215-3.18 seems to be a work in progress. New code was just uploaded. I think we have to make the exploit work on our kernel version.
Edit3: I re-added clobber_addr_limit(); to poc98.c and recompiled. Running it doesn't get an exploited kernel probably because it's written for a different kernel. That's about the extent of my kernel knowledge so we need a kernel hacker to get root.
Click to expand...
Click to collapse
could you attach the latest version of your poc? (edit 3)