TLBleed in the news

We have shared TLBleed with several operating system projects, in order for them to be able to implement mitigations if desired. As a result of seeing TLBleed, OpenBSD decided to disable /msg99141.html">Hyperthreading by default. This has prompted some speculation that TLBleed is a spectre-like attack, but that is not the case. OpenBSD also realizes the exact impact of TLBleed. There has been significant news coverage: TheRegister (and this one), ArsTechnica, bleepingcomputer, ZDnet, Techrepublic, TechTarget, ITwire, tweakers, and a personal favorite, the SecurityNow Podcast episode 669 (mp3, show notes, youtube).

The full paper will be online soon.

GLitch hits the news

GLitch, our JS-based Rowhammer exploit that takes advantage of GPU acceleration to trigger bit flips and get control over the Firefox browser on Android made it to the news. After respecting the 90 days disclosure policy we finally went live on May 3 releasing all the details of our attack.

The research got quite some interest from the security community on Twitter and it got covered in two detailed articles on Wired and ArsTechnica. After this, it got picked up by other news outlets such as DecipherTweakers, The Hacker News and others.

While the great interest for the research people did not really like the demo video. The reason is attributed to the background music.
Oh well… ¯\_(ツ)_/¯

VUSec: Election software very vulnerable

We analyzed the election software that is used, and has been used for years, in all Dutch elections. Our conclusion: this software is very vulnerable.

On the 13th of March, Herbert Bos appeared on RTL Nieuws to summarize these findings. He is on briefly after 7 seconds, and then again at 3m17s (also with Sebastian, Marco and Sanjay, who did the heavy lifting for the analysis, together with Andrei).

Surprisingly, Minister Ollongren does not think there is a problem, even though we show vulnerabilities as bad as integer overflows that allow attackers to manipulate overall results even from compromised local polling stations.

The news broadcast, our analysis, and the independent analysis by Sijmen Ruwhof, did lead to questions from the parliament, and some members of parliament explicitly echoed Herbert’s analysis.  The issue was also reported in most newspapers and on Tweakers.

Technical report: Benchmarking Crimes: An Emerging Threat in Systems Security

Or: if you can’t do the time, don’t do the crime

Several days ago, we released a technical report entitled Benchmarking Crimes: An Emerging Threat in Systems Security.  The paper was intended for publication at a security conference but was rejected at multiple venues. To let our work be a supporting piece of evidence and analysis for the community to build on, we share our work with the community as a technical report, and we publish it on

The results are as revealing as they are damning: we formulate 22 different benchmarking crimes, each of which violates the results of a benchmark in a minor or major fashion. We survey 50 different systems security defense papers. We include papers published by this group in that selection. To gauge reliability, the survey is performed twice – we let two independent readers perform this survey. Their findings are consistent: in this wide study of  accepted papers at top systems security venues, all papers had committed benchmarking crimes in some number and degree of egregiousness.

Most of these are recent papers (2015), but a significant fraction are from 2010. This longitudinal component of the study tells us that not only are benchmarking crimes widespread, but also no better in modern papers than in older ones.

This raises the question of how we can trust benchmarks in research results. We hope our work will contribute to an improvement in this situation.

The Register has coverage.

Systems and Network Security Group at VU Amsterdam