A popular expression in the Linux forums nowadays is noting that someone “uses Arch btw”, signifying that they have the technical chops to install and use Arch Linux, a distribution designed to be cutting edge but that also has a reputation of being for advanced users only. Whether this meme was originally posted seriously or was started as a joke at the expense of some of the more socially unaware Linux users is up for debate. Either way, while it is true that Arch can be harder to install and configure than something like Debian or Fedora, thanks to excellent documentation and modern (but optional) install tools it’s no longer that much harder to run than either of these popular distributions.

For my money, the true mark of a Linux power user is the ability to install and configure Gentoo Linux and use it as a daily driver or as a way to breathe life into aging hardware. Gentoo requires much more configuration than any mainline distribution outside of things like Linux From Scratch, and has been my own technical white whale for nearly two decades now. I was finally able to harpoon this beast recently and hope that my story inspires some to try Gentoo while, at the same time, saving others the hassle.

A Long Process, in More Ways Than One

My first experience with Gentoo was in college at Clemson University in the late ’00s. The computing department there offered an official dual-boot image for any university-supported laptop at the time thanks to major effort from the Clemson Linux User Group, although the image contained the much-more-user-friendly Ubuntu alongside Windows. CLUG was largely responsible for helping me realize that I had options outside of Windows, and eventually I moved completely away from it and began using my own Linux-only installation. Being involved in a Linux community for the first time had me excited to learn about Linux beyond the confines of Ubuntu, though, and I quickly became the type of person featured in this relevant XKCD. So I fired up an old Pentium 4 Dell desktop that I had and attempted my first Gentoo installation.

For the uninitiated, the main thing that separates Gentoo from most other distributions is that it is source-based, meaning that users generally must compile the source code for all the software they want to use on their own machines rather than installing pre-compiled binaries from a repository. So, for a Gentoo installation, everything from the bootloader to the kernel to the desktop to the browser needs to be compiled when it is installed. This can take an extraordinary amount of time especially for underpowered machines, although its ability to customize compile options means that the ability to optimize software for specific computers will allow users to claim that time back when the software is actually used. At least, that’s the theory.

It didn’t work out too well for me and my Dell, though, largely because Dell of the era would put bottom-basement, obscure hardware in their budget computers which can make for a frustrating Linux experience even among the more user-friendly distributions due to a general lack of open-source drivers. I still hold a grudge against Dell for this practice in much the same way that I still refuse to use Nvidia graphics cards, but before I learned this lesson I spent weeks one summer in college with this Frankensteined computer, waiting for kernels and desktop environments to compile for days only to find out that there was something critical missing that broke my installations. I did get to a working desktop environment at one point, but made a mistake with it along the way and decided, based on my Debian experiences, that re-installing the operating system was the way to go rather than actually fixing the mistake I had made. I never got back to a working desktop after that and eventually gave up.

This experience didn’t drive me away from Gentoo completely, though. It was always at the back of my mind during any new Linux install I performed, especially if I was doing so on underpowered hardware that could have benefited from Gentoo’s customization. I would try it occasionally again and again only to give up for similar reasons, but finally decided I had gained enough knowledge from my decades as a Debian user to give it a proper go. A lot has changed in the intervening years; in the days of yore an aspiring Gentoo user had to truly start at the ground up, even going as far as needing to compile a compiler. These days only Gentoo developers take these fundamental steps, providing end users with a “Stage 3” tarball which contains the core needed to install the rest of Gentoo.

Bringing Out The Best of Old Hardware

And I do have a piece of aging hardware that could potentially benefit from a Gentoo installation. My mid-2012 Macbook Pro (actually featured in this article) is still a fairly capable machine, especially since I only really need a computer these days for light Internet browsing and writing riveting Hackaday articles. Apple long ago dropped support for this machine in macOS meaning that it’s no longer a good idea to run its native operating system. In my opinion, though, these older, pre-butterfly Macs are still excellent Linux machines aside from minor issues like finding the correct WiFi drivers. (It also can’t run libreboot, but it’s worth noting that some Macs even older than mine can.) With all of that in mind I got to work compiling my first Linux kernel in years, hoping to save my old Macbook from an e-waste pile.

