Normal view

There are new articles available, click to refresh the page.
Yesterday — 17 May 2024Main stream

Why a ‘frozen’ distribution Linux kernel isn’t the safest choice for security

17 May 2024 at 08:59

It’s a compelling story and on the surface makes a lot of sense. Carefully curated software patches applied to a known Linux kernel, frozen at a specific release, would obviously seem to be preferable to the random walk of an upstream open source Linux project. But is it true? Is there data to support this ?

After a lot of hard work and data analysis by my CIQ kernel engineering colleagues Ronnie Sahlberg and Jonathan Maple, we finally have an answer to this question. It’s no. The data shows that “frozen” vendor Linux kernels, created by branching off a release point and then using a team of engineers to select specific patches to back-port to that branch, are buggier than the upstream “stable” Linux kernel created by Greg Kroah-Hartman.

↫ Jeremy Allison at CIQ

I mean, it kind of makes sense. The full whitepaper is available, too.

Before yesterdayMain stream

Qualcomm details Linux on Snapdragon X Elite, and it’s looking surprisingly good

15 May 2024 at 20:07

With Qualcomm and Microsoft about to flood the market with devices using the new Snapdragon X Elite, those of us who don’t want to use Windows felt a bit uneasy – what’s Linux support going to look like for this new generation of ARM devices? Well, it seems Qualcomm’s been busy, and they’ve published a blog post detailing their work on Linux support for the X Elite.

It’s been our priority not only to support Linux on our premium-tier SoCs, but to support it pronto. In fact, within one or two days of publicly announcing each generation of Snapdragon 8, we’ve posted the initial patchset for Linux kernel support. Snapdragon X Elite was no exception: we announced on October 23 of last year and posted the patchset the next day. That was the result of a lot of pre-announcement work to get everything up and running on Linux and Debian.

↫ Qualcomm’s developer blog

In the blog post, the company details exactly which X Elite features have already been merged into mainline with Linux 6.8 and 6.9, as well as which features will be merged into mainline in Linux 6.10 and 6.11, and to be quite frank – it’s looking really solid, especially considering this is Qualcomm we’re talking about. Over the coming six months, they’re going to focus on getting end-to-end hardware video decoding working, including in Firefox and Chrome, as well as various CPU and GPU optimisations, adding the required firmware to the linux-firmware package, and providing access to easy installers.

All in all, it’s looking like the X Elite will be exceptionally well supported by Linux before the year’s over.

The blog post also details the boot path for Linux on the X Elite, and that, too, is looking good. It’s using a standard UEFI boot process, and supports GRUB and systemd-boot out of the box. Linux boots up using devicetrees, though, and apparently, there’s a known problem with using those that Qualcomm and the community are working on.

We’re working closely with upstream communities on an open problem with the UEFI-based BIOS while booting with devicetrees. The problem is that, when you have more than one devicetree blob (DTB) packed into the firmware package flashed on the device, there is no standard way of selecting a devicetree to pass on to the kernel. OEMs commonly put multiple DTBs into the firmware package so it will support devices with slightly different SKUs, so we’re keen to solve this problem.

↫ Qualcomm’s developer blog

I am pleasantly surprised by the openness and straightforwardness Qualcomm is showing the Linux community here, and I really hope this is a sign of how the company will keep supporting its laptop and possibly desktop-oriented SoCs from here on out. It seems like next year we will finally be getting competitive ARM laptops that can run Linux in a fully supported fashion.

Linux maintainers were infected for 2 years by SSH-dwelling backdoor with huge reach

15 May 2024 at 12:56
A cartoon door leads to a wall of computer code.

Enlarge (credit: BeeBright / Getty Images / iStockphoto)

Infrastructure used to maintain and distribute the Linux operating system kernel was infected for two years, starting in 2009, by sophisticated malware that managed to get a hold of one of the developers’ most closely guarded resources: the /etc/shadow files that stored encrypted password data for more than 550 system users, researchers said Tuesday.

The unknown attackers behind the compromise infected at least four servers inside kernel.org, the Internet domain underpinning the sprawling Linux development and distribution network, the researchers from security firm ESET said. After obtaining the cryptographic hashes for 551 user accounts on the network, the attackers were able to convert half into plaintext passwords, likely through password-cracking techniques and the use of an advanced credential-stealing feature built into the malware. From there, the attackers used the servers to send spam and carry out other nefarious activities. The four servers were likely infected and disinfected at different times, with the last two being remediated at some point in 2011.

