Assistant Professor at UT Austin interested in building secure systems, security enforcement using PL techniques, and hardware-based security. Posts/boosts: cybersecurity, cs, tech, academia. #CyberSecurity #CyberSec #professor #academic #academia
Assistant Professor at UT Austin interested in building secure systems, security enforcement using PL techniques, and hardware-based security. Posts/boosts: cybersecurity, cs, tech, academia.
Posts
Assistant Professor at UT Austin interested in building secure systems, security enforcement using PL techniques, and hardware-based security. Posts/boosts: cybersecurity, cs, tech, academia. #CyberSecurity #CyberSec #professor #academic #academia
@simon@tutut.delire.party The issue is that in-the-wild attacks are able to construct exploit chains that first compromise the content process using JavaScript engine bugs and next escalate privileges by either
-
using a bug in the browser host process' communication interface, where a missing check allows a compromised content process (which is generally quite locked down) to compromise the host process (which has little/no restrictions) merely by passing it a bad message
-
using a bug in the OS kernel/drivers to directly get root
Here is one of many examples i quickly looked up from google project zero
https://googleprojectzero.github.io/0days-in-the-wild/0day-RCAs/2019/CVE-2019-11707.html
The easiest way to cut this is of is at step 1, i.e., isolate the effect of JavaScript engine bugs, so that step 2 is not possible
Assistant Professor at UT Austin interested in building secure systems, security enforcement using PL techniques, and hardware-based security. Posts/boosts: cybersecurity, cs, tech, academia. #CyberSecurity #CyberSec #professor #academic #academia
I attended USENIX OSDI 2026 last week to share our paper “Mohabi: Disaggregating and Sandboxing the Firefox JavaScript Engine” (available at https://www.usenix.org/system/files/osdi26-sharma.pdf)
The TLDR: Browsers have very complex JavaScript engines, and many recent attacks have targeted bugs in this complex JavaScript engine as the entry point to compromise users’ machines. In this paper, we built “Mohabi” — a fork of Firefox that uses in-process sandboxing to fully isolate the JavaScript engine at moderate cost. This means that in Mohabi, bugs in the JavaScript engine are no longer security bugs.
I could talk a lot about this research process we used in this paper — e.g., we weren’t just trying to get something that "kinda worked", we really wanted something that would be a scalable/maintainable as well as secure. It ended up taking us 2 years and many, many design iterations to find the design we were happy with that would meet these goals.
This has probably been one of the most technically challenging papers I have been involved in, and the students driving this work Abhishek Sharma, Anand Balaji, Zachary Yedidia, Anthony Du, and Taehyun Noh have done amazing work!
Team: Abhishek Sharma (@abhishekcs@infosec.exchange), Anand Balaji (@anand@discuss.systems), Zachary Yedidia (https://zyedidia.github.io/) Anthony Du, Taehyun Noh (@taehyun@infosec.exchange), Iain Ireland, Jan de Mooij (@jandem@mastodon.social), Matthew Gaudet (@mgaudet@discuss.systems), Tal Garfinkel (https://www.linkedin.com/in/tal-garfinkel-937528/) Deian Stefan (https://cseweb.ucsd.edu/~dstefan/) Hovav Shacham (@hovav@infosec.exchange), Shravan Narayan (@shravanrn@infosec.exchange)
Posted to Mastodon on Mohabi**
** Mohabi is a research prototype, and not meant for day to day use, but it is a fully functioning fork of Firefox ESR115 (the latest ESR when we started this work 2 years ago).
Assistant Professor at UT Austin interested in building secure systems, security enforcement using PL techniques, and hardware-based security. Posts/boosts: cybersecurity, cs, tech, academia. #CyberSecurity #CyberSec #professor #academic #academia
I attended USENIX OSDI 2026 last week to share our paper “Mohabi: Disaggregating and Sandboxing the Firefox JavaScript Engine” (available at https://www.usenix.org/system/files/osdi26-sharma.pdf)
The TLDR: Browsers have very complex JavaScript engines, and many recent attacks have targeted bugs in this complex JavaScript engine as the entry point to compromise users’ machines. In this paper, we built “Mohabi” — a fork of Firefox that uses in-process sandboxing to fully isolate the JavaScript engine at moderate cost. This means that in Mohabi, bugs in the JavaScript engine are no longer security bugs.
I could talk a lot about this research process we used in this paper — e.g., we weren’t just trying to get something that "kinda worked", we really wanted something that would be a scalable/maintainable as well as secure. It ended up taking us 2 years and many, many design iterations to find the design we were happy with that would meet these goals.
This has probably been one of the most technically challenging papers I have been involved in, and the students driving this work Abhishek Sharma, Anand Balaji, Zachary Yedidia, Anthony Du, and Taehyun Noh have done amazing work!
Team: Abhishek Sharma (@abhishekcs@infosec.exchange), Anand Balaji (@anand@infosec.exchange Balaji@discuss.systems), Zachary Yedidia (https://zyedidia.github.io/) Anthony Du, Taehyun Noh (@taehyun@infosec.exchange Noh), Iain Ireland, Jan de Mooij (@jandem@mastodon.social), Matthew Gaudet (@mgaudet@discuss.systems), Tal Garfinkel (https://www.linkedin.com/in/tal-garfinkel-937528/) Deian Stefan (https://cseweb.ucsd.edu/~dstefan/) Hovav Shacham (@hovav@infosec.exchange), Shravan Narayan (@shravanrn@infosec.exchange)
Toot was posted to Mastodon on Mohabi*
- Mohabi is a research prototype, and not meant for day to day use, but it is a fully functioning fork of Firefox ESR115 (the latest ESR when we started this work 2 years ago).