In this post, I’ll look at CVE-2023-6241, a vulnerability in the Arm Mali GPU that I reported to Arm on November 15, 2023 and was fixed in the Arm Mali driver version r47p0, which was released publicly on December 14, 2023. It was fixed in Android in the March security update. When exploited, this vulnerability allows a malicious Android app to gain arbitrary kernel code execution and root on the device. The vulnerability affects devices with newer Arm Mali GPUs that use the Command Stream Frontend (CSF) feature, such as Google’s Pixel 7 and Pixel 8 phones. What is interesting about this vulnerability is that it is a logic bug in the memory management unit of the Arm Mali GPU and it is capable of bypassing Memory Tagging Extension (MTE), a new and powerful mitigation against memory corruption that was first supported in Pixel 8. In this post, I’ll show how to use this bug to gain arbitrary kernel code execution in the Pixel 8 from an untrusted user application. I have confirmed that the exploit works successfully even with kernel MTE enabled by following these instructions.

source: HN

so basically the pixel 7 pro, when you crop and save a screenshot, overwrites the image with the new version, but leaves the rest of the original file in its place

https://twitter.com/ItsSimonTime/status/1636857478263750656

source: L

As just one example (unrelated to what follows), their software bundles FFmpeg DLLs that were built in 2012 and have not been updated since then. There have been over a hundred security updates in that time, none of which have been applied.

In completely unrelated news, upcoming versions of Signal will be periodically fetching files to place in app storage. These files are never used for anything inside Signal and never interact with Signal software or data, but they look nice, and aesthetics are important in software. Files will only be returned for accounts that have been active installs for some time already, and only probabilistically in low percentages based on phone number sharding. We have a few different versions of files that we think are aesthetically pleasing, and will iterate through those slowly over time. There is no other significance to these files.

This is part 1 of a 6-part series detailing a set of vulnerabilities found by Project Zero being exploited in the wild.

At Project Zero we often refer to our goal simply as “make 0-day hard”. Members of the team approach this challenge mainly through the lens of offensive security research. And while we experiment a lot with new targets and methodologies in order to remain at the forefront of the field, it is important that the team doesn’t stray too far from the current state of the art. One of our efforts in this regard is the tracking of publicly known cases of zero-day vulnerabilities. We use this information to guide the research. Unfortunately, public 0-day reports rarely include captured exploits, which could provide invaluable insight into exploitation techniques and design decisions made by real-world attackers. In addition, we believe there to be a gap in the security community’s ability to detect 0-day exploits.

Chrome: Infinity Bug - https://googleprojectzero.blogspot.com/2021/01/in-wild-series-chrome-infinity-bug.html

Chrome Exploits - https://googleprojectzero.blogspot.com/2021/01/in-wild-series-chrome-exploits.html

Android Exploits - https://googleprojectzero.blogspot.com/2021/01/in-wild-series-android-exploits.html

Android Post-Exploitation - https://googleprojectzero.blogspot.com/2021/01/in-wild-series-android-post-exploitation.html

Windows Exploits - https://googleprojectzero.blogspot.com/2021/01/in-wild-series-windows-exploits.html

In this work we attempt a full accounting of the current and historical status of smartphone security measures. We focus on several of the most popular device types, and present a complete description of both the available security mechanisms in these devices, as well as a summary of the known public information on the state-of-the-art in bypass techniques for each. Our goal is to provide a single periodically updated guide that serves to detail the public state of data security in modern smartphones.

source: green

Every minute of every day, everywhere on the planet, dozens of companies — largely unregulated, little scrutinized — are logging the movements of tens of millions of people with mobile phones and storing the information in gigantic data files. The Times Privacy Project obtained one such file, by far the largest and most sensitive ever to be reviewed by journalists. It holds more than 50 billion location pings from the phones of more than 12 million Americans as they moved through several major cities, including Washington, New York, San Francisco and Los Angeles.

