Hírolvasó

Version 8.2.0 of the QEMU emulator is out. Changes include new emulations for virtio-sound devices, universal flash storage devices, Xilinx Versal boards, and much more.

Yet another year has come to an end. Much to our dismay, 2023 did not, in fact, happen exactly as we predicted back in January. So it seems that, once again, we will have to go through the process of looking at the predictions that we made and mocking each in turn, before getting into what was missed altogether. A lot happened in 2023, not all of which was predictable.

The 2024 Linux Storage, Filesystem, Memory-Management, and BPF Summit will be held May 13 to 15 in Salt Lake City, Utah, USA. The call for proposals has already gone out, with a deadline of March 1. "LSF/MM/BPF is an invitation-only technical workshop to map out improvements to the Linux storage, filesystem, BPF, and memory management subsystems that will make their way into the mainline kernel within the coming years."

The 6.6.8, 6.1.69, 5.15.144, 5.10.205, 5.4.265, 4.19.303, and 4.14.334 stable kernel updates have all been released; each contains another set of important fixes.

Note that 5.15.145 is already in the review process, with a due date of December 22. It consists almost exclusively of ksmbd patches in a flurry of backporting that was seemingly inspired by the recent marking of ksmbd as broken in 5.15.

Security updates have been issued by Fedora (ansible and ansible-core), Gentoo (Minecraft Server and thunderbird), Mageia (fusiondirectory), Red Hat (gstreamer1-plugins-bad-free, opensc, and openssl), Slackware (libssh and mozilla), SUSE (avahi, firefox, ghostscript, gstreamer-plugins-bad, mariadb, openssh, openssl-1_1-livepatches, python-aiohttp, python-cryptography, xorg-x11-server, and xwayland), and Ubuntu (libssh and openssh).

Taters, a macska ezzel a Földtől a legtávolabb jutó élőlény lett.

A DSA szigorúbb feltételei vonatkoznak mostantól a Pornhubra, az XVideos-ra és a Stripchatre is.

Ráadásul akár a hajlítható kijelzős mobilok is szétkaphatók otthon a gyártó által támogatott módon.

A szolgáltató legújabb mesh eszközei már Wi-Fi 6E -képesek.

Az állam kiszállt, de a Vodafone révén még mindig jelen van tulajdonosként a hazai távközlésben.

Vulkan 1.3.274 moves the Vulkan encode work out of BETA and moves h264 and h265 into KHR extensions. radv support for the Vulkan video encode extensions has been in progress for a while.

The latest branch is at [1]. This branch has been updated for the new final headers.

Updated: It passes all of h265 CTS now, but it is failing one h264 test.

Initial ffmpeg support is [2].

[1] https://gitlab.freedesktop.org/airlied/mesa/-/tree/radv-vulkan-video-encode-h2645-spec-latest?ref_type=heads

[2] https://github.com/cyanreg/FFmpeg/commits/vulkan/

Earlier this year, after Github accidentally committed their private RSA SSH host key to a public repository, I wrote about how better support for SSH host certificates would allow this sort of situation to be handled in a user-transparent way without any negative impact on security. I was hoping that someone would read this and be inspired to fix the problem but sadly that didn't happen so I've actually written some code myself.

The core part of this is straightforward - if a server presents you with a certificate associated with a host key, then make the trust in that host be whoever signed the certificate rather than just trusting the host key. This means that if someone needs to replace the host key for any reason (such as, for example, them having published the private half), you can replace the host key with a new key and a new certificate, and as long as the new certificate is signed by the same key that the previous certificate was, you'll trust the new key and key rotation can be carried out without any user errors. Hurrah!

So obviously I wrote that bit and then thought about the failure modes and it turns out there's an obvious one - if an attacker obtained both the private key and the certificate, what stops them from continuing to use it? The certificate isn't a secret, so we basically have to assume that anyone who possesses the private key has access to it. We may have silently transitioned to a new host key on the legitimate servers, but a hostile actor able to MITM a user can keep on presenting the old key and the old certificate until it expires.

There's two ways to deal with this - either have short-lived certificates (ie, issue a new certificate every 24 hours or so even if you haven't changed the key, and specify that the certificate is invalid after those 24 hours), or have a mechanism to revoke the certificates. The former is viable if you have a very well-engineered certificate issuing operation, but still leaves a window for an attacker to make use of the certificate before it expires. The latter is something SSH has support for, but the spec doesn't define any mechanism for distributing revocation data.

