site: googleprojectzero.blogspot.com
The curious tale of a fake Carrier.app
https://googleprojectzero.blogspot.com/2022/06/curious-case-carrier-app.html [googleprojectzero.blogspot.com]
2022-06-23 22:55
tags:
cxx
exploit
investigation
iphone
security
turtles
Six privilege escalation exploits are bundled with this app. Five are well-known, publicly available N-day exploits for older iOS versions. The sixth is not like those others at all. This blog post is the story of the last exploit and the month-long journey to understand it.
The More You Know, The More You Know You Don’t Know
https://googleprojectzero.blogspot.com/2022/04/the-more-you-know-more-you-know-you.html [googleprojectzero.blogspot.com]
2022-04-20 01:49
tags:
development
exploit
security
update
This is our third annual year in review of 0-days exploited in-the-wild [2020, 2019]. Each year we’ve looked back at all of the detected and disclosed in-the-wild 0-days as a group and synthesized what we think the trends and takeaways are. The goal of this report is not to detail each individual exploit, but instead to analyze the exploits from the year as a group, looking for trends, gaps, lessons learned, successes, etc.
A Look at iMessage in iOS 14
https://googleprojectzero.blogspot.com/2021/01/a-look-at-imessage-in-ios-14.html [googleprojectzero.blogspot.com]
2021-01-29 00:17
tags:
defense
development
iphone
security
The blog post will start with an overview of the major changes Apple implemented in iOS 14 which affect the security of iMessage. Afterwards, and mostly for the readers interested in the technical details, each of the major improvements is described in more detail while also providing a walkthrough of how it was reverse engineered. At least for the technical details, it is recommended to briefly review the blog post series from last year for a basic introduction to iMessage and the exploitation techniques used to attack it.
This approach could apply to any system.
Introducing the In-the-Wild Series
https://googleprojectzero.blogspot.com/2021/01/introducing-in-wild-series.html [googleprojectzero.blogspot.com]
2021-01-13 07:29
tags:
admin
android
browser
exploit
malware
programming
security
series
windows
windows
Enter the Vault: Authentication Issues in HashiCorp Vault
https://googleprojectzero.blogspot.com/2020/10/enter-the-vault-auth-issues-hashicorp-vault.html [googleprojectzero.blogspot.com]
2020-10-11 21:11
tags:
auth
cloud
exploit
security
This is tediously complex, IMO (as someone who doesn’t use the service in question), but the conclusion is worth considering.
In my experience, tricky vulnerabilities like this often exist where developers have to interact with external systems and services. A strong developer might be able to reason about all security boundaries, requirements and pitfalls of their own software, but it becomes very difficult once a complex external service comes into play. Modern cloud IAM solutions are powerful and often more secure than comparable on-premise solutions, but they come with their own security pitfalls and a high implementation complexity. As more and more companies move to the big cloud providers, familiarity with these technology stacks will become a key skill for security engineers and researchers and it is safe to assume that there will be a lot of similar issues in the next few years.
Finally, both discussed vulnerabilities demonstrate how difficult it is to write secure software. Even with memory-safe languages, strong cryptography primitives, static analysis and large fuzzing infrastructure, some issues can only be discovered by manual code review and an attacker mindset.
One Byte to rule them all
https://googleprojectzero.blogspot.com/2020/07/one-byte-to-rule-them-all.html [googleprojectzero.blogspot.com]
2020-08-07 01:09
tags:
exploit
iphone
programming
security
systems
For the last several years, nearly all iOS kernel exploits have followed the same high-level flow: memory corruption and fake Mach ports are used to gain access to the kernel task port, which provides an ideal kernel read/write primitive to userspace. Recent iOS kernel exploit mitigations like PAC and zone_require seem geared towards breaking the canonical techniques seen over and over again to achieve this exploit flow. But the fact that so many iOS kernel exploits look identical from a high level begs questions: Is targeting the kernel task port really the best exploit flow? Or has the convergence on this strategy obscured other, perhaps more interesting, techniques? And are existing iOS kernel mitigations equally effective against other, previously unseen exploit flows?
In this blog post, I’ll describe a new iOS kernel exploitation technique that turns a one-byte controlled heap overflow directly into a read/write primitive for arbitrary physical addresses, all while completely sidestepping current mitigations such as KASLR, PAC, and zone_require. By reading a special hardware register, it’s possible to locate the kernel in physical memory and build a kernel read/write primitive without a fake kernel task port. I’ll conclude by discussing how effective various iOS mitigations were or could be at blocking this technique and by musing on the state-of-the-art of iOS kernel exploitation. You can find the proof-of-concept code here.
https://bugs.chromium.org/p/project-zero/issues/detail?id=1986#c7
Related: https://googleprojectzero.blogspot.com/2020/07/the-core-of-apple-is-ppl-breaking-xnu.html
The core of Apple is PPL: Breaking the XNU kernel's kernel
https://googleprojectzero.blogspot.com/2020/07/the-core-of-apple-is-ppl-breaking-xnu.html [googleprojectzero.blogspot.com]
2020-08-01 01:27
tags:
defense
exploit
iphone
malloc
programming
security
systems
While doing research for the one-byte exploit technique, I considered several ways it might be possible to bypass Apple’s Page Protection Layer (PPL) using just a physical address mapping primitive, that is, before obtaining kernel read/write or defeating PAC. Given that PPL is even more privileged than the rest of the XNU kernel, the idea of compromising PPL “before” XNU was appealing. In the end, though, I wasn’t able to think of a way to break PPL using the physical mapping primitive alone.
However, it’s not the Project Zero way to leave any mitigation unbroken. So, having exhausted my search for design flaws, I returned to the ever-faithful technique of memory corruption. Sure enough, decompiling a few PPL functions in IDA was sufficient to find some memory corruption.
A survey of recent iOS kernel exploits
https://googleprojectzero.blogspot.com/2020/06/a-survey-of-recent-ios-kernel-exploits.html [googleprojectzero.blogspot.com]
2020-06-12 00:44
tags:
exploit
iphone
links
reference
security
I recently found myself wishing for a single online reference providing a brief summary of the high-level exploit flow of every public iOS kernel exploit in recent years; since no such document existed, I decided to create it here.
This post summarizes original iOS kernel exploits from local app context targeting iOS 10 through iOS 13, focusing on the high-level exploit flow from the initial primitive granted by the vulnerability to kernel read/write. At the end of this post, we will briefly look at iOS kernel exploit mitigations (in both hardware and software) and how they map onto the techniques used in the exploits.
Escaping the Chrome Sandbox with RIDL
https://googleprojectzero.blogspot.com/2020/02/escaping-chrome-sandbox-with-ridl.html [googleprojectzero.blogspot.com]
2020-02-15 23:49
tags:
browser
cpu
exploit
programming
security
sidechannel
systems
Vulnerabilities that leak cross process memory can be exploited to escape the Chrome sandbox. An attacker is still required to compromise the renderer prior to mounting this attack. To protect against attacks on affected CPUs make sure your microcode is up to date and disable hyper-threading (HT).
This is a pretty clear write-up and comes with a nice footnote:
When I started working on this I was surprised that it’s still exploitable even though the vulnerabilities have been public for a while. If you read guidance on the topic, they will usually talk about how these vulnerabilities have been mitigated if your OS is up to date with a note that you should disable hyper threading to protect yourself fully. The focus on mitigations certainly gave me a false sense that the vulnerabilities have been addressed and I think these articles could be more clear on the impact of leaving hyper threading enabled.
A very deep dive into iOS Exploit chains found in the wild
https://googleprojectzero.blogspot.com/2019/08/a-very-deep-dive-into-ios-exploit.html [googleprojectzero.blogspot.com]
2019-08-30 02:11
tags:
best
browser
exploit
investigation
iphone
malware
security
series
web
Earlier this year Google’s Threat Analysis Group (TAG) discovered a small collection of hacked websites. The hacked sites were being used in indiscriminate watering hole attacks against their visitors, using iPhone 0-day.
There was no target discrimination; simply visiting the hacked site was enough for the exploit server to attack your device, and if it was successful, install a monitoring implant. We estimate that these sites receive thousands of visitors per week.
TAG was able to collect five separate, complete and unique iPhone exploit chains, covering almost every version from iOS 10 through to the latest version of iOS 12. This indicated a group making a sustained effort to hack the users of iPhones in certain communities over a period of at least two years.
I’ll investigate what I assess to be the root causes of the vulnerabilities and discuss some insights we can gain into Apple’s software development lifecycle. The root causes I highlight here are not novel and are often overlooked: we’ll see cases of code which seems to have never worked, code that likely skipped QA or likely had little testing or review before being shipped to users.
Down the Rabbit-Hole...
https://googleprojectzero.blogspot.com/2019/08/down-rabbit-hole.html [googleprojectzero.blogspot.com]
2019-08-13 19:47
tags:
auth
exploit
fuzzing
investigation
programming
security
windows
I often find it valuable to write simple test cases confirming things work the way I think they do. Sometimes I can’t explain the results, and getting to the bottom of those discrepancies can reveal new research opportunities. This is the story of one of those discrepancies; and the security rabbit-hole it led me down.
Any application, any user - even sandboxed processes - can connect to any CTF session. Clients are expected to report their thread id, process id and HWND, but there is no authentication involved and you can simply lie. Secondly, there is nothing stopping you pretending to be a CTF service and getting other applications - even privileged applications - to connect to you.
Even without bugs, the CTF protocol allows applications to exchange input and read each other’s content. However, there are a lot of protocol bugs that allow taking complete control of almost any other application.
https://github.com/taviso/ctftool
Regarding disclosure: https://bugs.chromium.org/p/project-zero/issues/detail?id=1859#c10
The Fully Remote Attack Surface of the iPhone
https://googleprojectzero.blogspot.com/2019/08/the-fully-remote-attack-surface-of.html [googleprojectzero.blogspot.com]
2019-08-08 00:55
tags:
exploit
iphone
networking
security
turtles
We investigated the remote attack surface of the iPhone, and reviewed SMS, MMS, VVM, Email and iMessage. Several tools which can be used to further test these attack surfaces were released. We reported a total of 10 vulnerabilities, all of which have since been fixed. The majority of vulnerabilities occurred in iMessage due to its broad and difficult to enumerate attack surface. Most of this attack surface is not part of normal use, and does not have any benefit to users. Visual Voicemail also had a large and unintuitive attack surface that likely led to a single serious vulnerability being reported in it. Overall, the number and severity of the remote vulnerabilities we found was substantial. Reducing the remote attack surface of the iPhone would likely improve its security.
Also: https://googleprojectzero.blogspot.com/2019/08/the-many-possibilities-of-cve-2019-8646.html
0day "In the Wild"
https://googleprojectzero.blogspot.com/p/0day.html [googleprojectzero.blogspot.com]
2019-05-17 00:04
tags:
malware
security
Project Zero’s team mission is to “make zero-day hard”, i.e. to make it more costly to discover and exploit security vulnerabilities. We primarily achieve this by performing our own security research, but at times we also study external instances of zero-day exploits that were discovered “in the wild”. These cases provide an interesting glimpse into real-world attacker behavior and capabilities, in a way that nicely augments the insights we gain from our own research.
Today, we’re sharing our tracking spreadsheet for publicly known cases of detected zero-day exploits, in the hope that this can be a useful community resource:
source: green
Trashing the Flow of Data
https://googleprojectzero.blogspot.com/2019/05/trashing-flow-of-data.html [googleprojectzero.blogspot.com]
2019-05-12 15:02
tags:
development
exploit
garbage-collection
javascript
jit
malloc
security
In this blog post I want to present crbug.com/944062, a vulnerability in Chrome’s JavaScript compiler TurboFan that was discovered independently by Samuel (saelo@) via fuzzing with fuzzilli, and by myself via manual code auditing. The bug was found in beta and was fixed before it made it into the stable release of Chrome, but I think it’s interesting for a few reasons and decided to write about it. The issue was in TurboFan’s handling of the Array.indexOf builtin and at first it looked like an info leak at best, so it was not clear that you can turn this into an arbitrary write primitive. Besides that, it’s an instance of a common bug pattern in JIT compilers: the code was making assumptions at compile time without inserting the corresponding runtime checks for these assumptions.
As has been shown many times before, often bugs that don’t seem exploitable at first can be turned into an arbitrary read/write. In this case in particular, triggering the garbage collector while our fake pointer was on the stack gave us a very strong exploitation primitive. The V8 team fixed the bug very quickly as usual. But more importantly, they’re planning to refactor the InferReceiverMaps function to prevent similar bugs in the future. When I noticed this function in the past, I was convinced that one of the callers will get it wrong and audited all the call sites. Back then I couldn’t find a vulnerability but a few months later I stumbled over this newly introduced code that didn’t add the right runtime checks. In hindsight, it would have been worthwhile to point out this dodgy API to the team even without vulnerabilities to show for.
Splitting atoms in XNU
https://googleprojectzero.blogspot.com/2019/04/splitting-atoms-in-xnu.html [googleprojectzero.blogspot.com]
2019-04-02 02:08
tags:
concurrency
cpu
exploit
iphone
malloc
security
systems
A locking bug in the XNU virtual memory subsystem allowed violation of the preconditions required for the correctness of an optimized virtual memory operation. This was abused to create shared memory where it wasn’t expected, allowing the creation of a time-of-check-time-of-use bug where one wouldn’t usually exist. This was exploited to cause a heap overflow in XPC, which was used to trigger the execution of a jump-oriented payload which chained together arbitrary function calls in an unsandboxed root process, even in the presence of Apple’s implementation of ARM’s latest Pointer Authentication Codes (PAC) hardware mitigation. The payload opened a privileged socket and sent the file descriptor back to the sandboxed process, where it was used to trigger a kernel heap overflow only reachable from outside the sandbox.
This is excellent work.
The Curious Case of Convexity Confusion
https://googleprojectzero.blogspot.com/2019/02/the-curious-case-of-convexity-confusion.html [googleprojectzero.blogspot.com]
2019-02-05 20:48
tags:
browser
exploit
graphics
math
programming
security
There are several things worth highlighting about this bug. Firstly, computational geometry is hard. Seriously. I have some experience with it and, while I can’t say I’m an expert I know that much at least. Handling all the special cases correctly is a pain, even without considering security issues. And doing it using floating point arithmetic might as well be impossible. If I was writing a graphics library, I would convert floats to fixed-point precision as soon as possible and wouldn’t trust anything computed based on floating-point arithmetic at all.
Secondly, the issue highlights the importance of doing variant analysis - I discovered it based on a public bug report and other people could have done the same.
Thirdly, it highlights the importance of defense-in-depth. The latest patch makes sure that drawing a concave path with convex path algorithms won’t result in memory corruption, which also addresses unknown variants of convexity issues. If this was implemented immediately after the initial report, Project Zero would now have one blog post less :-)
Examining Pointer Authentication on the iPhone XS
https://googleprojectzero.blogspot.com/2019/02/examining-pointer-authentication-on.html [googleprojectzero.blogspot.com]
2019-02-01 22:29
tags:
cpu
defense
hardware
investigation
iphone
security
Among the most exciting security features introduced with ARMv8.3-A is Pointer Authentication, a feature where the upper bits of a pointer are used to store a Pointer Authentication Code (PAC), which is essentially a cryptographic signature on the pointer value and some additional context. Special instructions have been introduced to add an authentication code to a pointer and to verify an authenticated pointer’s PAC and restore the original pointer value. This gives the system a way to make cryptographically strong guarantees about the likelihood that certain pointers have been tampered with by attackers, which offers the possibility of greatly improving application security.
Despite these flaws, PAC remains a solid and worthwhile mitigation. Apple’s hardening of PAC in the A12 SoC, which was clearly designed to protect against kernel attackers with read/write, meant that I did not find a systematic break in the design and had to rely on signing gadgets, which are easy to patch via software. As with any complex new mitigation, loopholes are not uncommon in the first few iterations. However, given the fragility of the current bypass technique (relying on, among other things, the single IOUserClient class that allows us to overwrite its IOExternalTrap, one of a very small number of usable PACIZA gadgets, and a handful of non-PAC’d JOP gadgets introduced by obfuscation), I believe it’s possible for Apple to harden their implementation to the point that strong forgery bypasses become rare.
Taking a page from the kernel's book: A TLB issue in mremap()
https://googleprojectzero.blogspot.com/2019/01/taking-page-from-kernels-book-tlb-issue.html [googleprojectzero.blogspot.com]
2019-01-17 21:33
tags:
concurrency
exploit
linux
malloc
security
systems
This is a technical blog post about TLB flushing bugs in kernels, intended for people interested in kernel security and memory management.
Searching statically-linked vulnerable library functions in executable code
https://googleprojectzero.blogspot.com/2018/12/searching-statically-linked-vulnerable.html [googleprojectzero.blogspot.com]
2018-12-18 23:09
tags:
defense
hash
investigation
security
Software supply chains are increasingly complicated, and it can be hard to detect statically-linked copies of vulnerable third-party libraries in executables. This blog post discusses the technical details of an Apache-licensed open-source library to detect code from other open-source libraries in executables, along with some real-world findings of forked open-source libraries in real-world software.
A cache invalidation bug in Linux memory management
https://googleprojectzero.blogspot.com/2018/09/a-cache-invalidation-bug-in-linux.html [googleprojectzero.blogspot.com]
2018-09-26 19:10
tags:
concurrency
exploit
linux
malloc
security
This blogpost describes a way to exploit a Linux kernel bug (CVE-2018-17182) that exists since kernel version 3.16. While the bug itself is in code that is reachable even from relatively strongly sandboxed contexts, this blogpost only describes a way to exploit it in environments that use Linux kernels that haven’t been configured for increased security (specifically, Ubuntu 18.04 with kernel linux-image-4.15.0-34-generic at version 4.15.0-34.37). This demonstrates how the kernel configuration can have a big impact on the difficulty of exploiting a kernel bug.
The bug was fixed by changing the sequence numbers to 64 bits, thereby making an overflow infeasible, and removing the overflow handling logic.
The miracle cure for all your overflow ailments, the bigger int.
The policy of only printing a warning even when the kernel has discovered a memory corruption is problematic for systems that should kernel panic when the kernel notices security-relevant events like kernel memory corruption.
That does seem problematic.