There’s a lot expected of a new Gentoo user even with modern amenities like the stage 3 tarball (and even then, you have to pick a stage file from a list of around 50 options), and although the handbooks provided are fairly comprehensive they can be confusing or misleading in places. (It’s certainly recommended to read the whole installation guide first and even perform a trial installation in a virtual machine before trying it on real hardware.) In addition to compiling most software from source (although some popular packages like Firefox, LibreOffice, and even the kernel itself are available as precompiled binaries now), Gentoo requires the user to configure what are called USE flags for each package which specify that package’s compile options. A global USE flag file is also maintained to do things like build GNOME, Bluetooth, even 32-bit support into every package, while specific package USE flags are maintained in other separate files. For example, when compiling GIMP, users can choose which image formats they want their installation of GIMP to support. There’s a second layer of complexity here too as certain dependencies for packages can be “masked” or forbidden from being installed by default, so the user will also need to understand why certain things are masked and manually unmask them if the risk is deemed acceptable.

One thing that Gentoo has pioneered in recent years is the use of what it calls distribution kernels. These are kernel configurations with sane defaults, meaning that that they’ll probably work for most users on most systems on the first try. From there, users can begin tweaking the kernel for their use case once they have a working installation, but they don’t have to do that leg work during the installation process anymore. Of course, in true Gentoo fashion, you can still go through the process of configuring the kernel manually during the install if you choose to.

Aside from compiling a kernel, Gentoo also requires the user to make other fundamental choices about their installation during the install process that most other major distributions don’t. Perhaps the biggest one is that the user has to choose an init system, the backbone of the operating system’s startup and service management systems. Generally most distributions decide for you, with most larger distributions like Debian, Fedora, and Arch going with systemd by default. Like anything in the Linux world, systemd is controversial for some, so there are alternatives with OpenRC being the one with the most acceptance in the Gentoo world. I started out with OpenRC in my installations but found a few pieces of software that I use regularly don’t play well with it, so I started my build over and now use systemd. The user also can select between a number of different bootloaders, and I chose the tried-and-true Grub seeing no compelling reason to change at the moment.

In addition, there’s no default desktop environment, so you’ll also need to choose between GNOME, KDE, XFCE, any other desktop environment, or among countless window managers. The choice to use X or Wayland is up to you as well. For what it’s worth, I can at least report that GNOME takes about three times as long to compile as the kernel itself does, so keep that in mind if you’re traveling this path after me.

It’s also possible you’ll need to install a number of drivers for hardware, some of which might be non-free and difficult to install in Gentoo while they might be included by default in distributions like Ubuntu. And, like everything else, they’ll need to be compiled and configured on your machine as well. For me specifically, Gentoo was missing the software to control the fans on my MacBook Pro, but this was pretty easy to install once I found it. There’s an additional headache here as well with the Broadcom Wi-Fi cards found in older Macs, which are notoriously difficult pieces of hardware to work with in the Linux world. I was eventually able to get Wi-Fi working on my MacBook Pro, but I also have an 11″ MacBook Air from the same era that has a marginally different wireless chipset that I still haven’t been able to get to work in Gentoo, giving me flashbacks to my experience with my old Dell circa 2007.

This level of granularity when building software and an overall installation is what gives Gentoo the possibility for highly optimized installations, as every package can be configured for the user’s exact use case for every package down to the kernel itself. It’s also a rolling release model similar to Arch, so in general the newest versions of software will be available for it as soon as possible while a Debian user might have to wait a year or two for the next stable release.

A Few Drawbacks

It’s not all upside, though. For those without a lot of Gentoo experience (including myself) it’s possible to do something like spend a day and a half compiling a kernel or desktop environment only to find out a critical feature wasn’t built, and then have to spend another day and a half compiling it again with the correct USE flags. Or to use the wrong stage file on the first try, or realize OpenRC won’t work as an init system for a specific use case, or having Grub inscrutably be unable to find the installation. Also, don’t expect Gentoo to be faster out-of-the-box than Debian or Fedora without a customization effort, either; for me Gentoo was actually slower than Debian in my benchmarks without a few kernel and package re-compiles. With enough persistence and research, though, it’s possible to squeeze every bit of processing power out of a computer this way.