Stealing kernel.org’s keys to the kingdom

An infection of kernel.org came to light in 2011, when kernel maintainers revealed that 448 accounts had been compromised after attackers had somehow managed to gain unfettered, or “root,” system access to servers connected to the domain. Maintainers reneged on a promise to provide an autopsy of the hack, a decision that has limited the public’s understanding of the incident.

Read 19 remaining paragraphs | Comments

Raspberry Pi: how push for child programming skills inspired a coding generation

15 May 2024 at 10:35

Company’s cheap, simple-to-use durable minicomputer has proved a hit all over the world

Raspberry Pi, whose popular minicomputers are sold around the world, has come a long way since its co-founder Jack Lang had to store some of the first batch of single-board devices in his garage more than a decade ago.

What started out as a project to reverse the decline in computer science applications at Cambridge University went on to inspire a generation of child programmers by offering them an affordable $35 (£28) minicomputer. Now the company is preparing to list on the London Stock Exchange.

Continue reading...

💾

© Photograph: Mark Hawkins/Alamy

💾

© Photograph: Mark Hawkins/Alamy

CISA and FBI Issue Alert on Path Traversal Vulnerabilities

13 May 2024 at 05:00

The joint alert from CISA and FBI highlights the continued exploitation of path traversal vulnerabilities in critical infrastructure attacks, impacting sectors like healthcare. The recent CVE-2024-1708 vulnerability in ConnectWise ScreenConnect is a prime example. This flaw was exploited alongside another vulnerability to deploy ransomware and compromise systems.   What are Path Traversal Vulnerabilities?   Path […]

The post CISA and FBI Issue Alert on Path Traversal Vulnerabilities appeared first on TuxCare.

The post CISA and FBI Issue Alert on Path Traversal Vulnerabilities appeared first on Security Boulevard.

Linux Kernel 6.9 Officially Released

12 May 2024 at 18:34
"6.9 is now out," Linus Torvalds posted on the Linux kernel mailing list, "and last week has looked quite stable (and the whole release has felt pretty normal)." Phoronix writes that Linux 6.9 "has a number of exciting features and improvements for those habitually updating to the newest version." And Slashdot reader prisoninmate shared this report from 9to5Linux: Highlights of Linux kernel 6.9 include Rust support on AArch64 (ARM64) architectures, support for the Intel FRED (Flexible Return and Event Delivery) mechanism for improved low-level event delivery, support for AMD SNP (Secure Nested Paging) guests, and a new dm-vdo (virtual data optimizer) target in device mapper for inline deduplication, compression, zero-block elimination, and thin provisioning. Linux kernel 6.9 also supports the Named Address Spaces feature in GCC (GNU Compiler Collection) that allows the compiler to better optimize per-CPU data access, adds initial support for FUSE passthrough to allow the kernel to serve files from a user-space FUSE server directly, adds support for the Energy Model to be updated dynamically at run time, and introduces a new LPA2 mode for ARM 64-bit processors... Linux kernel 6.9 will be a short-lived branch supported for only a couple of months. It will be succeeded by Linux kernel 6.10, whose merge window has now been officially opened by Linus Torvalds. Linux kernel 6.10 is expected to be released in mid or late September 2024. "Rust language has been updated to version 1.76.0 in Linux 6.9," according to the article. And Linus Torvalds shared one more details on the Linux kernel mailing list. "I now have a more powerful arm64 machine (thanks to Ampere), so the last week I've been doing almost as many arm64 builds as I have x86-64, and that should obviously continue during the upcoming merge window too."

Read more of this story at Slashdot.

Fedora Asahi Remix 40 is another big step forward for Linux on Apple Silicon Macs

9 May 2024 at 18:49
Terminal screen showing Fedora logo in ASCII text

Enlarge / RIP, Neofetch. (credit: Kevin Purdy)

Asahi Linux, the project that aims to bring desktop Linux to Apple hardware with Apple silicon—the M series of chips—is out with Fedora Asahi Remix 40. More hardware features of Apple devices are supported, the Fedora Linux 40-based distro ships with KDE's new Plasma 6 desktop, and untold numbers of bugs are squashed, to be replaced with reams more.

