[2012.12.18] Why Exynos exploit patches may not work as expected + demo app

So I'm sure we've all heard about the ExynosAbuse exploit. If not, the original thread is here. The only proper solution is a kernel fix. This thread is only about app-based fixes.

There are various fixes available at the time of this writing, including my own. I don't mind some competition, that is not the problem. What is a problem is that some of these other app-based solutions out there have been mentioned and pushed a lot in the media (tech as well as non-tech) while they are seriously flawed (the only true solution is a kernel fix that simply removes the exploitable memory device, but that requires a non-universal device update, so we focus only on app-based fixes here that users may run immediately).

What I mean by flawed is that while they offer protection most of the time, they may leave a big gaping hole during boot that can be exploitable (as I will demonstrate) - and serious malware authors will of course include this attack vector in any serious malware - as will they include an attack vector to exploit temporary enabling of the exploit so you can use your camera (on devices where the fix breaks camera use).

Serious malware needs only a tiny hole to squeeze through once, and will attempt to leave it's own backdoor in case the hole they squeezed through is closed. Disabling the fix to use your camera only for a second with a malicious app running in the background running the exploit in a loop, and game over. I'm not even going to demo that, that flaw should be clear.

Due to unreliable fixes being mentioned by the media, a lot of people who have read online (or even print) news about this exploit may be using a fix they believe will work, but actual malware will easily bypass. Maybe some noise needs to be made about this ?

We're going to talk about three solutions here:

RyanZA's ExynosMemFix
Supercurio's Voodoo Anti ExynosMemAbuse v0.6
Chainfire's ExynosAbuse APK




The demo

What I am going to demo is running the exploit at boot, even though a fix that runs at boot is installed, on an exploitable device. After reading the rest of this article, find attached the ExynosExploitDemo APK. After installation, open the app, reboot your device, unlock your device (enter PIN, pattern, etc) and watch the screen like a hawk. Within a minute, a toast (bottom of the screen) notification will popup telling you whether the exploit worked. If it didn't work the first time, please try it at least 3 times. Once you are satisfied with the results, you should uninstall it again as it slows down the boot process.




Test setup

For each test I have completely factory reset the devices, and installed the "protection" APK before installing the exploit demo. Tests have been run on both Galaxy S3 as well as Galaxy Note 2, with and without SIMs installed. Tests were performed on December 18, 2012 with the most recent versions at that time.



BOOT_COMPLETED

Both RyanZA's as well as Supercurio's solution depend on Android launching the apps at boot (using the BOOT_COMPLETED mechanism), so they can plug the hole. This is a standard Android practise, The problem is, there is no guaranteed order in which apps are started at startup. A malicious app could also register to be started at boot (as the demo app does), and it would be a race whether the malicious exploit is run first, or the protection code. Luckily, you are more likely to have installed one of the patches before the malware, and the app that is installed first also has a better change of being run first - but is something that you cannot and should not rely on, nor does it guarantee the protection app will win the race, as explained below. The number of apps installed (and their package names, and what exactly they do at launch) may further influence which package "wins". What I'm trying to demonstrate here is that depending on this method of patching is unreliable at best.




The demo vs RyanZA's ExynosMemFix

RyanZA's is probably the least advertised/mentioned solution, which I expect is least used as well. The solution relies on BOOT_COMPLETED and "su" availability (like being rooted with SuperSU or Superuser), but does not rely on the exploit itself.

The reliance on "su" availability makes it vulnerable, it runs "su" to get the required access level to plug the hole. Even if installed before the malware and the system launches its startup code before the malware, the "su" call is an expensive one that can take an arbitrary amount of time to complete, regardless of the app having been granted permission before or not.

In my tests, even with ExynosMemFix installed before the demo, and having verified it's code launched first, it would always lose against the demo (and thus the exploit succeeds) if the root management app installed is Superuser. Due to the way the Superuser app is designed, it takes a longer time acknowledging the "su" request, giving the demo time to run the exploit. I have also seen ExynosMemFix generate an ANR error during testing a number of times, indicating that it may be calling "su" from the actual broadcast receiver (instead of a background thread), with all the problems that may cause.

When SuperSU is used, ExynosMemFix would always win against the demo in my tests (and thus the exploit fails), due to SuperSU responding much faster as it does not rely on the Android framework as Superuser does.

