CVE-2022-25664 is one of the most interesting bug I've reported. It's "only" an info leak, but a very powerful one that allows an untrusted Android app to read pages of memory from the kernel or other apps any number of times.
In this post I'll use CVE-2022-38181, a use-after-free I reported last year in the Arm Mali GPU driver to gain arbitrary kernel code execution and root from untrusted Android app. Not sure if the bug or the disclosure is more interesting:
file: "mali_app/app/src/main/cpp/hello-jni.c": 4b66a16931b96fdf14a32aa9963c25326a2a8b217e7a842d886d5885ef01956d
The email I sent: 234646839712e54fb7179ab74ddeb6bb8857d9bd853b29be2596fdb21d22a4c7 (Plain text starts from "Hi" and ends with "Mo") Thanks!
security is reading this, please reply to my email on 5 Aug about a bug report that Android security team shared with you privately, thanks. SHA256 of various files for verification (next tweets)
This might be the best bug I found. Never thought I'd be writing a kernel exploit as reliable, clean and fast as a browser exploit. For a while I actually used this to root my research phone when can't be bothered to patch the rom:
goes through the details of CVE-2022-1134, a type confusion in Chrome, and shows how to gain remote code execution in the Chrome renderer using this bug.
This is probably the most complex exploit I've done so far. A UAF in Android kernel freed by kfree_rcu (introduces a delay) in a tight race + kCFI + Samsung RKP. Yet its still possible to gain arbitrary kernel RW, disable SE and root from untrusted app.
In this post I'll go through 3 bugs in the Qualcomm NPU driver that I reported, which allowed me to execute arbitrary kernel code from the untrusted app domain in Android, disable SELinux and bypass task cred protection to gain root on a Samsung phone:
dug his way out of the Chrome sandbox using a credit card as a shovel! "The fugitive in Java: Escaping to Java to escape the Chrome sandbox" https://github.co/3AY6Uw6
In the last part of the Chrome beta + Android full chain series, I'll use a Chrome WebAudio UAF I reported last September (which turned out to be a bug collision) to gain RCE in the renderer sandbox.
In this second part of the Chrome beta + Android full chain series, I'll use a sandbox escape in the beta version of Chrome v86 that I reported last September to gain App privilege from the Chrome renderer sandbox:
popped some fresh Android kernels for you to enjoy! "One day short of a full chain: Part 1 - Android Kernel arbitrary code execution" https://github.co/2On97xT
In this series of posts I'll exploit 3 bugs that I reported last year. Together they can form a full chain from Chrome beta v86 to the Android kernel. The first post is about exploiting a UAF in the kernel reachable from the App sandbox:
managed to actually exploit that Chrome WebAudio Use After Free he found back in March? 🎃 Mo shares his tricks and treats us with his latest post on Chrome UAF exploitation 👻https://github.co/3msMoMy
In this post I give details about how to create an exploit for the type confusion vulnerability (CVE-2018-19134) of Ghostscript and turn it into a RCE. I have to say PostScript is not my prefer language for writing exploit. https://lgtm.com/blog/ghostscript_CVE-2018-19134_exploit…
This post gives the details of some type confusions (CVE-2018-19134,19475-76) that I found in Ghostscript after studying reports of similar issues filed by
found in the last few months and ended up finding another -dSAFER bypass RCE, plus some type confusions, one of which is also a proper RCE. All patched in 9.26. Write ups coming soon.
In this post on Struts' OGNL injection vulnerabilities I'll go through a type of RCE issue called "double evaluation". There are a number of new issues, although no CVE as Struts did not think it's their responsibility. https://lgtm.com/blog/apache_struts_double_evaluations…
For people looking into intrusion detection of CVE-2018-11776. From what is available in public, it should be clear that the attack is done via a url with ognl. So look for url that contains ognl. An exploit won't tell you more than that.
Struts users should take the advice of the Struts team to upgrade:
https://cwiki.apache.org/confluence/display/WW/S2-057…
the new versions are backward compatible and they don't just patched CVE-2018-11776 but also include general security improvements to make life harder for hackers.
As some people have asked about exploits of CVE-2018-11776. I don't plan to release it at the moment so that users can have time to upgrade, I would also like to urge others to refrain from releasing exploits just yet.
Interested in how we approach security research and disclosing #0days? We now have a page detailing our official vulnerability disclosure policy, and detailing how we use QL to discover them in the first place: https://lgtm.com/security#vulnerabilities#SecurityResearch
Thanks to the hard work of the Java team, (Anders Schack-Mulligen in particular), the 'Deserialization of user-controlled data' query in http://lgtm.com now catches Struts' CVE-2017-9805 with great precision!