Common desktop apps’ flaws patched at Black Hat

Security researchers gathering at the Black Hat conference held this week in Las Vegas have presented their findings which showed significant security problems in the Electron framework.

This software facility allows applications to run easily on different platforms. Electron encapsulates an application which runs on what’s effectively a limited web browser, allowing Electron-based apps to be distributed as binaries on Windows, Mac, Linux, and other operating systems.

So seamless is the process that many users are simply unaware that they are using an Electron-based app at all: Discord, Skype, Slack, and Teams, for example, are commonly run as Electron apps and are near-indistinguishable from their native versions.

However, flaws in the Electron “wrapper” discovered by researchers at Black Hat meant that hackers could have gained control over machines through users following links they are sent in the application – precisely the sort of interaction that users undertake while using Discord and Teams especially. In the case of the Teams vulnerability, for example, an invite to a meeting, when clicked, would have allowed the sender to take control over the victim’s entire machine.

Sometimes the only clue end-users have that they are running an Electron app is a difference in the look and feel of the application in question. For Mac users, in particular, the contrast can be pretty jarring. But there are few noticeable anomalies for PC and Linux users (and the more aesthetically-numbed Mac user) who are perhaps generally more used to seeing apps look a little rough around the edges, or at least, different from one another.

There has been criticism of Electron apps in the past, too, with regards to their size – due in part to the fact that Electron apps each bundle a fully-featured Chromium web rendering engine as part of the framework. Five Electron applications (say Netflix, Spotify, Slack, Gitter, and GMail) on modest hardware is the equivalent of storing and running five web browsers; a big ask on limited storage and memory.

But for developers, frameworks like Electron are attractive, as the facility brings teams one step closer to the dream of “write once, deploy many times.” Without such capabilities, developers would be forced to rewrite and recompile their applications for each platform in turn. Electron is a great way, therefore, of getting an application out to as many users as possible. Plus, Electron apps can be written in commonly-used languages like JavaScript and web markup like HTML and CSS. The barrier between writing complex web pages and standalone applications is, therefore, very narrow.

It’s often possible and arguably safer to run applications like Discord, Spotify, and Teams inside a bona fide web browser rather than as “apps” in Electron clothing. Safer, but, on the flip side, a web application can sometimes be “just another open tab,” among dozens of others. Standalone apps tend to, well, stand out better. There are, however, a greater number of security-conscious eyeballs on the common web browsers than on the Electron project. In recent years the Electron team has addressed many security-related problems, and it’s worth noting that the flaws discovered at Black Hat were closed before researchers released the findings reported here. So, if security risks bring you out in a cold sweat, run anything you can on a browser and avoid downloading binaries at all.

But if we resist the temptation to jump on the Electron-hating bandwagon, a greater uptake by developers of Electron as a framework would go a long way to ensuring it becomes more secure over time. More apps from more developers will mean more security oversight, in all probability. Then, a single security patch to Electron will by proxy update the security holes in several applications on users’ desktops.

The something-running-inside-something-else model of software is incredibly common, of course. Generations of Java programs running inside a Java Runtime Environment are a testament to that. While not inherently insecure, if the “outer layers” of the model are found to be insecure (as is the case here), the consequences spread to everything built using the same runtime environment, the “inner layers,” to continue the analogy.