Each piece of information in this file represents the precise location of a single smartphone over a period of several months in 2016 and 2017. The data was provided to Times Opinion by sources who asked to remain anonymous because they were not authorized to share it and could face severe penalties for doing so. The sources of the information said they had grown alarmed about how it might be abused and urgently wanted to inform the public and lawmakers.

source: L

Public defenders lack access to gadgets and software that could keep their clients out of jail.

This tech gap has two basic forms. First, law enforcement agencies can use warrants and court orders to compel companies to turn over emails, photos and other communications, but defense lawyers have no such power. And second, the government has access to forensic technology that makes digital investigations easier. Over the last two decades, the machines and software designed to extract data from computers and smartphones were primarily made for and sold to law enforcement.

To successfully defend its clients, the Legal Aid Society, New York City’s largest public defender office, realized in 2013 that it needed to buy the same tools the police had: forensic devices and software from companies including Cellebrite, Magnet Forensics and Guidance Software. Not only does the expensive technology unearth digital evidence that is otherwise hard or impossible to find, it captures it in a format that can hold up in court, as opposed to evidence that could have been tampered with or forged.

source: green

Motorola has today announced a modern successor to one of the most iconic phones ever released: the Razr V3. The popular flip-phone was first released in 2004 and had been a huge success for the company as it went on to sell over a 100M units. The clamshell design was immensely popular as it was a lot thinner and had a unique design. The new Razr takes the core aspects of this design and ports it over to the latest 2019 technologies. At the heart of the new smartphone lies Motorola’s take on foldable displays, giving the new Razr a proper modern “full body screen” experience.

A nice look at how they got the fold to work. We’ll see.

Over the past few weeks, those of you who frequent the DAY[0] streams over on our Twitch may have seen me working on trying to understand the recent Android Binder Use-After-Free (UAF) published by Google’s Project Zero (p0). This bug is actually not new, the issue was discovered and fixed in the mainline kernel in February 2018, however, p0 discovered many popular devices did not receive the patch downstream. Some of these devices include the Pixel 2, the Huawei P20, and Samsung Galaxy S7, S8, and S9 phones. I believe many of these devices received security patches within the last couple weeks that finally killed the bug.

After a few streams of poking around with a kernel debugger on a virtual machine (running Android-x86), and testing with a vulnerable Pixel 2, I’ve came to understand the exploit written by Jann Horn and Maddie Stone pretty well. Without an understanding of Binder (the binder_thread object specifically), as well as how Vectored I/O works, the exploit can be pretty confusing. It’s also quite clever how they exploited this issue, so I thought it would be cool to write up how the exploit works.

source: grugq

The API blacklist tracks who’s calling a function. If the source isn’t exempt, it crashes. In the first example, the source is the app. However, in the second example, the source is the system itself. Instead of using reflection to get what we want directly, we’re using it to tell the system to get what we want. Since the source of the call to the hidden function is the system, the blacklist doesn’t affect us anymore.

The call is coming from inside the system!

source: grugq

All over the world, in Dutch clubs like the one Kok frequented, or Australian biker hangouts and Mexican drug safe houses, there is an underground trade of custom-engineered phones. These phones typically run software for sending encrypted emails or messages, and use their own server infrastructure for routing communications.

For MPC, the process of setting up the devices was relatively simple: MPC would take a Google Nexus 5 or Nexus 5X Android phone, and then add its own security features and operating system, according to social media posts from MPC and a source with knowledge of the process. MPC then created the customer’s messaging accounts, added a data-only SIM card (which MPC paid about £20 a month for), and then sold the phone to the customer at £1,200. Six-month renewals cost £700, the source added. MPC only sold around 5,000 phones, the source said, but that still indicates the business netted the company some £6 million. At one point, a version of MPC’s phones also used code from an open-source, security-focused Android fork called CopperheadOS, three sources said.

More: https://www.vice.com/en_us/article/kz4yxa/encrypted-phone-company-mpc-helped-martin-kok-murder

source: cox