Personally, I’m not sure I’m willing to go through the amount of effort to migrate my workstations (and especially my servers) to Gentoo because of how much extra configuration is required for often marginal performance gains thanks to the power and performance capabilities of modern hardware. Debian Stable will likely remain my workhorse for the time being for those machines, and I wouldn’t recommend anyone install Gentoo who doesn’t want to get into the weeds with their OS. But as a Linux hobbyist there’s a lot to be said for using other distributions that are a little more difficult to use than Debian or even Arch, although I’d certainly recommend using a tool like Clonezilla to make backups of your installation from time to time so if you do make the same mistakes I made in college you can more easily restore your system. For me, though, I still plan to keep Gentoo on my MacBook Pro since it’s the machine that I tinker with the most in the same way that a classic car enthusiast wants to keep their vehicle on the road and running as well as it did when it was new. It also lets me end forum posts with a sardonic “I use Gentoo, btw” to flex on the Arch users, which might be the most important thing of all.

For those of you longing for better gaming on an Apple Silicon device, Asahi Linux is here to help.

While Apple’s own line of CPUs are relatively new kids on the block, they’ve still been around for four years now, giving hackers ample time to dissect their innards. The team behind Asahi Linux has now brought us “the only conformant OpenGL®, OpenCL, and Vulkan® drivers” for Apple’s M1 and M2.

The emulation overhead of the system means that most games will need at least 16 GB of RAM to run. Many games are playable, but newer titles can’t yet hit 60 frames per second. The developers are currently focused on “correctness” and hope to improve performance in future updates. Many indie titles are reported to already be working at full speed though.

You can hear more about some of the fiddly bits of how to “tessellate with arcane compute shaders” in the video below. Don’t worry, it’s only 40 minutes of the nine hour video and it should start right at the presentation by GPU dev [Alyssa Rosenzweig].

If you want to see some of how Linux on Apple Silicon started or some of the previous work on hacking the M1 GPU, we have you covered.

Up first this week is a warning for the few of us still brave enough to host our own email servers. If you’re running Zimbra, it’s time to update, because CVE-2024-45519 is now being exploited in the wild.

That vulnerability is a pretty nasty one, though thankfully requires a specific change from default settings to be exposed. The problem is in postjournal. This logging option is off by default, but when it’s turned on, it logs incoming emails. One of the fields on an incoming SMTP mail object is the RCPT TO: field, with the recipients made of the to, cc, and bcc fields. When postjournal logs this field, it does so by passing it as a bash argument. That execution wasn’t properly sanitized, and wasn’t using a safe call like execvp(). So, it was possible to inject commands using the $() construction.

The details of the attack are known, and researchers are seeing early exploratory attempts to exploit this vulnerability. At least one of these campaigns is attempting to install webshells, so at least some of those attempts have teeth. The attack seems to be less reliable when coming from outside of the trusted network, which is nice, but not something to rely on.

New Tool Corner

What is that binary doing on your system? Even if you don’t do any security research, that’s a question you may ask yourself from time to time. A potential answer is WhoYouCalling. The wrinkle here is that WYC uses the Windows Event Tracing mechanism to collect the network traffic strictly from the application in question. So it’s a Windows only application for now. What you get is a packet capture from a specific executable and all of its children processes, with automated DNS capture to go along.

DNS Poisoning

Here’s a mystery. The folks at Assetnote discovered rogue subdomains from several of their customers, showing up with seemingly random IP addresses attached. A subdomain like webproxy.id.customer.vn might resolve with 10 different addresses, when querying on alibabadns.com.

That turned out to be a particularly important clue. These phantom subdomains were all linked to the Chinese Internet in some way, and it turns out that each subdomain had some interesting keyword in it, like webproxy or VPN. This seems to be a really unique way to censor the Internet, as part of the Chinese Great Firewall. The problem here is that the censorship can escape, and actually poison DNS for those subdomains for the rest of the Internet. And because sometimes the semi-random IPs point at things like Fastly CDN or old cPanel installs. A bit of legwork gets you the equivalent of subdomain takovers. Along with the story, Assetnote have shared a tool to check domains for this issue.

Virtual Name Tags Bring the Creep Factor

What do you get when you combine Internet-connected smart glasses with LLM doing facial recognition? The optimistic opinion is that you get virtual nametags for everybody you meet. I’ve played a video game or two that emulates that sort of ability. Taking a bit more cynical and realistic view, this auto-doxxing of everyone in public strays towards dystopian.

