[KERNEL] [01-09-2013] [BLN-support] [CM9,CM10.1,CM10.2] Thor GB, ICS & JB

[user_99]

Und der nächste Thor ist im Anflug: Version 0.30 & 0.30-mr1 Link

Changelog:

0.30: fix lowmemorykiller adj interface not getting created
0.30: fix gpu control interface


Happy flashing...

 

[Jrp Defy]

So muss da nochmal nachhaken.
Der security fix ist nur Kernel bedingt?

Und thor hatte den aber schon von Anfang an drinnen?!

Grüße

Gesendet von meinem GT-N7000 mit der Android-Hilfe.de App

 

[AA1973]

Scheint laut chainfire der sicherste Weg zu sein (uber den Kernel) und Thor hat seinen v0.29mr1 dahingehend sofort abgesichert.

"topped only by actually fixing the exploit in the kernel."

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.

 

[cheezusweezel]

Thor v0.31 + v0.31-mr1 ist raus, OP ändere ich am Abend.

Link: http://forum.tegraowners.com/viewforum.php?f=32

Mit JellyBam 3.1.0 läuft er mal wunderbar, Scheduler ROW.

Gesendet von meinem GT-N7000 mit der Android-Hilfe.de App

 

[bangsti]

Danke Cheezusweezel
Mal schauen wie er mit der neuen SlimBean läuft.

 

[lassiter34]

Sag mal Fred, gibts eigentlich eine Rom, die du nicht testest?

 

[cheezusweezel]

Seite 1 wieder aktuell. Neue SlimBean ??? Gleich mal gucken ...

 

[bangsti]

@lassiter34
Hehe dazu sag ich nichts

@cheezusweezel
Link findest du in meinen Downloadthread bzw auf xda wurde einer eröffnet.

Zusammen mit Thor ist die neue SlimBean sehr flüssig.

*** Send from my Note CM 10.1 ***

 

[trahzebuck]

Sag mal Fred, gibts eigentlich eine Rom, die du nicht testest?

Na evtl. hat ja eybee an Fred gedacht, als er seinen Spruch über das Flashen eines Schinkensandwiches rausgehauen hat. lol.
Immer noch für mich einer der Top 10 Posts on XDA ever.

Sorry für OT.

 

[cheezusweezel]

Die neue Slim rockt, hab mal die käsige Variante in meinem Thread verlinkt ...

 

[carafaja]

hier läuft dieser Kernel sehr gut, wenn er denn mal den Boot-Vorgang beendet.

Es wird das Samsung Logo angezeigt und ein blauer Fortschrittsbalken. Dieser bleibt dann irgendwann einfach stehen. Nach den dritten oder vierten Versuch funktioniert es dann mal.

Was kann das sein?

-------
Tapatalked with a Samsung Galaxy Note™

 

[CVH]

dieses Phänomen hatte ich auch paar mal. Aber ich mach neuerdings immer ein kleinen Wipe (cache und dalvik cache) und installiere den Thor. Danach funktioniert der einwandfrei.

 

[lassiter34]

Ich mache immer einen kleinen Wipe, bevor ich einen Kernel flashe.

 

[user_99]

Und weiter geht es: 0.32 Link :http://forum.tegraowners.com/viewtopic.php?p=22404#p22404

 

[cheezusweezel]

Version 0.33 & 0.33-mr1 sind raus !

 

[user_99]

Und weiter geht's : Versionen 0.34 & 0.34-mr1 sind raus !

 

[CVH]

Update auf Nummer 034.1

Link zur CM10 Version: thor-kernel-jb-v0.34.1.zip

Link zur CM10.1 Version: thor-kernel-jb-v0.34.1-mr1.zip

 

[fragi]

Hast du vielleicht auch die Hashwerte?

Kriege für die 10.1-Version folgenden MD5 Hash 0d0ef9c6755060c7d7390646f051651a

 

[cheezusweezel]

Ist korrekt ... Seite 1 wieder aktuell.

 

[fragi]

Sauber