Fedora Asahi Remix is a "fully integrated distro," according to the Asahi team, and you can "expect a solid and high-quality experience without any unwanted surprises." It supports all the M1 and M2 devices in the MacBook, Mac Mini, Mac Studio, and iMac lines. It's OpenGL 4.6 and OpenGL ES 3.2 certified, and comes with "the best Linux laptop audio you've ever heard."

So, should you install it on your Mac? Keep scrolling down Asahi's release page and check the "Device support" section. Still missing from most M-series Apple devices are support for Thunderbolt and USB4, built-in microphones, and Touch ID, as well as USB-C display support. Speakers are not supported on the iMac. And HDMI audio is in rough shape, being able to "break audio on the system completely."

Read 6 remaining paragraphs | Comments

PowerPC 40x processor support to be dropped from the Linux kernel

6 May 2024 at 19:09

In addition to Linux 6.10 expected to drop support for very old DEC Alpha processors (EV5 and earlier), it looks like the PowerPC 40x (early PowerPC 400 series) processor and platform support will be retired too.

Back in 2020 was a proposal for dropping PowerPC 40x support from the Linux kernel given that the code was orphaned for a long time with no apparent users. The PowerPC 40x processors were found in thin clients, set-top boxes, and other devices during the 90’s. Finally now it looks like that the PowerPC 40x removal is set to happen.

↫ Michael Larabel

Spring cleaning in the hardware support department. I wonder what has more users – Windows on ARM, or Linux on PowerPC 40x.

run0: a systemd-based, more secure replacement for sudo

29 April 2024 at 07:49

Lennart Poettering, main developer of systemd, has announced run0, a systemd-based replacement for the well-known sudo command that fixes many of he inherent issues with the widely used tool to gain temporary elevated privileges. There are various problems with sudo, which basically come down to that it’s a large SUID binary, meaning it consists of privileged code that unprivileged users can run from their own context. This makes sudo a fairly large attack surface, and why OpenBSD uses doas instead; while doas suffers from the same main problem, it’s much smaller and reduces the attack surface considerably.

SUID processes are weird concepts: they are invoked by unprivileged code and inherit the execution context intended and controlled by unprivileged code. By execution context I mean the myriad of properties that a process has on Linux these days, from environment variables, process scheduling properties, cgroup assignments, security contexts, file descriptors passed, and so on and so on. A few of these settings the kernel is nice enough to clean up automatically when a SUID binary is invoked, but much of it has to be cleaned up by the invoked suid binary. This has to be done very very carefully, and history has shown that SUID binaries are generally pretty shit at that.

↫ Lennart Poettering

Poettering wants to address this problem, and has come up with run0, which behaves like sudo, but works entirely differently and is not SUID. Run0 asks the services manager to create a shell or command under the target user’s ID, creating a new PTY, sending data back and forth from the originating TTY and the new PTY.

Or in other words: the target command is invoked in an isolated exec context, freshly forked off PID 1, without inheriting any context from the client (well, admittedly, we *do* propagate $TERM, but that’s an explicit exception, i.e. allowlist rather than denylist).

One could say, “run0” is closer to behaviour of “ssh” than to “sudo”, in many ways. Except that it doesn’t bother with encryption or cryptographic authentication, key management and stuff, but instead relies on the kernel’s local identification mechanisms.

run0 doesn’t implement a configuration language of its own btw (i.e. no equivalent of /etc/sudoers). Instead, it just uses polkit for that, i.e. how we these days usually let unpriv local clients authenticate against priv servers.

↫ Lennart Poettering

This approach addresses a whole slew of attack vectors on sudo, and it comes with fun additional features like being able to give your terminal a different background tint when using it, or displaying a little red dot in the terminal window title to further indicate you’re using elevated privileges. It will ship as part of the upcoming release of systemd 256.

A BSD person tries Alpine Linux

28 April 2024 at 04:19

In February last year I wrote about running a FreeBSD desktop, and concluded that sometimes you need to give yourself permission to tinker.

Well recently I’ve started tinkering with Alpine Linux! It’s been recommended to me for years, so I’m finally getting around to checking it out. There’s a lot to like if you come from BSD, which we’ll dig into here.

↫ Ruben Schade

