The exploit is a memory corruption vulnerability in Polkit, a framework that handles the privilege level of various system processes. It specifically impacts the program pkexec. With the proof-of-concept exploit (file download warning) in hand, all an attacker needs to do to escalate themselves to root is to compile the program on the computer and run it as the default user. An example is shown by [Jim MacDonald] on Twitter for those not willing to try this on their own machines.
As bad as this sounds, it seems as though all of the major distributions that this impacts have already released updates that patch the issue, including Debian, Ubuntu, Red Hat, Fedora, open SUSE, and Arch. There is also a temporary workaround that removes read/write permission from the pkexec program so it can’t run at all. That being said, it might be best to check that your Linux systems are all up-to-date and that no strangers have been typing random commands into the terminal recently.
There are many ways to update an embedded system in the field. Images can fly through the air one a time, travel by sneaker or hitch a ride on other passing data. OK, maybe that’s a stretch, but there are certainly a plethora of ways to get those sweet update bytes into a target system. How are those bytes assembled, and what are the tools that do the assembly? This is the problem I needed to solve.
Recall, my system wasn’t a particularly novel one (see the block diagram below). Just a few computers asking each other for an update over some serial busses. I had chosen to bundle the payload firmware images into the binary for the intermediate microcontroller which was to carry out the update process. The additional constraint was that the blending of the three firmware images (one carrier and two payload) needed to happen long after compile time, on a different system with a separate toolchain. There were ultimately two options that fit the bill.
Performing over-the-air updates of devices in the field can be a tricky business. Reliability and recovery is of course key, but even getting the right bits to the right storage sectors can be a challenge. Recently I’ve been working on a project which called for the design of a new pathway to update some small microcontrollers which were decidedly inconvenient.
There are many pieces to a project like this; a bootloader to perform the actual updating, a robust communication protocol, recovery pathways, a file transfer mechanism, and more. What made these micros particularly inconvenient was that they weren’t network-connected themselves, but required a hop through another intermediate controller, which itself was also not connected to the network. Predictably, the otherwise simple “file transfer” step quickly ballooned out into a complex onion of tasks to complete before the rest of the project could continue. As they say, it’s micros all the way down.
Just going by the numbers, it’s a pretty safe bet that most Hackaday readers own an Android device. Even if Google’s mobile operating system isn’t running on your primary smartphone, there’s a good chance it’s on your tablet, e-reader, smart TV, car radio, or maybe even your fridge. Android is everywhere, and while the development of this Linux-based OS has been rocky at times, the general consensus is that it seems to have been moving in the right direction over the last few years. Assuming your devices actually get the latest and greatest update, anyway.
So it’s not much of a surprise that Android 11, which was officially released yesterday, isn’t a huge update. There’s no fundamental changes in the core OS, because frankly, there’s really not a whole lot that really needs changing. Android has become mature enough that from here on out we’re likely to just see bug fixes and little quality of life improvements. Eventually Google will upset the apple cart (no pun intended) with a completely new mobile OS, but we’re not there yet.
Of course, that’s not to say there aren’t some interesting changes in Android 11. Or more specifically, changes that may actually be of interest to the average Hackaday reader. Let’s take a look at a handful of changes and tweaks worth noting for the more technical crowd.
Microsoft seems to have an every-other-version curse. We’re not sure how much of this is confirmation bias, but consider the track record of releases. Windows 95 was game-changing, Windows 98 famously crashed during live demo. Windows 2000 was amazing, Windows ME has been nicknamed the “Mistake Edition”. XP was the workhorse of the world for years and years, and Vista was… well, it was Vista. Windows 7 is the current reigning champion of desktop installs, and Windows 8 was the version that put a touchscreen interface on desktops. The “curse” is probably an example of finding patterns just because we’re looking for them, but the stats do show a large crowd clinging to Windows 7.
Windows 10 made a name for itself by automatically installing itself on Windows 7 and Windows 8 computers, much to the annoyance of many unexpecting “victims” of that free upgrade. Several years have gone by, Windows 10 has gotten better, and support for Windows 7 ends in January. If you’re tied to the Windows ecosystem, it’s time to upgrade to Windows 10. It’s too bad you missed out on the free upgrade to Windows 10, right?
About that… It’s probably an unintended side effect, but all valid Windows 7 and Windows 8 keys are also valid Windows 10 keys. Activation is potentially another issue, but we’ll get to that later.
Weather stations are a popular project, partly because it’s helpful (and interesting) to know about the weather at your exact location rather than a forecast that might be vaguely in your zip code. They’re also popular because they’re a good way to get experience with microcontrollers, sensors, I/O, and communications protocols. Your own build may also be easily upgradeable as the years go by, and [Tysonpower] shows us some of the upgrades he’s made to the popular Sparkfun weather station from a few years ago.
The Sparkfun station is a good basis for a build though, it just needs some updates. The first was that the sensor package isn’t readily available though, but some hunting on Aliexpress netted a similar set of sensors from China. A Wemos D1 Mini was used as a replacement controller, and with it all buttoned up and programmed it turns out to be slightly cheaper (and more up-to-date) than the original Sparkfun station.
Potentially, one of the great things about having a device connected to the network is that you can update it remotely. However, how do you make that happen? If you use the Arduino setup for the ESP8266 or ESP32, you might try [scottchiefbaker’s] library which promises to make the process easy.
Adding it looks to be simple. You’ll need an include, of course. If you don’t mind using port 8080 and the path /webota, you only need to call handle_webota() from your main loop. If you want to change the defaults, you’ll need to add an extra call in your setup. You also need to set up a few global variables to specify your network parameters.