This Week In Security: Malicious Clipboards, Snakes On A Domain, And Binary Golf

September 2, 2022 by Jonathan Bennett 4 Comments

There’s a bit of a panic regarding Chromium, Google Chrome, the system clipboard, and of all things, Google Doodles on the New Tab Page. It’s all about Chromium issue 1334203, “NewTabPageDoodleShareDialogFocusTest.All test fails when user gesture is enforced”. You see, Chromium has quite a large regression test suite, and Google engineers want to ensure that the Google Doodles always work. A security feature added to the clipboard handling API happened to break a Doodles test, so to fix the Doodle, the security feature was partially reverted. The now-missing feature? Requiring user interaction before a page can read or write to the clipboard.

Now you understand why there’s been a bit of a panic — yes, that sounds really bad. Pages arbitrarily reading from your clipboard is downright malicious and dangerous. And if no interaction is required, then any page can do so, right? No, not quite. So, Chrome has a set of protections, that there are certain things that a page cannot do if the user has not interacted with the page. You might see this at play in Discord when trying to refresh a page containing a video call. “Click anywhere on this page to enable video.” It’s intended to prevent annoying auto-play videos and other irritating page behavior. And most importantly, it’s *not* the only protection against a page reading your clipboard contents. See for yourself. Reading the clipboard is a site permission, just like accessing your camera or mic.

Now it’s true that a site could potentially *write* to the clipboard, and use this to try to be malicious. For example, writing rm -rf / on a site that claims to be showing off Linux command line tips. But that’s always been the case. It’s why you should always paste into a simple text editor, and not straight into the console from a site. So, really, no panic is necessary. The Chromium devs tried to roll out a slightly more aggressive security measure, and found it broke something unrelated, so partially rolled it back. The sky is not falling.
Continue reading “This Week In Security: Malicious Clipboards, Snakes On A Domain, And Binary Golf” →

ESP8266 And ESP32 WiFi Hacked!

September 5, 2019 by Elliot Williams 48 Comments

[Matheus Garbelini] just came out with three (3!) different WiFi attacks on the popular ESP32/8266 family of chips. He notified Espressif first (thanks!) and they’ve patched around most of the vulnerabilities already, but if you’re running software on any of these chips that’s in a critical environment, you’d better push up new firmware pretty quick.

The first flaw is the simplest, and only effects ESP8266s. While connecting to an access point, the access point sends the ESP8266 an “AKM suite count” field that contains the number of authentication methods that are available for the connection. Because the ESP doesn’t do bounds-checking on this value, a malicious fake access point can send a large number here, probably overflowing a buffer, but definitely crashing the ESP. If you can send an ESP8266 a bogus beacon frame or probe response, you can crash it.

What’s most fun about the beacon frame crasher is that it can be implemented on an ESP8266 as well. Crash-ception! This takes advantage of the ESP’s packet injection mode, which we’ve covered before.

The second and third vulnerabilities exploit bugs in the way the ESP libraries handle the extensible authentication protocol (EAP) which is mostly used in enterprise and higher-security environments. One hack makes the ESP32 or ESP8266 on the EAP-enabled network crash, but the other hack allows for a complete hijacking of the encrypted session.

These EAP hacks are more troubling, and not just because session hijacking is more dangerous than a crash-DOS scenario. The ESP32 codebase has already been patched against them, but the older ESP8266 SDK has not yet. So as of now, if you’re running an ESP8266 on EAP, you’re vulnerable. We have no idea how many ESP8266 devices are out there in EAP networks, but we’d really like to see Espressif patch up this hole anyway.

[Matheus] points out the irony that if you’re using WPA2, you’re actually safer than if you’re unpatched and using the nominally more secure EAP. He also wrote us that if you’re stuck with a bunch of ESP8266s in an EAP environment, you should at least encrypt and sign your data to prevent eavesdropping and/or replay attacks.

Again, because [Matheus] informed Espressif first, most of the bugs are already fixed. It’s even percolated downstream into the Arduino-for-ESP, where it’s just been worked into the latest release a few hours ago. Time for an update. But those crusty old NodeMCU builds that we’ve got running everything in our house? Time for a full recompile.

We’ve always wondered when we’d see the first ESP8266 attacks in the wild, and that day has finally come. Thanks, [Matheus]!