perfctl

There’s a newly discovered Linux malware, perfctl, that specializes in stealth, combined with Monero mining. The malware is also used to relay traffic, as well as install other malware in compromised machines. The malware communicates over TOR, and uses some clever tricks to avoid detection. Log in to a compromised machine, and the Monero mining stops until you log back out.

The malware is particularly difficult to get rid of, and as always, the best solution is to carefully back up and then wipe the affected machine. One of the tells to look for is a machine that’s hard charging when it has no business being spun up to 100% CPU usage, and then when you log in and look for the culprit, it drops to normal.

Bits and Bytes

[nv1t] found a kid’s toy, the Kekz Headphones, and they just begged to be taken apart. This toy has a bunch of audio on an SD Card, and individual NFC-enabled tokens that triggers playback of the right file. This one is interesting from an infosec perspective, because the token actually supplies the encryption key for the file playback, making it a nominally secure system. After pulling everything apart, it became apparent that the encryption wasn’t up to the task, with only about 56 possible keys for each file.

Something we’ve continually talked about is how the subtle mismatches in data parsing often lead to vulnerabilities. [Mahmoud Awali] has noticed this, too, and decided to put together a comparison of how different languages handle HTTP parameters. Did you know that Ruby uses the semicolon as a parameter delimiter? There are a bunch of quirks like this, and this is the sort of material that you’ll need to find that next big vulnerability.

And finally, speaking of Ruby, are you familiar with Ruby’s class pollution category of vulnerabilities? It’s akin to Python and JavaScript’s prototype pollution, and not entirely unlike Java’s deserialization issues. If Ruby is your thing, go brush up on how to avoid this particular pitfall.

It looks like there’s finally hope for sane password policies. The US National Institue of Standards and Technology, NIST, has released a draft of SP 800-63-4, the Digital Identity Guideline.

There’s password guidance in there, like “SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords” and “SHALL NOT require users to change passwords periodically.” NIST approved passwords must be at least 8 characters long, with a weaker recommendation of at least 15 characters. Security questions like name of first pet get the axe. And it’s strongly recommended that all ASCII and Unicode characters should be acceptable for passwords.

This is definitely moving in the right direction. NIST guidelines are only binding for government services and contractors, though they do eventually get picked up by banks and other industries. So there’s hope for sane password policies eventually.

Tank Hacking

Researchers at Bitsight are interested in infrastructure security, and they opted to take a closer look at Automatic Tank Gauging (ATG) systems. Those are found at gas stations, as well as any other facility that needs automated monitoring of liquids or gasses in a tank. There is an actual ATG message format, originally designed for RS-232 serial, and woefully unprepared for the interconnected present. The protocol allows for an optional security code, but it maxes out at only six alpha-numeric characters.

Among the vulnerabilities getting announced today, we have a pair of CVSS 10 command injection flaws, a quartet of 9.8 authentication bypass flaws, with one of those being a hardcoded credential — AKA a backdoor. The other CVSS9+ flaw is a SQL injection, with a trio of slightly less serious flaws.

The really interesting question is what could theoretically be done with admin access and escape to shellcode in one of these systems? There’s the obvious path of Denial of Service. Once you have root, just delete files, flash random noise over the firmware, and walk away. The more interesting approach is to make changes that have physical consequences. If a fuel tank is reprogrammed to indicate that holds twice the volume, will it overflow? Researchers realized that relays have a maximum operation rate, and driving them on and off at faster rates has interesting effects — glowing and letting the magic smoke out.

More Tank Hacking?

Also this week is the story of a Kansas water treatment plant that has gone to manual mode after a cyberattack. It’s not clear whether this was actually an aimed attack at infrastructure, or just a ransomware attack that is impacting the water treatment facility as a side-effect.

The Linux Mystery 9.9 CVE

This week we’ve been watching a story develop after [Simone Margaritelli] sounded the warning about a very serious GNU/Linux vulnerabiltiy on Twitter/X. The claim was a CVSS 9.9 in all Linux systems. Well apparently it’s time, because the details have dropped, and it’s a wild ride.

