| Tweets |
|
Ian Beer
@i41nbeer
|
Aug 29 |
|
We’ll look at how the attackers modify their exploitation techniques over time to defeat new mitigations, and investigate the capabilities of the attacker’s implant to access personal information on the exploited devices.
|
||
|
|
||
|
Ian Beer
@i41nbeer
|
Aug 29 |
|
It covers every vulnerability in detail, including root cause analysis, what steps could have been taken to prevent the bugs, and what steps should be taken to ensure they don’t happen again.
|
||
|
|
||
|
Ian Beer
@i41nbeer
|
Aug 29 |
|
googleprojectzero.blogspot.com/2019/08/a-very… thanks to @_clem1, @5aelo for their joint work on this. This has been a huge effort to pull apart and document almost every byte of a multi-year in-the-wild exploitation campaign, which used 14 different iOS exploits.
|
||
|
|
||
|
Ian Beer
@i41nbeer
|
27 Dec 18 |
|
hello #35C3
|
||
|
|
||
|
Ian Beer
@i41nbeer
|
18 Oct 18 |
|
A blog post about turning back the clock to 2014, and thinking about what 2022 might be like: googleprojectzero.blogspot.com/2018/10/deja-x…
|
||
|
|
||
|
Ian Beer
@i41nbeer
|
19 Sep 18 |
|
And if you're using the mptcp/vfs exploits for security research (eg with Electra 11.3.1) you should just keep using that. I'll release the 11.4.1 exploits I have but the focus will shift to iOS 12 now :)
|
||
|
|
||
|
Ian Beer
@i41nbeer
|
19 Sep 18 |
|
The iOS 12 security bulletin seems to only include iOS-only bugs this time (as opposed to those which affect iOS *and* MacOS.) There are far more fixes in iOS 12 than are mentioned, including a nasty logic bug to break you out of the app sandbox. Update your personal devices!
|
||
|
|
||
|
Ian Beer
@i41nbeer
|
18 Sep 18 |
|
The 0x3771 seems to be the type signature used as the upper 16 bits of context value for virtual call BLRAA (with the lower 48 being the fptr’s address?)
|
||
|
|
||
|
Ian Beer
@i41nbeer
|
9 Aug 18 |
|
Here are the slide from my #blackhat talk yesterday: docs.google.com/presentation/d… Please expand the speaker notes if you read it!
|
||
|
|
||
|
Ian Beer
@i41nbeer
|
8 Aug 18 |
|
I'd love to get a chance to sit down with you and discuss how together we can make iOS even more secure for all our users. Cheers, Ian Beer.
|
||
|
|
||
|
Ian Beer
@i41nbeer
|
8 Aug 18 |
|
Hi @tim_cook, I've been working for years to help make iOS more secure. Here's a list of all the bugs I reported which qualified for your bug bounty since its launch, could you invite me to the program so we can donate this money to @amnesty? pic.twitter.com/VUKj7BaJ4P
|
||
|
|
||
|
Ian Beer
@i41nbeer
|
24 Jul 18 |
|
Please read README_KDP before trying to use this. There are many limitations, but I have found it useful for vulnerability research nevertheless.
|
||
|
|
||
|
Ian Beer
@i41nbeer
|
24 Jul 18 |
|
Here's an updated version of async_wake with a more usable KDP-based kernel debugger: bugs.chromium.org/p/project-zero…
|
||
|
|
||
|
Ian Beer
@i41nbeer
|
29 Jun 18 |
|
Slides from my #MOSEC2018 talk "build your own iOS kernel debugger": bugs.chromium.org/p/project-zero…
|
||
|
|
||
|
Ian Beer
@i41nbeer
|
17 Jun 18 |
|
Fixing that in combination with enabling 20 spinner threads seems to show reliability closer to 50% in some very unscientific testing, but I'm sure there are still plenty of bugs. @Externalist's writeup had plenty more good ideas for improving reliability.
|
||
|
|
||
|
Ian Beer
@i41nbeer
|
17 Jun 18 |
|
credit to @Externalist for spotting a bug in empty_list: on devices with 16k pages there are 0x61 ipc_port allocations per zone refill (not sure where 0xe0 came from...); so it should look like this: int ports_per_zcram = kernel_page_size == 0x1000 ? 0x49 : 0x61;
|
||
|
|
||
|
Ian Beer
@i41nbeer
|
17 Jun 18 |
|
I’ll take a closer look tonight on some 16k page devices; maybe they don’t actually take 16k per port zcram. Will post the results and some example code showing how you can find out.
|
||
|
|
||
|
Ian Beer
@i41nbeer
|
16 Jun 18 |
|
struct ipc_kmsg is a header for a variable sized structure; I explain it here: googleprojectzero.blogspot.com/2017/04/except… that's why it looks like I'm reading off the end of it; the mach message body is actually aligned to the end of the allocation.
|
||
|
|
||
|
Ian Beer
@i41nbeer
|
16 Jun 18 |
|
This probably has a few consequences, not least that the region of ports within which it searches for the corruption is likely shifted so the corruption might succeed but it'll keep going, eventually panicking.
|
||
|
|
||
|
Ian Beer
@i41nbeer
|
16 Jun 18 |
|
super writeup! I think you found a bug in my exploit :) You're right that ports_per_zcram shouldn't be 0xe0 on 16k devices. On 16k page devices an ipc_ports zcram will use 1 16k page, so ports_per_zcram should be 0x61.
|
||
|
|
||