Just a quick look at this unexpectedly popular Linux distribution that really has its own identity.

Lunatik: a framework for scripting the Linux kernel with Lua

21 April 2024 at 17:47

Lunatik is a framework for scripting the Linux kernel with Lua. It is composed by the Lua interpreter modified to run in the kernel; a device driver (written in Lua =)) and a command line tool to load and run scripts and manage runtime environments from the user space; a C API to load and run scripts and manage runtime environments from the kernel; and Lua APIs for binding kernel facilities to Lua scripts.

↫ Lunatik GitHub page

I’m not knowledgeable enough to understand what this might be used for, but I figured y’all would be interested in this.

Linus Torvalds really prefers tabs

17 April 2024 at 18:27

Linus Torvalds really doesn’t like spaces – as in, tabs vs. spaces – and got a little annoyed that a commit removed a hidden tab because it “apparently showed breakage in some third-party kernel config parsing tool”. So, Torvalds decided to add some hidden tabs to trigger breakages like this, and is threatening to add more hidden tabs if necessary.

It wasn’t clear what tool it was, but let’s make sure it gets fixed. Because if you can’t parse tabs as whitespace, you should not be parsing the kernel Kconfig files.

In fact, let’s make such breakage more obvious than some esoteric ftrace record size option. If you can’t parse tabs, you can’t have page sizes.

↫ Linus Torvalds

I’m not a programmer so I’m not going to wade into this debate – I have a personal Mastodon account to state it’s obviously tabs – but I did note that it seems like, at least in this commit message, Torvalds uses a double space after a period. Which is objectively the worst thing, right before Fahrenheit.

GestureX: control your Linux machine with hand gestures

15 April 2024 at 14:50

GestureX enables you to control your Linux PC using hand gestures. You can assign specific commands or functionalities to different hand gestures, allowing for hands-free interaction with your computer.

↫ GestureX GitHub page

I personally see no use for any of this, but I’m sure there are some interesting accessibility uses for technology like this, which in and of itself make it a worthwhile endeavour to work on. Do note, though, that this is all beta, so there’s bound to be issues.

Linux 6.10 to merge NTSYNC driver for emulating Windows NT synchronization primitives

14 April 2024 at 16:41

Going through my usual scanning of all the “-next” Git subsystem branches of new code set to be introduced for the next Linux kernel merge window, a very notable addition was just queued up… Linux 6.10 is set to merge the NTSYNC driver for emulating the Microsoft Windows NT synchronization primitives within the kernel for allowing better performance with Valve’s Steam Play (Proton) and Wine of Windows games and other apps on Linux.

↫ Michael Larabel

The improvements to performance of games running under Proton this new driver will bring are legitimately insane. We’re looking at a game-changing addition to the Linux kernel here, and it’s no surprise, then, to see this effort being spearheaded by companies like Valve and CodeWeavers.

Backdoor in XZ Utils That Almost Happened

11 April 2024 at 07:01

Last week, the Internet dodged a major nation-state attack that would have had catastrophic cybersecurity repercussions worldwide. It’s a catastrophe that didn’t happen, so it won’t get much attention—but it should. There’s an important moral to the story of the attack and its discovery: The security of the global Internet depends on countless obscure pieces of software written and maintained by even more obscure unpaid, distractible, and sometimes vulnerable volunteers. It’s an untenable situation, and one that is being exploited by malicious actors. Yet precious little is being done to remedy it.

Programmers dislike doing extra work. If they can find already-written code that does what they want, they’re going to use it rather than recreate the functionality. These code repositories, called libraries, are hosted on sites like GitHub. There are libraries for everything: displaying objects in 3D, spell-checking, performing complex mathematics, managing an e-commerce shopping cart, moving files around the Internet—everything. Libraries are essential to modern programming; they’re the building blocks of complex software. The modularity they provide makes software projects tractable. Everything you use contains dozens of these libraries: some commercial, some open source and freely available. They are essential to the functionality of the finished software. And to its security.

You’ve likely never heard of an open-source library called XZ Utils, but it’s on hundreds of millions of computers. It’s probably on yours. It’s certainly in whatever corporate or organizational network you use. It’s a freely available library that does data compression. It’s important, in the same way that hundreds of other similar obscure libraries are important.