* Unauthenticated RCE vs all GNU/Linux systems (plus others) disclosed 3 weeks ago.
* Full disclosure happening in less than 2 weeks (as agreed with devs).
* Still no CVE assigned (there should be at least 3, possibly 4, ideally 6).
* Still no working fix.
* Canonical, RedHat and… pic.twitter.com/N2d1rm2VeR

— Simone Margaritelli (@evilsocket) September 23, 2024

So first, the actual vulnerabilities: Part of the Common Unix Printing System (now just CUPS) is cups-browsed, a helper daemon that automatically installs printers discovered on the local network. This binds to all IP addresses on UDP port 631, and an incoming UDP packet will trigger a printer install. The quirk here is that this incoming request can include an arbitrary URL as the source of the IPP printer driver information. That IPP data isn’t sanitized, allowing for arbitrary information upload and subsequent file creation with that arbitrary data. The cherry on top is the foomatic-rip driver that includes the helpful feature of running a shell command as part of the printing process. Oh, and to be clear, the CVSS 9.9 isn’t strictly accurate, because it does require a user interaction to print to the malicious printer, to trigger the code execution.

Now here’s the tricky question: How many of those quirks are vulnerabilities? Cups-browsed seems obviously architected without an authentication layer, and therefore not at all intended to be exposed to the Internet. Downloading an arbitrary IPP file seems to be working as intended, and the FoomaticRIPCommandLine is a documented feature, not a vulnerability.

And yet, pretty obviously, a printer on the local network shouldn’t be able to trigger arbitrary code execution when printing to it, especially when it’s so easy for any computer to fake being a printer. It’s very surprising that there are over 100,000 systems that expose UDP port 631 and the cups-browsed service to the Internet. I look forward to other researchers double-checking that claim. If it wasn’t obvious, don’t expose CUPS to the Internet. It shouldn’t have taken a CVE to make that abundantly clear. That is probably why it was so hard for [Simone] to get the CUPS developers to take this seriously.

As per the Red Hat notice, you can check your Linux systems for this issue by running sudo systemctl status cups-browsed and check a remote machine using sudo nmap -sU -p 631 -v ip.address.of.machine watching for “631/udp open|filtered ipp” in the output. There is already a Proof of Concept that has leaked, so do check and pull the plug on any systems that expose this service.

The Other One

The “9.9” CVE was just a bit of a letdown, but we do have CVE-2024-20017, a confirmed high severity vulnerability in MediaTek’s wappd daemon that seems to weigh in at 9.8.

The vulnerability is specifically in the handling of the Security Block message that’s part of WiFi roaming handoffs. wappd allocates a fixed-size buffer, and doesn’t validate the actual message size before copying that data. This can overflow by up to 1433 bytes, and that’s certainly enough to trigger full RCE. There’s Proof of Concept code available, so watch for updates for Wireless gear.

Bits and Bytes

Kaspersky has done something unexpected, pulling a switcheroo. Users who still had Kaspersky installed have found UltraAV now automatically installed on their machines. It’s reported that Kaspersky was sending email notices out earlier this month that the update was coming.

There’s a really impressive chain of tricks that redirects from a Youtube URL to an arbitrary Google Docs URL. That may not sound particularly interesting, but the whole chain of redirects means that a page that looks like a Google Form with a simple poll could actually grant permissions to arbitrary Google Drive files on submit. Google paid a juicy $4133.70 for the find, and rolled the fix out on the same day.

ChatGPT has a new feature, long-term memory. The idea is that your conversations with the LLM can become part of the training data, making the model even more useful as you use it. There is a really powerful feature available in ChatGPT now, that the LLM can pull data from the Internet in real time. Turns out if you can get one of these instances to pull some manipulated data, the model can keep it in long term storage. The real trick is that this injection can convince the model to keep revisiting an arbitrary URL, leaking data. Impressive.

And finally, the Kia dealer and owners websites leak a bit too much data. With nothing more than the car’s VIN, an attacker can generate a fake dealer token, and demote and replace the previous owner. From there, it’s trivial to remote start, honk, or otherwise mess with the vehicle. It wasn’t great, but Kia got it fixed over a month ago.

