The folks at Pen Test Partners decided to take a look at electric vehicle chargers. Many of these chargers are WiFi-connected, and let you check your vehicle’s charge state via the cloud. How well are they secured? Predictably, not as well as they could be.
The worst of the devices tested, Project EV, didn’t actually have any user authentication on the server side API. Knowing the serial number was enough to access the account and control the device. The serial numbers are predictable, so taking over every Project EV charger connected to the internet would have been trivial. On top of that, arbitrary firmware could be loaded remotely onto the hardware was possible, representing a real potential problem.
The EVBox platform had a different problem, where an authenticated user could simply specify a security role. The tenantadmin role was of particular interest here, working as a superadmin that could see and manage multiple accounts. This flaw was patched within an impressive 24 hours. The
EVBox charger, as well as several other devices they checked had fundamental security weaknesses due to their use of Raspberry Pi hardware in the product. Edit: The EVBox was *not* one of the devices using the Pi in the end product.
Wait, What About the Raspberry Pi?
Apparently the opinion that a Raspberry Pi didn’t belong in IoT hardware caught Pen Test Partners some flack, because a few days later they published a follow-up post explaining their rationale. To put it simply, the Pi can’t do secure boot, and it can’t do encrypted storage. Several of the flaws they found in the chargers mentioned above were discovered because the device filesystems were wide open for inspection. A processor that can handle device encryption, ideally better than the TPM and Windows Bitlocker combination we covered last week, gives some real security against such an attack. Continue reading “This Week In Security: Insecure Chargers, Request Forgeries, And Kernel Security”
You may remember the Pipewire coverage we ran a couple weeks ago, and the TODO item to fix up Firewire device support with Pipewire. It turns out that this is an important feature for kernel hackers, too, because the Alsa changes just got pulled into the 5.14 kernel, and included is the needed Firewire audio work. Shout-out to [Marcan] for pointing out this changeset. Yes, that’s the same as [Hector Martin], the hacker bringing Linux to the M1, who also discovered M1racles. We’ve covered some of his work before.
It turns out that some Firewire audio devices expect timing information in the delivery stream to match the proper playback time for the audio contained in the stream. A naive driver ends up sending packets of sound to the Firewire device that wanted to be played before the packet arrives. No wonder the devices didn’t work correctly. I’m running a 5.14 development kernel, and so far my Focusrite Saffire Pro40 has been running marvelously, where previous kernels quickly turned its audio into a crackling mess.
There is another fix that’s notable for Pipewire users, a reduction in latency for USB audio devices. That one turned out to be not-quite-correct, leading to a hang in the kernel on Torvald’s machine. It’s been reverted until the problem can be corrected, but hopefully this one will land for 5.14 as well. (Edit: The patch was cleaned up, and has been pulled for 5.14. Via Phoronix.) Let us know if you’d like to see more kernel development updates!
One problem with modern programming languages is the reach their overly enthusiastic early adopters have nowadays thanks to the internet. As a result, everyone else’s first encounter with them are oftentimes some crude, fanboyish endeavors to rewrite every single established software project in that shiny new language — just because — which may leave an off-putting taste behind. However, Rust certainly seems to have outgrown this state by now, and with its rising popularity within the general developer population, it’s safe to say it will stick around. Will it fully replace C one day? Probably not, but there’s a big chance for coexistence, and [Nick Desaulniers] got the ball rolling for that within the Linux kernel.
Now, before you storm off pledging your allegiance to C by finding a new operating system: nothing is happening yet. [Nick] simply tested the waters for a possible future of Rust within the Linux kernel code base, which is something he’s planning to bring up for discussion in this year’s Linux Plumbers Conference — the annual kernel developer gathering. The interesting part is [Linus Torvalds]’s respone on the LKML thread, which leaves everyone hoping for a hearty signature Rust rant akin to his C++ one disappointed. Instead, his main concern is that a soft and optional introduction of the support in the build system would leave possible bugs hidden, and therefore should be automatically enabled if a Rust compiler is present — essentially implying that he seems otherwise on board.
We’ll see what comes of it, but with Rust language team lead [Josh Triplett] stating that enhancements benefiting and advancing a kernel integration are certainly imaginable for Rust itself, we might see interesting collaborations coming up in the near future. If you don’t want to wait for that and use Rust already today in a user-land driver, check out this 35c3 talk. And if that doesn’t go far enough for you, here’s a whole (non-Linux) kernel written in Rust.
We’ve often heard that you don’t need to know how an engine works to drive a car, but you can bet that professional race car drivers know. By analogy, you can build lots of systems with off-the-shelf boards like Raspberry Pis and program that using Python or some other high-level abstraction. The most competent hackers, though, know what’s going on inside that Pi and what Python is doing under the hood down to some low level.
If you’ve been using Linux “under the hood” often means understanding what happens inside the kernel–the heart of the Linux OS that manages and controls everything. It can be a bit daunting; the kernel is simple in concept, but has grown over the years and is now a big chunk of software to approach.
Your first embedded system project probably shouldn’t be a real time 3D gamma ray scanner. A blinking LED is a better start. If you are approaching the kernel, you need a similar entry level project. [Stephen Brennan] has just the project for you: add your own system call to a custom Linux kernel.
Continue reading “Under The (Linux) Hood”