So, I've implemented a new SSH protocol extension that allows a host to send a key revocation list to a client. The idea is that the client authenticates to the server, receives a key revocation list, and will no longer trust any certificates that are contained within that list. This seems simple enough, but a naive implementation opens the client to various DoS attacks. For instance, if you simply revoke any key contained within the received KRL, a hostile server could revoke any certificates that were otherwise trusted by the client. The easy way around this is for the client to ensure that any revoked keys are associated with the same CA that signed the host certificate - that way a compromised host can only revoke certificates associated with that CA, and can't interfere with anyone else.

Unfortunately that still means that a single compromised host can still trigger revocation of certificates inside that trust domain (ie, a compromised host a.test.com could push a KRL that invalidated the certificate for b.test.com), because there's no way in the KRL format to indicate that a given revocation is associated with a specific hostname. This means we need a mechanism to verify that the KRL update is legitimate, and the easiest way to handle that is to sign it. The KRL format specifies an in-band signature but this was deprecated earlier this year - instead KRLs are supposed to be signed with the sshsig format. But we control both the server and the client, which means it's easy enough to send a detached signature as part of the extension data.

Putting this all together: you ssh to a server you've never contacted before, and it presents you with a host certificate. Instead of the host key being added to known_hosts, the CA key associated with the certificate is added. From now on, if you ssh to that host and it presents a certificate signed by that CA, it'll be trusted. Optionally, the host can also send you a KRL and a signature. If the signature is generated by the CA key that you already trust, any certificates in that KRL associated with that CA key will be incorporated into local storage. The expected flow if a key is compromised is that the owner of the host generates a new keypair, obtains a new certificate for the new key, and adds the old certificate to a KRL that is signed with the CA key. The next time the user connects to that host, they receive the new key and new certificate, trust it because it's signed by the same CA key, and also receive a KRL signed with the same CA that revokes trust in the old certificate.

Obviously this breaks down if a user is MITMed with a compromised key and certificate immediately after the host is compromised - they'll see a legitimate certificate and won't receive any revocation list, so will trust the host. But this is the same failure mode that would occur in the absence of keys, where the attacker simply presents the compromised key to the client before trust in the new key has been created. This seems no worse than the status quo, but means that most users will seamlessly transition to a new key and revoke trust in the old key with no effort on their part.

The work in progress tree for this is here - at the point of writing I've merely implemented this and made sure it builds, not verified that it actually works or anything. Cleanup should happen over the next few days, and I'll propose this to upstream if it doesn't look like there's any showstopper design issues.

comments

Linux graphics developers often speak of modern Linux graphics when they refer to a number of individual software components and how they interact with each other. Among other things, it's a mix of kernel-managed display resources, Wayland for compositing, accelerated 3D rendering, and decidedly not X11. In a two-part series, we will take a fast-paced journey through the graphics code to see how it converts application data to pixel data and displays it on the screen. In this installment, we look at application rendering, Mesa internals, and the necessary kernel features.

Version 4.2.0 of the Qubes OS distribution has been released; changes include a switch to Xfce for the Fedora and Debian templates, a number of rewritten graphical applications, PipeWire support, and more. See the release notes for details. (Qubes OS was last covered here in 2021).

OpenSSH 9.6 has been released. It includes some minor improvements and a fix for the so-called Terrapin attack.

While cryptographically novel, the security impact of this attack is fortunately very limited as it only allows deletion of consecutive messages, and deleting most messages at this stage of the protocol prevents user authentication from proceeding and results in a stuck connection.

Version 121.0 of the Firefox browser is out. Along with the usual pile of security fixes, this release add the ability to force links to be rendered with underlines and use of Wayland by default if it is available: "This brings support for touchpad & touchscreen gestures, swipe-to-nav, per-monitor DPI settings, better graphics performance, and more."

Security updates have been issued by Debian (webkit2gtk), Fedora (rdiff-backup and xorg-x11-server-Xwayland), Mageia (cjose and ghostscript), Oracle (avahi), Red Hat (postgresql:10), and SUSE (avahi, freerdp, libsass, and ncurses).

A cég egy-két dolgot elhallgatott a szolgáltatás működése kapcsán.

As announced by Damien Miller OpenSSH 9.6/9.6p1 has been released.

The complete release notes may be found here: https://www.openssh.com/releasenotes.html#9.6.

Among notable changes, this release includes a fix for the Terrapin Attack.

Read more…

A véroxigénszint-szenzor körüli szabadalmi vitával kapcsolatos végső döntés Joe Biden kezében van.