This solution can be somewhat secure, but even if used in combination with SuperSU, it cannot be guaranteed the malware does not launch first (I've seen it happen, but have not found the key to reproducing it yet). In combination with Superuser instead of SuperSU, the patch leaves a major hole.




The demo vs Supercurio's Voodoo Anti ExynosMemAbuse v0.6

Supercurio's is probably the most advertised/mentioned solution in general by media outlets. The solution relies on BOOT_COMPLETED and the exploit itself (but no "su" required).

The reliance on the exploit makes it vulnerable. The exploit may need to run a couple of times before it succeeds during boot, and it takes quite a few milliseconds to run. It runs the exploit to get the required access level to plug the hole. The exploit does however take some time to run, and both exploit as well as the hole-plugging-command must be completed before the malware starts, to effective block it.

In my tests, even with Voodoo Anti ExynosMemAbuse installed before the demo, and having verified it's code launched first, it would always lose against the demo (and thus the exploit succeeds). The protection code would launch before the demo code, but it would not complete (and fix the hole) before the malware was started, thus failing to block it.

Note that this specific case is probably especially sensitive to the number of apps you have installed - it may be the case that the more apps you have installed after this solution and before actual malware, the better the chance the protection will succeed before the malware is triggered. You can't possibly rely on this, though.

This solution is the least secure solution of all available options - it will leave a big hole open, you might as well not run any patch at all.




The demo vs Chainfire's ExynosAbuse APK

Mine is probably the second most advertised/mentioned solution. The solution relies on modifying /system and the exploit itself, with parts relying on "su".

This solution can root the device and install SuperSU as management app itself, though it also works with a pre-installed Superuser. It requires this to install the on-boot fix. After that patch is applied, you can unroot again (inside SuperSU: Settings --> Full unroot) - the patch will keep working. The patch itself does however modify /system, to make sure the fix is applied before any normal Android app is started with BOOT_COMPLETED, completely preventing the hole the demo app (and malware) would use to run the exploit. As such, the exploit always fails.

This solution is the most secure solution of the available options in this regard, topped only by actually fixing the exploit in the kernel.




Virus/malware/etc scanners

I have also noticed that various virus and malware scanners have updated their definitions in the past few days, and they will now detect the original ExynosAbuse exploit. Be warned however, that this specific hole can be exploited in many different ways and the example code provided by alephzain is just that: an example. I am not at all convinced that all different exploits based on this hole can even theoretically be reliably detected by these scanners - including Google's - unless every app is actually tested against in a sandbox environment (and even then ...). They may protect against those using the exploit as-is, though.




The big joke

The funny thing is, all the fixes that can actually work void warranty: mine requires modifying /system, RyanZA's requires root as well, and a proper fix requires a custom kernel.

In other words, right now you can't really protect yourself against this abuse without voiding your warranty. If there ever was a case for having laws against limitations of warranty, this is it. On a related note, any warranty denied because your system status is "modified" is also completely bogus, as a successful exploit might (outside of your knowledge) probably try to install their own backdoor in /system ... which might trigger "modified" status.

Also, if you're thinking this is complicated code, malware authors are not smart enough, etc - think again. Serious malware authors live and breathe this stuff, and the relevant code for this attack is rather trivial and only about 30 lines, including whitespace and actually showing you the exploit result.

Another joke is that I seriously doubt any major news outlet will post a correction, but hey at least I tried




Different test results

Let us please not make this thread about your test results being different. If you have read and understood all the text above, you would know that there are various factors that may throw the test outcome one way or the other. Unless your sure your different result is significant in being different, please do not clutter the thread with it.




Download
If you have a decent and updated virus scanner, it will likely scream at you for trying to download this. It is after all an exploit. You may need to turn it off if you want to test this for yourself.

supercurio said:

Chainfire, guys, please give a try to the v0.7 version of my app, same place.

Chainfire, it would have been nice to be informed while you were preparing the article (on your early conclusions)

Click to expand...

Click to collapse

supercurio said:

Yes, that's good thinking.
And also why I tried to provide something (even an imperfect workaround) that doesn't alter system.

I have 2 questions tho and I'll verify to get an answer to the first one.

- Is my app really not triggering the "modified" status
- If Chainfire un-do all the modifications applied by his tools, will the device return to its "un-modified" status

Or maybe the "un-modified" status can be faked, restoring the proper function of OTA updates.

Click to expand...

Click to collapse

supercurio said:

The 0.9 update of my app is strong now on boot (or less weak), but this is not very satisfying.

Frustrating as there's no "perfect" fix for regular users I'm thinking about right now.
I'm not really a fan of waiting, are you ?

Click to expand...

Click to collapse

Nice to have been informed ? I've stated in the threads regarding the exploit and fixes that yours and RyanZA's solutions are not secure.

The problem is that any solution based on BOOT_COMPLETE can never be secure. And "sort of", "mostly", etc, have absolutely no place in security.

To me it appears (I have not checked the code, so I'm just guessing) you now make the receiver blocking during the exploit process in v0.9, again relying on boot order. You cannot rely on boot order even in ideal conditions, and I can think of several scenarios where that just doesn't work (protecting too late) or crashes (leaving you completely unprotected).

Sure, that beats the attached version in the first post, but I have several more tricks up my sleeve. I've rerun my tests against both RyanZA and your v0.9 with a private exploit test version that beats both protections every single time. Before anybody asks me to publish it - sorry but I will not. That may sound like a cop-out (think and say what you will) but if I do release it, you will only try to improve your solution - completely missing the point.

Anyway, I will not discuss the point further, I believe I have made my point, and nothing I can further say or do will convince anyone more than who is already convinced.

As for the modified status, yes that is totally reversable. I'll document this in more detail, maybe add a button in the app to help with it. As for your fix triggering modified, your app can trigger it, but it depends on the firmware version.

RyanZA said:

Props on the great research Chainfire, I agree with it all 100%

Personally though, malware authors target the easy and low hanging fruit - in this case, 99% of phone users who have not used any kind of fix. (99% is a very low estimate). They have no real reason to try and 'out race' mine or supercurios fix in practice, as (mine in particular) has very few users. Why bother creating a special exploit that only runs on boot, when you can just target 99%+ of all unfixed devices by just running the exploit when the app is started?

I've seen 4 malicious uses of the exploit in the wild so far, and all of them run on app start, which is blocked by all 3 'unsecure'/non-kernel fixes. Users are still VERY heavily encouraged to use any of the fixes as they currently stop all uses of the exploit in the wild. Supercurios is still the best one as it does not require root, and should definitely be advertised by the media as much as possible as it stops a real world and current threat to user security as best as it can.

Click to expand...

Click to collapse

The thing is, if I was a blackhat you'd all have some serious problems with that attitude, you would notice by the hard-bricked device in your hand. Maybe we're all lucky I'm not and that all malware authors are too lazy to add 20 trivial lines to their code. (Right ...)

Also who said that exploit would only run at boot ? It's simply what I decided to test against because it's the most obvious flaw. A proper package would try the exploit at several times ... including boot.

Just because you build your house in the middle of nowhere is no guarantee it won't be burgled. And when said burgler comes, if your windows are barred it's not going to help if there's a big gaping hole where your door should be.

Supercurio's is IMHO still the worst one, as it's the easiest one to beat. And it does require root, it just doesn't tell you about it and uses the exploit itself to root. That difference is just meaningless words. It also keeps a rooted background process around that it communicates with through a socket, of which I'm not sure how secure that even is (who knows that might be exploitable, I haven't bothered to try).

As stated though, I'm not going to discuss that point further. If you don't agree I'm not going to be able to convince you.

Furthermore, you're assuming that we know about all the exploits in the wild ... due to the nature of the exploit, it seems unlikely you can reliably detect this type of exploit - there are many ways this hole can be abused, the code going around is just one example of it.

makkeonmies said:

maybe note worthy thing to here, in EU you dont lose your warrantly for applying fixes like this in fact you can install kernels/roms as many times as you want and you still got your warrantly. what comes to my own experience from this, my phone have been repaired 2 times because micro-usb didnt want to co-operate with me first time i had miui installed, second time had cm10 when i sent my phone to get fixed, both times got it fixed free of charge.

source: https://fsfe.org/freesoftware/legal/flashingdevices.en.html
tl;dr
if flashing original firmware dont fix issues you had on your phone, then you must have the damage covered free of charge(ie. micro-usb port goes crazy)

Click to expand...

Click to collapse

Being in the right and getting your right are two different things. While what you say is no doubt true, the manufacturer can still claim your rooting/custom firmware is what caused the damaged to the device. And while I believe it's actually their responsibility to prove that, in reality, what are you going to do when they simply refuse to fix your device due to root ?

As an example, HTC claimed HSPL (the bootloader unlock back in WM days) broke my screen, and the (official HTC) repair center simply refused to fix it, because HTC HQ would not cover it (which is not in the EU). Threw some law and some lawyers at them, and in the end my device did get repaired, but I'm pretty sure the repair center footed the bill itself, and with the amount of time and money spent on the process, it would have been cheaper to just buy a new one.

toxicthunder said:

@supercurio I was wondering the exact same thing on how may the "un-modified" status can be faked. Then again, as another user pointed out, though warranty rules and regulations maybe the same across all regions - it is their comprehension and application which is ambiguous.

I for one can attest that at my place they will simply replace the internals of your phone as long as the purchase bill you produce confirms that your device is still covered by the manufacturer warranty.

Click to expand...

Click to collapse

The unmodified status cannot currently be faked (well technically it can, but nobody done it yet), but the state is certainly restorable (I will document this further with my app).

La_Globule said:

Thanks Chainfire for this clear explanation.

I would add that, as soon as the exploit has been discovered, it is now risky to install or update apps if you are unsure about the editor.
And this is more risky today than before.
However I think there are several software editors in which we can trust in.

As far as already installed apps are concerned, either they are safe and there is no problem if you do not change anything (add or update).
If one of them is not safe, it is too late, because it lasts before the exploit.

Click to expand...

Click to collapse

If the author of an app you have installed already would release an update to their app containing the malware and running it at boot, it will generally run before Supercurio's or RyanZA's fix, and you'd be screwed.

RotesMeerJogger said:

really great work chainfire and thanks for your spent time to fix this security hole. i have one last question: can i test if any app/programm use actually this exploit on my device? or if i be infected and run your app, from this time no ohter app can use the exploit?

Click to expand...

Click to collapse

If you run my patch at boot no other app should be able to use the exploit - I am not aware of any way to beat my method.

My app clearly states the limitations of the approach (inside the app itself, leaves no doubt)

But it should not loose every time against the demo exploit at boot, so I'll change for a more aggressive way to start.
Thanks Chainfire for taking the time to test.

2012.12.19 Update
I have a new (private, yeah) version of the demo that now beats both Supercurio's (v0.9) as well RyanZA's solution 100% of the time

--- also reserved ---