Today, I am disclosing a 0-day vulnerability that bypasses the patch for CVE-2024-34331. I have identified two distinct methods to circumvent the fix. Both bypasses were reported separately to the Zero Day Initiative (ZDI) and the affected vendor Parallels. Unfortunately, their responses have been deeply unsatisfactory.

This is a blog post for my presentation at the conference OBTS v7.0. The slides are uploaded here.

Happy New Year!

This is a blog post for my presentation at the conference POC2024. The slides are uploaded here.

Starting with macOS Sonoma 14.0, Apple has introduced a new TCC category kTCCServiceSystemPolicyAppData to protect the App Container Data. This is designed to address one of my reports (aka CVE-2023-42929):

About two weeks ago, Apple published the CVE-2023-42942 in the security advisory. It was a race condition issue existed in the system service xpcroleaccountd, and it could be exploited for root privilege escalation. Today, I am going to share the details.

Last year, I discovered a full user TCC bypass issue in the macOS Sonoma beta version. There was a CVE number assigned at the beginning, but removed by Apple in the release of macOS 14.0. Instead, I got the credit in their Additional Recognitions.

This blog post is written for my talk at OBTS v6.0.

A year ago, I discovered a TCC-bypass issue in the system daemon service named com.apple.fontmover. Three months later, Apple addressed it as CVE-2022-32902. After checking how Apple addressed the issue, I found two new issues introduced by patching the issue. I reported them to Apple immediately and waited for about 9 months.

A few weeks ago, Rich Trouton noticed a new change in the latest macOS release: macOS Ventura 13.3 alters expected behavior for Finder’s Open With functionality for macOS installer packages. In this post, I want to share a simple LPE vulnerability associated with it and why Apple made the change.

I found some new attack surfaces in the macOS PackageKit.framework, and successfully disclosed 15+ critical SIP-Bypass vulnerabilities. Apple has addressed 12 of them with CVE assigned so far. There are still some reports in the Apple’s processing queue. All of them are interesting logic issues, and of course each has a successful exploit demonstration.

In this writeup, I will introduce a very simple method to bypass GateKeeper , and uncover the root cause through reversing and debugging. Apple had already addressed it as CVE-2022-22616 in macOS Monterey 12.3, and credited the bug to two Jamf researchers (@malwarezoo, @jbradley89) and me. So, make sure you have updated your Mac devices to the latest version.

As well known, iOS14.8 patched two 0 days in the wild, one of which is the pegasus 0-click vulnerability. You can get the root cause and more interesting findings by reading my analysis from here.

Last year, I used the BinDiff plugin normally inside the IDA Pro, but I got a crash due to the plugin issue. Then a dialog prompted and I choosed to Let IDA Continue, then I got another weird crash. Yes, 2 different issues from BinDiff plugin & IDA Pro, just triggered by a bindiff file. Driven by my curiosity, I tried to find the root cause and got this CVE here :

​ 现在许多高效的 fuzz 引擎（AFL，honggfuzz，syzkaller等）都会收集语料执行时的代码覆盖率，并以此为反馈来指导变异和 fuzz 策略。对于开源的项目，通过设置编译选项，编译器就会自动帮忙插桩了。但是对于闭源的二进制文件，问题就显得比较棘手了。当前主流的做法大多还是 DBI （运行时动态插桩，如 Dynamorio，frida stalker 等）。而与此相对的就是SBI （静态插桩）了。毫无疑问，静态插桩几乎可以获得和编译器插桩一样的执行效率，可以把编译器插桩看成是 SBI 的一个特例。但是目前已有的一些 SBI 方案没有大量运用普及，大都有各自的局限性。

My team and I posted the details of the brand new Mac Malware XCSSET last year [1] [2], and disclosed the interesting 0 day tricks used inside. All the XCSSET payload modules were reviewed carefully. However, I was a newbie for hunting macOS vulnerability and I didn’t realize the TCC bypass is a vulnerability at that time until Jamf posted their new blog and detailed the 3rd 0 day used by XCSSET.

As mentioned in my last blog, I can launch any decrypted iOS App on M1 Mac with free developer certificate. Here, I will try to install the decrypted IPA dircectly without re-signing.

Besides the method in my last blog, I keep trying other methods to run the decrypted iOS App. Then I thought of the Xcode Simulator, which had no possibility to run the real iOS Apps before, due to the x86_64 platform restriction. But now, the Simulator from M1 Mac is also the arm64 architecture. Is it possible to run the decrypted iOS App in the simulator now ?

We have no permission to attach the lldb to any other iOS Apps on the M1 Mac, when SIP is enabled. But we couldn’t launch the iOS Apps if SIP is disabled. It seems that fairplayd has a check for the system boot policy security mode and refuses to decrypt the iOS App macho when SIP is disabled.