Could you give me your email address?

[ele7enxxh]

Hi,

I have some other questions that need you help, but I do not have your email so I just submitted this issue. And my email is ele7enxxh@gmail.com.

Thanks!

[michalbednarski]

I guess issue is okay for asking questions here (or at least it was already used once that way in this repository)

[ele7enxxh]

Thank for you reply.

I am interested in CVE-2017-0806, but I have no idea how to reproduce this vulnerability. Could you share POC or more details about it?

[michalbednarski]

Below is some context on why above behavior is vulnerability, which will be helpful if you're trying to reproduce this

For reference for everybody else, here's commit fixing that CVE.

Code diff doesn't make issue clear, commit message say a bit more, but to understand what the issue is we must step back to an old bug fixed in 2013 (not found by me)

Android bug 7699048 (LaunchAnyWhere)

Links (none of them by me):

• patch
• writeup (in Chinese) (Google translate might be useful)

Basically, above bug was that Account Authenticator could provide Intent in AccountManager.KEY_INTENT and that Intent was started.

As you can see in patch above, it was fixed by adding validation of KEY_INTENT in AccountManagerService in system_server and now flow is (more or less):

1. Application starts system Activity to show account chooser (e.g. ChooseTypeAndAccountActivity)
2. System Activity requests AccountManagerService to perform operation using Account Authenticator
3. AccountManagerService in system_server binds to authenticator
4. AccountManagerService invokes method on Account Authenticator and gets response from it
5. AccountManagerService checks Bundle returned by Authenticator, if it has KEY_INTENT specified that points to Activity that doesn't belong to Authenticator, result is rejected.
6. If everything was ok, AccountManagerService sends result Bundle back to system Activity
7. If result Bundle has KEY_INTENT, system Activity launches Activity described by it

Now, in steps above there's an assumption that this bug can violate: that result Bundle won't spuriously change it's contents while it's being sent in step 6

"Self changing" Bundles

Now, to understand how we could cause Bundle to change it's contents while it's being sent, we need to understand how Bundles are sent between processes using Parcel.

Relevant code fragments:

• BaseBundle.writeToParcelInner
• Parcel.writeArrayMapInternal
• Parcel (native side, Strings are written using writeString16)

Relevant characteristics of Parcel are:

• Parcel doesn't remember types of data written to it (with the exception of "Active Objects", such as Binder and ParcelFileDescriptor, but these are not important here)
• Above means that you can use writeString and later user readInt to read raw binary data that was put in Parcel
• Preferred way of putting Objects to Parcel is by implementing Parcelable interface
• When Parcelable is read from Parcel, Parcel uses ClassLoader to find class by name, any class present in system that implements Parcelable interface can be put in Bundle
• It is responsibility of Parcelable implementation to always read same amount of data it has written, if it won't do so, next values from Parcel will be loaded from wrong offset

Now, that last point is what can be violated using this bug. This means, that using this bug it is possible to cause data written after GateKeeperResponse into Parcel can be read differently than it was written. By carefully constructing Bundle it's possible to create one that will contain different Intent when it's verified whenever target Activity belongs to Authenticator and different Intent when it's about to be passed to startActivity()

What to do with arbitrary startActivity() with system privileges

• Install another APK
• Similary, uninstall
• Probably more (blogpost describing Dropbox application bug)
• Get access to some ContentProviders

[ele7enxxh]

Thank you so much for your help.

I have reproduced this issue on pixel device and bypass android-bug-7699048.

[ScottyBauer]

Sorry to dig up an old topic. I'm trying to wrap my head around the actual flow of how the combination of the gatekeeper response bug combined with launch anywhere primitive allows us to run any activity. At a high level it looks like we're able to hide intents inside of a malformed gatekeeper response. When the malformed gatekeeper response is un-seralized it ends up making the rest of the bundle look like there is an Intent? Is that high level overview correct?

[michalbednarski]

hide intents inside of a malformed gatekeeper response.

Well, GateKeeperResponse doesn't contain Intent at any point here, it just stays aside in same Bundle to throw serialization off, but key under which it sits is not accessed by code verifying nor launching Intent, those read KEY_INTENT which is relevant for them and serialization grabs all values which stay in Bundle.

The point is that Bundle has to be deserialized correctly and present one Intent (or possibly no Intent at all depending on which place in system is used to finally launch activity) and then that Bundle needs to be serialized by system and after second deserialization present different Intent.

I'll clean up and post tomorrow PoC.

[michalbednarski]

PoC is now posted at https://github.com/michalbednarski/ReparcelBug

[heeeeen]

Thank you for the information! I've been studying this topic since a series of this kind of vulnerabilities acknowledged in Android Security Bulletin. Now I find this original source! From other clues, I've already written a detailed writeup on this in http://www.ms509.com/2018/07/03/bundle-mismatch/ (Chinese)

[bagipro]

@michalbednarski
Hi, do you have any examples how CVE-2018-9522 could be exploited? I don't really see any danger in the changed code
https://android.googlesource.com/platform/frameworks/base/+/181dc252ddec574464882970d3fab290e8b625b5%5E%21/#F0

[michalbednarski]

CVE-2018-9522 is bug in same family of Parcelable mismatch bugs as CVE-2017-0806 this thread was originally about, has same impact and similar exploitation technique. Everything in this thread (except PoC which needs minor changes to actually target this bug) applies to CVE-2018-9522 as well.

[pwnipc]

Hello @michalbednarski , couldn't find a way to reach out so I'll use this Issue. Uhmm, is it possible to spawn an activity that would inherit the system privileges or maybe launch an app with uid 1000 using this vulnerability or even change ADB's shell process uid to 1000?

[michalbednarski]

In general by "start Activity as system" I mean having system perform startActivity(attackerControlledIntent), not that launched Activity will be running as anything other than it'd usually run

In general case Parcel mismatch doesn't lead to code execution, although there were some specific cases where it did, for example on Android 12 Beta

For testing impact of issues on development builds of Android you can use su 1000 in adb or attach debugger to application running under that uid

[pwnipc]

Thank you.