Shravan Ravi Narayan

120 Followers
222 Following
74 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

Webpagehttps://shravanrn.com
Unfaithful Claims: Breaking 6 zkVMs

A zkVM verifier should be faithful to one thing above all else: its public claims. Yet we found six systems where this guarantee breaks. Learn how a subtle ordering bug lets an attacker bypass the cryptography entirely and prove mathematically impossible statements.

OtterSec

I've been seeing a lot of comments online about how browser telemetry is just a way to spy on users and we never actually use it, and it provides no value.

We can debate whether you think someone (Firefox or otherwise) overcollects telemetry, or doesn't collect it in a privacy-preserving enough way. And you should be able to turn it all off, for any reason.

But it's been instrumental for me, personally, to ship multiple security improvements to Firefox - and I'm just one of hundreds of developers. I wrote up some more here: https://ritter.vg/blog-telemetry.html

telemetry helps. you still get to turn it off - ritter.vg

Tom Ritter's personal homepage, where he rambles about tech-related topics.

A few years ago I designed a way to detect bit-flips in Firefox crash reports and last year we deployed an actual memory tester that runs on user machines after the browser crashes. Today I was looking at the data that comes out of these tests and now I'm 100% positive that the heuristic is sound and a lot of the crashes we see are from users with bad memory or similarly flaky hardware. Here's a few numbers to give you an idea of how large the problem is. đź§µ 1/5

I'm looking forward to presenting my paper, "Continuous User Behavior Monitoring using DNS Cache Timing Attacks" at NDSS next week!
We mount an Evict+Reload-style attack on the local DNS cache, detecting recently accessed domains and evicting to continuously monitor new accesses.

Our attack works from native code, even across virtual machines and containers.
We also run the attack in the browser from a malicious website, using JavaScript or even scriptless HTML+CSS.
Most underlying primitives are OS-agnostic!

Read the paper here: https://hannesweissteiner.com/publications/dmt/

Thanks to Roland Czerny, @silent_bits, @notbobbytables , Johanna Ullrich and @lavados for the amazing collaboration!

Continuous User Behavior Monitoring using DNS Cache Timing Attacks

I am a PhD Student in CoreSec at ISEC at Graz University of Technology as part of the CoreSec group. My research area is side-channel attacks and defenses.

A new piece of research as part of my group's safe and formally verified numerics project that I am really excited about -- The FLoPS framework, which formalizes the upcoming P3109 standard in Lean. Great work by my PhD students: Tung-Che Chang and Sehyeok Park and collaborator Jay Lim from University of California, Riverside.

The upcoming IEEE-P3109 standard for low-precision floating-point arithmetic can become the foundation of future machine learning hardware and software. Unlike the fixed types of IEEE-754, P3109 introduces a parametric framework defined by bitwidth, precision, signedness, and domain. This flexibility results in a vast combinatorial space of formats -- some with as little as one bit of precision -- alongside novel features such as stochastic rounding and saturation arithmetic.

We have formalized the P3109 standard and discovered new interesting properties of foundational algorithms such as Fast2Sum, Sternbenz, and a floating-point splitting ExtractScalar in the context of P3109.

During this process, we discovered some errors in the draft standard and reported it to the working group (I am member of the P3109 working group). They have been fixed.

See the Github repo of our mechanized proofs in Lean: https://github.com/rutgers-apl/flops

See our technical report:
https://arxiv.org/pdf/2602.15965

On a side note, I was convincingly persuaded to explore Lean by Ilya Sergey when I visited NUS in August 2024. Thanks Ilya for making a compelling case for using Lean while Umang Mathur and Abhik Roychoudhury made the visit possible.

#RutgersCS #RAPL #P3109

Happy to share that our work analyzing the performance of ARM Memory tagging extensions on real hardware has been accepted at USENIX Security 2026. We look at the performance of MTE on Pixel 8, Pixel 9, AmpereOne CPUs, and even have some preliminary analysis of MTE performance on the Mac M5. This covers MTE on phones, laptops, and server chips.

Context: Memory safety bugs represent the majority (50% to 70%) of bugs in systems like Chrome, Windows etc. ARM's memory tagging is a hardware feature that can be used to probabilistically detect memory safety bugs. Unfortunately, most discussions of MTE's performance overhead so far have been vague. Since MTE is now available in a handful of devices we decided to take a look!