It’s often said these days that computers don’t become outdated nearly as quickly as they did in the past, with even a decade-old computer still more than capable of handling daily tasks for the average person. Testing that theory, [Igor Ljubuncic] revisited the Asus eeePC which he purchased back in 2010. Although it’s not specified exactly which model it is, it features an Intel Atom N450 (1 core, 2 threads) running at 1.67 GHz, 1 GB of 667 MHz DDR2 and a 250 GB HDD, all falling into that ultra-portable, 10.1″ Netbook category.

When new, the netbook came with Windows 7 Starter Edition, which [Igor] replaced with Ubuntu Netbook Remix 10.04, which was its own adventure, but the netbook worked well and got dragged around the world on work and leisure assignments. With increasingly bloated updates, Ubuntu got replaced by MX Linux 18, which improved matters, but with the little CPU struggling more and more, [Igor] retired the netbook in 2019. That is, until reviving it recently.

Upon booting, the CMOS battery was of course empty, but the system happily continued booting into MX Linux. The Debian update repositories were of course gone, but changing these to the archive version allowed for some (very old) updates. This raised the question of whether modern Linux would even run on this ancient Atom CPU, the answer of which turned out to be a resounding ‘yes’, as MX Linux still offers 32-bit builds of its most recent releases. A 15 minute upgrade process later, and a 2 minute boot later, the system was running a Linux 6.1 kernel with Xfce desktop.

As for the performance, it’s rather what you expect, with video playback topping out at 480p (on the 1024×600 display) and applications like Firefox lacking the compact density mode, wasting a lot of screen space. Amazingly the original battery seems to still deliver about half the runtime it did when new. All of which is to say that yes, even a ‘low-end’ 2010-era netbook can still be a very usable system in 2024, with a modern OS.

Although Linux runs almost every supercomputer, most of the web, the majority of smart phones, and a few writers’ ancient Macbooks, there’s one major weak point in the Linux world that will almost always have developers reaching for a different operating system. Linux is not a real-time operating system (RTOS), meaning that it can’t respond to requests in the real world within a set timeframe. This means that applications needing computer control in industry, medicine, robotics, and other real-world situations generally need a purpose-built RTOS. At least, that was true until recently when an update to the Linux kernel added real-time capabilities.

The feature, called PREEMPT_RT, forces the Linux kernel to respond to certain request within a set limit of time. This means that a system with this support built into the kernel can “preempt” any current task, stopping everything else a computer is doing in order to execute that task right away. There are some existing solutions to getting a functional equivalent system working with Linux now, but they can be clunky or inelegant, requiring the user to install patches or other software to get it to work. With the support built directly into the kernel this will become much less of a pain point for anyone who needs this functionality going forward.

This feature has been in the works for around two decades now, so with this entering general use now we would expect to start seeing it show up in various projects as well as in commercial offerings soon, especially since other RTOS solutions can be pricey. Don’t recompile the kernel in your desktop for this feature just yet, though; real-time function can cause some unintended consequences with normal use you’ll need to account for. There’s some more discussion on this in the /r/Linux subreddit and there are some other real-time operating systems available for computers not typically capable of running Linux to take a look at as well.

It’s not uncommon for a new distro version to come out, and a grudging admission that maybe a faster laptop is on the cards. Perhaps after seeing this project though, you’ll never again complain about that two-generations-ago 64-bit multi-core behemoth, because [Dimitri Grinberg] — who else! — has succeeded in booting an up-to-date Linux on the real most basic of processors. We’re not talking about 386s, ATmegas, or 6502s, instead he’s gone right back to the beginning. The Intel 4004 was the first commercially available microprocessor back in 1971, and now it can run Linux.

So, given the 4004’s very limited architecture and 4-bit bus, how can it perform this impossible feat? As you might expect, the kernel isn’t being compiled to run natively on such ancient hardware. Instead he’s achieved the equally impossible-sounding task of writing a MIPS emulator for the venerable silicon, and paring back the emulated hardware to the extent that it remains capable given the limitations of the 1970s support chips in interfacing to the more recent parts such as RAM for the MIPS, an SD card, and a VFD display. The result is shown in the video below the break, and even though it’s sped up it’s clear that this is not a quick machine by any means.

We’d recommend the article as a good read even if you’ll never put Linux on a 4004, because of its detailed description of the architecture. Meanwhile we’ve had a few 4004 stories over the years, and this one’s not even the first time we’ve seen it emulate something else.