Many open-source libraries, like XZ Utils, are maintained by volunteers. In the case of XZ Utils, it’s one person, named Lasse Collin. He has been in charge of XZ Utils since he wrote it in 2009. And, at least in 2022, he’s had some “longterm mental health issues.” (To be clear, he is not to blame in this story. This is a systems problem.)

Beginning in at least 2021, Collin was personally targeted. We don’t know by whom, but we have account names: Jia Tan, Jigar Kumar, Dennis Ens. They’re not real names. They pressured Collin to transfer control over XZ Utils. In early 2023, they succeeded. Tan spent the year slowly incorporating a backdoor into XZ Utils: disabling systems that might discover his actions, laying the groundwork, and finally adding the complete backdoor earlier this year. On March 25, Hans Jansen—another fake name—tried to push the various Unix systems to upgrade to the new version of XZ Utils.

And everyone was poised to do so. It’s a routine update. In the span of a few weeks, it would have been part of both Debian and Red Hat Linux, which run on the vast majority of servers on the Internet. But on March 29, another unpaid volunteer, Andres Freund—a real person who works for Microsoft but who was doing this in his spare time—noticed something weird about how much processing the new version of XZ Utils was doing. It’s the sort of thing that could be easily overlooked, and even more easily ignored. But for whatever reason, Freund tracked down the weirdness and discovered the backdoor.

It’s a masterful piece of work. It affects the SSH remote login protocol, basically by adding a hidden piece of functionality that requires a specific key to enable. Someone with that key can use the backdoored SSH to upload and execute an arbitrary piece of code on the target machine. SSH runs as root, so that code could have done anything. Let your imagination run wild.

This isn’t something a hacker just whips up. This backdoor is the result of a years-long engineering effort. The ways the code evades detection in source form, how it lies dormant and undetectable until activated, and its immense power and flexibility give credence to the widely held assumption that a major nation-state is behind this.

If it hadn’t been discovered, it probably would have eventually ended up on every computer and server on the Internet. Though it’s unclear whether the backdoor would have affected Windows and macOS, it would have worked on Linux. Remember in 2020, when Russia planted a backdoor into SolarWinds that affected 14,000 networks? That seemed like a lot, but this would have been orders of magnitude more damaging. And again, the catastrophe was averted only because a volunteer stumbled on it. And it was possible in the first place only because the first unpaid volunteer, someone who turned out to be a national security single point of failure, was personally targeted and exploited by a foreign actor.

This is no way to run critical national infrastructure. And yet, here we are. This was an attack on our software supply chain. This attack subverted software dependencies. The SolarWinds attack targeted the update process. Other attacks target system design, development, and deployment. Such attacks are becoming increasingly common and effective, and also are increasingly the weapon of choice of nation-states.

It’s impossible to count how many of these single points of failure are in our computer systems. And there’s no way to know how many of the unpaid and unappreciated maintainers of critical software libraries are vulnerable to pressure. (Again, don’t blame them. Blame the industry that is happy to exploit their unpaid labor.) Or how many more have accidentally created exploitable vulnerabilities. How many other coercion attempts are ongoing? A dozen? A hundred? It seems impossible that the XZ Utils operation was a unique instance.

Solutions are hard. Banning open source won’t work; it’s precisely because XZ Utils is open source that an engineer discovered the problem in time. Banning software libraries won’t work, either; modern software can’t function without them. For years, security engineers have been pushing something called a “software bill of materials”: an ingredients list of sorts so that when one of these packages is compromised, network owners at least know if they’re vulnerable. The industry hates this idea and has been fighting it for years, but perhaps the tide is turning.

The fundamental problem is that tech companies dislike spending extra money even more than programmers dislike doing extra work. If there’s free software out there, they are going to use it—and they’re not going to do much in-house security testing. Easier software development equals lower costs equals more profits. The market economy rewards this sort of insecurity.

We need some sustainable ways to fund open-source projects that become de facto critical infrastructure. Public shaming can help here. The Open Source Security Foundation (OSSF), founded in 2022 after another critical vulnerability in an open-source library—Log4j—was discovered, addresses this problem. The big tech companies pledged $30 million in funding after the critical Log4j supply chain vulnerability, but they never delivered. And they are still happy to make use of all this free labor and free resources, as a recent Microsoft anecdote indicates. The companies benefiting from these freely available libraries need to actually step up, and the government can force them to.

