What happens when developers accidentally pick a predictable source of randomness, and that source happens to be significantly weaker than reasonable

Far From Random: Three Mistakes From Dart/Flutter's Weak PRNG

submited by

Style Pass

2024-12-12 00:00:09

What happens when developers accidentally pick a predictable source of randomness, and that source happens to be significantly weaker than reasonable developers would expect? These are the stories of how some popular projects all got burned by the same underlying weakness in the Dart/Flutter ecosystem and how the projects were affected. The mistake is prevalent in many open-source projects, but we will highlight just a few of them here.

When you want to create an interactive application that runs on mobile, web, and desktop alike, and all in the same codebase, Flutter↗ is a popular choice. It allows users to write performant applications that give similar user experiences on every supported platform. Flutter is powered by Dart↗ , which can compile the code to ARM machine code for both iOS and Android, JavaScript/WebAssembly for browsers, and x64/ARM for desktop devices. It also features some nifty functionality like “stateful hot reload”, which allows users to change the code and instantly see the results of the change without restarting their entire application.

In order to run similarly on many platforms, Dart code runs in a virtual machine called the Dart VM. The VM comes with multiple built-in libraries that handle OS-specific operations like interacting with files and resources, rendering graphics, doing math operations, and also generating randomness. The platform-specific implementation of these libraries may have differences in exactly how they accomplish their tasks. For instance, platforms that have built-in randomness sources might use those for their CSPRNG and ask the Dart isolate (the main process) for an initial random seed for the insecure PRNG. And then there’s Wasm, that straight up hardcoded the initial seed↗ until September 2024.