Highlights
----------------
- Performance overheads of MTE can vary widely according to micro-architecture and benchmark.
- SYNC MTE can indeed be implemented efficiently as shown by the implementation on the AmpereOne, Mac M5, and Pixel's Little core. But micro-architectural details can lead to large overheads on specific benchmarks. E.g.: Causes a factor of 2x to 6x on Pixel's performance core, 1.8x on Pixel's big core, 1.43x on AmpereOne cores, and 1.29x on Mac M5 cores. Interestingly, on receiving our report, Ampere noted they had also discovered this internally and have fixed this in future chips.
- ASYNC MTE is faster than SYNC MTE and imposes very low overheads on Pixel's Performance and Little core. However, counter to conventional wisdom, subtle micro-architectural issues can compromise in ASYNC MTE's performance on specific workloads and micro-architectures - E.g., 1.8x on Pixel's big core.
- MTE's runtime support matters! The Linux kernel's support for MTE sometimes resulted in 25% throughput drop on Memcached on AmpereOne chips due to an assumption made based on an ambiguous part of the ARM MTE specification. We submitted a patch for this to the Linux kernel mailing list which eliminates almost all of the overhead on this benchmark.
- Prior academic work tested MTE using performance analogs. This was reasonable since MTE hardware has only been available recently. Unfortunately, we see that the analogs don't reflect real world performance. Further, assumptions of MTE performance from prior work on real devices are at best, incomplete (and at worst: wrong) due to testing on a single MTE micro-architecture or in some cases: benchmarking bugs.
- Finally, for use cases beyond enforcing memory safety, the first generation of MTE implementations has mixed results. Data tracing and copy elision can use MTE for speedups today, while CFI and SFI (in-process sandboxing) don't yet show clear performance with today's MTE implementations.

I suspect USENIX will have the papers up soon, but in case you want to look through the specific details, a copy of the paper is available here.
https://shravanrn.com/pubs/mte-extended

Kudos to the whole team and especially to Taehyun for driving this work!

Team: Taehyun Noh (@taehyun), Yingchen Wang, Tal Garfinkel (https://www.linkedin.com/in/tal-garfinkel-937528/), Mahesh Madhav(https://www.linkedin.com/in/mahesh-madhav/), Daniel Moghimi (@flowyroll), Mattan Erez(https://lph.ece.utexas.edu/merez/), Shravan Narayan (@shravanrn)

Also shout out to Mahesh Madhav and Carl Worth from Ampere for their help with Ampere infrastructure and identifying/testing kernel patches for MTE performance.

Who had "someone exploits HotCRP to download CCS submissions" on their 2026 bingo card?

Hi everyone! I'm excited to announce that my first first-author paper has been accepted at NDSS 2026 🥳, to be held at San Diego, California, USA. If you're attending #NDSS2026 this year and are working on systems security, let me know - it'd be awesome to meet up!

Eviction Notice: Reviving and Advancing Page Cache Attacks

@vmcall, Jonas Juffinger, Lukas Maar, @lavados

all of us from @isec_tugraz, at TU Graz, Austria.

In the paper, we revive practical attacks on the Linux page cache and also provide a systematic classification & understanding of primitives which interact with page cache. This understanding helps us advance page cache attacks, including speeding up previously known mechanisms by six orders of magnitude.

I have a small technical write up on my website if you're interested to check it out: https://snee.la/posts/eviction-notice/

Paper available here: https://snee.la/pdf/pubs/eviction-notice.pdf

Our artifacts have been evaluated to be available, functional, and reproducible, so feel free to try the code out on your Linux box: https://github.com/isec-tugraz/Eviction-Notice

Eviction Notice: Reviving and Advancing Page Cache Attacks

Foreword This blog post is a summarized and introductory write up of our paper recently accepted at NDSS 2026, “Eviction Notice: Reviving and Advancing Page Cache Attacks”. Read the full paper here. Authors: Sudheendra Raghav Neela, Jonas Juffinger, Lukas Maar, Daniel Gruss Artifacts: Github Repository, Zenodo Record (Available, Functional, and Reproducible) CVE-2025-21691: Announcement, Red Hat, NVD NIST, Debian Tracker, Suse. Introduction An operating system deals with pages, the smallest region of memory in a system using virtual memory1.

This is a wild hack. a16z gave a million dollars to startup called Doublespeed. They use a phone farm to flood social media with AI generated influencers and ads. A hacker remotely broke into the phone farm, unmasking the AI influencers/fake accounts, gave us the data https://www.404media.co/hack-reveals-the-a16z-backed-phone-farm-flooding-tiktok-with-ai-influencers/
Hack Reveals the a16z-Backed Phone Farm Flooding TikTok With AI Influencers

A hacker gained control of a 1,100 mobile phone farm powering covert, AI-generated ads on TikTok.

404 Media

@mgorny expat is sandboxed with RLBox security framework and WebAssembly. So Firefox would not be affected by any vulnerabilities due to use of an older version

https://blog.mozilla.org/attack-and-defense/2021/12/06/webassembly-and-back-again-fine-grained-sandboxing-in-firefox-95/

(This sandboxing is applied on all OSes)

FYI, @glandium @tomrittervg

WebAssembly and Back Again: Fine-Grained Sandboxing in Firefox 95 – Attack & Defense (Archive)

In Firefox 95, we're shipping a novel sandboxing technology called RLBox — developed in collaboration with researchers at the University of California San Diego and the University of Texas — ...

Attack & Defense (Archive)