In this blog post, I’m going to share about a double-free vulnerability that I discovered in WhatsApp for Android, and how I turned it into an RCE.

Double-free vulnerability in DDGifSlurp in decoding.c in libpl_droidsonroids_gif

source: HN

This paper is a study of Android apps in the wild that leak permission protected data (identifiers which can be used for tracking, and location information), where those apps should not have been able to see such data due to a lack of granted permissions. By detecting such leakage and analysing the responsible apps, the authors uncover a number of covert and side channels in real-world use.

As part of our continuous commitment to improve the security of the Android ecosystem, we are partnering with Arm to design the memory tagging extension (MTE). Memory safety bugs, common in C and C++, remain one of the largest vulnerabilities in the Android platform and although there have been previous hardening efforts, memory safety bugs comprised more than half of the high priority security bugs in Android 9.

We believe that memory tagging will detect the most common classes of memory safety bugs in the wild, helping vendors identify and fix them, discouraging malicious actors from exploiting them. During the past year, our team has been working to ensure readiness of the Android platform and application software for MTE. We have deployed HWASAN, a software implementation of the memory tagging concept, to test our entire platform and a few select apps. This deployment has uncovered close to 100 memory safety bugs. The majority of these bugs were detected on HWASAN enabled phones in everyday use. MTE will greatly improve upon this in terms of overhead, ease of deployment, and scale. In parallel, we have been working on supporting MTE in the LLVM compiler toolchain and in the Linux kernel. The Android platform support for MTE will be complete by the time of silicon availability.

source: grugq

When we published our paper in 2015, we predicted that this vulnerability would not be patched on 95% of devices in the Android ecosystem until January 2018 (plus or minus a standard deviation of 1.23 years). Since this date has now passed, we decided to check whether our prediction was correct.

The good news is that we found the operating system update requirements crossed the 95% threshold in May 2017, seven months earlier than our best estimate, and within one standard deviation of our prediction. The most recent data for May 2019 shows deployment has reached 98.2% of devices in use. Nevertheless, fixing this aspect of the vulnerability took well over 4 years to reach 95% of devices.

oof.

We have developed a new type of fingerprinting attack, the calibration fingerprinting attack. Our attack uses data gathered from the accelerometer, gyroscope and magnetometer sensors found in smartphones to construct a globally unique fingerprint.

A side-channel attack can extract private keys from certain versions of Qualcomm’s secure keystore. Recent Android devices include a hardware-backed keystore, which developers can use to protect their cryptographic keys with secure hardware. On some devices, Qualcomm’s TrustZone-based keystore leaks sensitive information through the branch predictor and memory caches, enabling recovery of 224 and 256-bit ECDSA keys. We demonstrate this by extracting an ECDSA P-256 private key from the hardware-backed keystore on the Nexus 5X.

Paper: https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2019/hardwarebackedhesit.pdf

source: HN

The new orders, sometimes called “geofence” warrants, specify an area and a time period, and Google gathers information from Sensorvault about the devices that were there. It labels them with anonymous ID numbers, and detectives look at locations and movement patterns to see if any appear relevant to the crime. Once they narrow the field to a few devices they think belong to suspects or witnesses, Google reveals the users’ names and other information.

The same thing (except without the happy ending) happened to me. Hidden messages where there definitely couldn’t be any, reversing Java code and its native libraries, a secret VM, a Google interview — all of that is below.

In the end I got an app that emulated the entire DroidGuard process: makes a request to the anti-abuse service, downloads the .apk, unpacks it, parses the native library, extracts the required constants, picks out the mapping of VM commands and interprets the byte code. I compiled it all and sent it off to Google.

The answer didn’t take long. An email from a member of the DroidGuard team simply read: “Why are you even doing this?”

source: L

Websites (or 3rd party content) that continually pings a server will not allow the cellular radio to turn off, and can lead to battery drain. In this post, I have shown 4 different scenarios where my Android device continues to download content for 5 minutes after the page has been minimized on the phone.

source: L