Elektrine
Log in Register
Paige Chat Timeline Gallery Friends Email Drive DNS Private DNS Domains VPN Kairo Nerve
Remote

Shravan Ravi Narayan

@shravanrn@infosec.exchange
mastodon 4.8.0-alpha.3+glitch
  • Open on infosec.exchange

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

129 Followers
267 Following
4 Posts
Joined November 27, 2022
Webpage:
https://shravanrn.com
Open post
Shravan Ravi Narayan @shravanrn@infosec.exchange
· 2mo ago

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).

usenix.org
19
4
11
0
Open post
Shravan Ravi Narayan @shravanrn@infosec.exchange
· 2mo ago
Replying to

@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

0-days In-the-Wild

CVE-2019-11707: IonMonkey Type Confusion in Array.Pop

Information about 0-days exploited in-the-wild!

1
0
0
0
Open post
Shravan Ravi Narayan @shravanrn@infosec.exchange
· 2mo ago

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).
usenix.org
0
0
0
0
Open post
Shravan Ravi Narayan @shravanrn@infosec.exchange
· 2mo ago
Replying to
@tris@chaos.social oh good point! In general, we're happy to work with folks to get Mohabi integrated if there is interest (I may look into the specific gjs integration effort on my side out of interest). @hovav@infosec.exchange
0
0
0
0
Back
313k7r1n3
Elektrine

Tor hidden service

elekhj7afj4qnrr4yd3bkzslsyo5jgfxw3orgjkhlcxifueodybyiiad.onion

I2P eepsite

j6b6cyk6gjmepjih7jjadxgxvvf3lzzujljuu2v4biemzpg3naya.b32.i2p

Platform

  • Email
  • Chat
  • Timeline
  • VPN
  • DNS

Company

  • About
  • Contact
  • FAQ
  • Lite (no JS)

Legal

  • Terms of Service
  • Privacy Policy
  • Transparency Report
  • Report Abuse
  • Warrant Canary
  • VPN Policy

Support

  • support@elektrine.com
  • Report Security Issue
Mail client setup IMAP mail.elektrine.com:993 POP3 mail.elektrine.com:995 SMTP mail.elektrine.com:465
© 2026 Elektrine. All rights reserved. Server: 09:40:09 UTC