There’s a lot of tech that could be applied to this problem, if corporations were willing to spend the money. Liabilities will help. The Cybersecurity and Infrastructure Security Agency’s (CISA’s) “secure by design” initiative will help, and CISA is finally partnering with OSSF on this problem. Certainly the security of these libraries needs to be part of any broad government cybersecurity initiative.

We got extraordinarily lucky this time, but maybe we can learn from the catastrophe that didn’t happen. Like the power grid, communications network, and transportation systems, the software supply chain is critical infrastructure, part of national security, and vulnerable to foreign attack. The US government needs to recognize this as a national security problem and start treating it as such.

This essay originally appeared in Lawfare.

XZ Utils Backdoor

2 April 2024 at 14:50

The cybersecurity world got really lucky last week. An intentionally placed backdoor in XZ Utils, an open-source compression utility, was pretty much accidentally discovered by a Microsoft engineer—weeks before it would have been incorporated into both Debian and Red Hat Linux. From ArsTehnica:

Malicious code added to XZ Utils versions 5.6.0 and 5.6.1 modified the way the software functions. The backdoor manipulated sshd, the executable file used to make remote SSH connections. Anyone in possession of a predetermined encryption key could stash any code of their choice in an SSH login certificate, upload it, and execute it on the backdoored device. No one has actually seen code uploaded, so it’s not known what code the attacker planned to run. In theory, the code could allow for just about anything, including stealing encryption keys or installing malware.

It was an incredibly complex backdoor. Installing it was a multi-year process that seems to have involved social engineering the lone unpaid engineer in charge of the utility. More from ArsTechnica:

In 2021, someone with the username JiaT75 made their first known commit to an open source project. In retrospect, the change to the libarchive project is suspicious, because it replaced the safe_fprint function with a variant that has long been recognized as less secure. No one noticed at the time.

The following year, JiaT75 submitted a patch over the XZ Utils mailing list, and, almost immediately, a never-before-seen participant named Jigar Kumar joined the discussion and argued that Lasse Collin, the longtime maintainer of XZ Utils, hadn’t been updating the software often or fast enough. Kumar, with the support of Dennis Ens and several other people who had never had a presence on the list, pressured Collin to bring on an additional developer to maintain the project.

There’s a lot more. The sophistication of both the exploit and the process to get it into the software project scream nation-state operation. It’s reminiscent of Solar Winds, although (1) it would have been much, much worse, and (2) we got really, really lucky.

I simply don’t believe this was the only attempt to slip a backdoor into a critical piece of Internet software, either closed source or open source. Given how lucky we were to detect this one, I believe this kind of operation has been successful in the past. We simply have to stop building our critical national infrastructure on top of random software libraries managed by lone unpaid distracted—or worse—individuals.

Ext2 filesystem driver now marked as deprecated

30 March 2024 at 09:57

It’s the ext2 filesystem driver that will be marked as deprecated in the upcoming 6.9 Linux kernel. The main issue is that even if the filesystem is created with 256 byte inodes (mkfs.ext2 -I 256), the filesystem driver will stick to 32 bit dates. Because of this, the driver does not support inode timestamps beyond 03:14:07 UTC on 19 January 2038.

↫ Michael Opdenacker

Kernel developer Ted T’so did state that if someone wants to add support for 64bit dates to ext2, it shouldn’t be too hard. I doubt many people still use ext2, but if someone is willing to step up, the deprecation can be made undone by adding this support.

Monogon OS: a new kind of Linux operating system

29 March 2024 at 14:28

Monogon OS is an open-source, secure, API-driven and minimal operating system unlike any other. It is based on Linux and Kubernetes, but with a clean userland rebuilt entirely from scratch. It is written in pure Go and eliminates decades worth of legacy code and unnecessary complexity.

It runs on a fleet of bare metal or cloud machines and provides users with a hardened, production ready Kubernetes, without the overhead of traditional Linux distributions or configuration management systems. It does away with the scripting/YAML duct tape and configuration drift inherent to traditional deployments. Instead, it provides a stable API-driven platform free of vendor lock-in and with none of the drudgery.

↫ Monogon OS website

This not exactly in my wheelhouse, but I’m pretty sure some of you will be all over this concept.

❌
❌