Hírolvasó

User-space shadow stacks are a relatively new feature in Linux; support was only added for 6.6, and is limited to the x86 architecture. As support for other architectures (including arm64 and RISC-V) approaches readiness, though, more thought is going into the API for this feature. As a recent discussion on the integration of shadow stacks with the clone3() system call shows, there are still some details to be worked out.

This ars technica article describes how secure-boot firmware on a huge range of systems can be subverted with a malicious image file:

As its name suggests, LogoFAIL involves logos, specifically those of the hardware seller that are displayed on the device screen early in the boot process, while the UEFI is still running. Image parsers in UEFIs from all three major IBVs [independent BIOS vendors] are riddled with roughly a dozen critical vulnerabilities that have gone unnoticed until now. By replacing the legitimate logo images with identical-looking ones that have been specially crafted to exploit these bugs, LogoFAIL makes it possible to execute malicious code at the most sensitive stage of the boot process.

Security updates have been issued by Debian (tzdata), Fedora (gmailctl), Oracle (kernel), Red Hat (linux-firmware, postgresql:12, postgresql:13, and squid:4), SUSE (cdi-apiserver-container, cdi-cloner-container, cdi- controller-container, cdi-importer-container, cdi-operator-container, cdi- uploadproxy-container, cdi-uploadserver-container, cont, frr, libtorrent-rasterbar, qbittorrent, openssl-3, openvswitch, openvswitch3, and suse-build-key), and Ubuntu (bluez, curl, linux, linux-aws, linux-azure, linux-laptop, linux-lowlatency, linux-oem-6.5, linux-oracle, linux-raspi, linux-starfive, linux-gcp, open-vm-tools, postgresql-12, postgresql-14, postgresql-15, and python-cryptography).

A Google és a Microsoft megoldásánál egy fokkal biztonságosabb megoldást kínál a Proton szolgáltatása.

A játék előzetesét eddig soha nem látott érdeklődés övezte.

Bővebben is beszélt a keresőcég a Geminiről.

Úgy tűnik, az RCS-alapú üzenetek támogatásának lehetősége meggyőzhette az Európai Bizottságot.

Mostantól a chatüzenetek és hívások is alapesetben végponti titkosítást kapnak.

Egyelőre azonban csak iPhone-okon és az újabb Samsung készülékekkel működik.

Problem: you create and VM like you always did, but RHEL 9 bombs with:

Fatal glibc error: CPU does not support x86-64-v2

Solution: as Dan Berrange explains in bug #2060839, a traditional default CPU model qemu64 is no longer sufficient. Unfortunately, there's no "qemu64-v2". Instead, you must select one of the real CPUs.

<cpu mode='host-model' match='exact' check='none'>
<model fallback='forbid'>Broadwell-v4</model>
</cpu>

The LWN.net Weekly Edition for December 7, 2023 is available.

The OpenPGP standard for email encryption has been around since 1997, when it was derived from the venerable Pretty Good Privacy (PGP) program that was released in 1991. Since it came about, OpenPGP has been the decentralized, interoperable way to exchange encrypted email, though its use never really took off as advocates hoped. Now, though, it would seem that a split in the OpenPGP community threatens to fragment the OpenPGP-encrypted-email landscape, potentially leading to interoperability woes.

Compiler Options Hardening Guide

On November 29th, the Open Source Security Foundation (OpenSSF) released a comprehensive and thorough hardening guide aimed at mitigating potential vulnerabilities in C and C++ code through the use of various hardening compiler options.

• Strengthening the Fort : OpenSSF Releases Compiler Options Hardening Guide for C and C++ (blog post about the guide)
• Compiler Options Hardening Guide for C and C++ (the guide)

This guide references some of the work we’ve accomplished over the years in the Kernel Self-Protection Project (KSPP), particularly our efforts to globally enable -Wimplicit-fallthrough and -fstrict-flex-arrays=3 in the upstream Linux kernel.

-Wimplicit-fallthrough

This warning flag warns when a fallthrough occurs unless it is specially marked as being intended. The Linux kernel project uses this flag; it led to the discovery and fixing of many bugs21.

• An end to implicit fall-throughs in the kernel (LWN.net article)

-fstrict-flex-arrays=3

In this guide we recommend using the standard C99 flexible array notation [] instead of non-standard [0] or misleading [1], and then using -fstrict-flex-arrays=3 to improve bounds checking in such cases. In this case, code that uses [0] for a flexible array will need to be modified to use [] instead. Code that uses [1] for a flexible arrays needs to be modified to use [] and also extensively modified to eliminate off-by-one errors. Using [1] is not just misleading39, it’s error-prone; beware that existing code using [1] to indicate a flexible array may currently have off-by-one errors40.

• Safer flexible arrays for the kernel (LWN.net article)
• Progress On Bounds Checking in C and the Linux Kernel – Kees Cook, Google & Gustavo A. R. Silva (Presentation on YouTube)

GCC hardening features

The work of Qing Zhao is also referenced in the guide. Qing is making significant contributions to the KSPP by implementing hardening features in GCC, which we want to adopt in the Linux kernel.

• GCC features to help harden the kernel (LWN.net article)

Beyond the Linux kernel

In conclusion, it’s quite fulfilling to see the hardening work we undertake in the Kernel Self-Protection Project having a significant influence in the world of software security, beyond the Linux kernel.

Many processor vendors provide a mechanism to allow some bits of a pointer value to be used to store unrelated data; these include Intel's linear address masking (LAM), AMD's upper address ignore, and Arm's top-byte ignore. A set of researchers has now come up with a way (that they call "SLAM") to use those features to bypass many checks on pointer validity, opening up a new set of Spectre attacks.

In response to SLAM, Intel made plans to provide software guidance prior to the future release of Intel processors which support LAM (e.g., deploying LAM jointly with LASS). Linux engineers developed patches to disable LAM by default until further guidance is available. ARM published an advisory to provide guidance on future TBI-enabled CPUs. AMD did not implement guidance updates and pointed to existing Spectre v2 mitigations to address the SLAM exploit described in the paper.

See the full paper for the details.

Security updates have been issued by Fedora (chromium, clevis-pin-tpm2, firefox, keyring-ima-signer, libkrun, perl, perl-PAR-Packer, polymake, poppler, rust-bodhi-cli, rust-coreos-installer, rust-fedora-update-feedback, rust-gst-plugin-reqwest, rust-pore, rust-rpm-sequoia, rust-sequoia-octopus-librnp, rust-sequoia-policy-config, rust-sequoia-sq, rust-sequoia-wot, rust-sevctl, rust-snphost, and rust-tealdeer), Mageia (samba), Red Hat (postgresql:12), SUSE (haproxy and kernel-firmware), and Ubuntu (haproxy, linux, linux-aws, linux-aws-6.2, linux-azure, linux-azure-6.2, linux-azure-fde-6.2, linux-lowlatency, linux-oracle, linux-raspi, linux-starfive, linux, linux-aws, linux-kvm, linux-lts-xenial, linux-oem-6.1, and redis).

Négy évtized telt el, mióta a Pascal megváltoztatta a programozás világát.

A cég szerint mindez nem csak környezetkímélőbb a közúti fuvarozásnál, hanem olykor gyorsabb is.

The Common Vulnerabilities and Exploits (CVE) system is the main mechanism for tracking various security flaws, using the omnipresent CVE number—even vulnerabilities with fancy names and web sites have CVE numbers. But the CVE system is not without its critics and, in truth, the incentives between the reporting side and those responsible for handling the bugs have always been misaligned, which leads to abuse of various kinds. There have been efforts to combat some of those abuses along the way; a newly announced "!CVE" project is meant to track vulnerabilities "that are not acknowledged by vendors but still are serious security issues".

Security updates have been issued by Debian (roundcube), Fedora (java-latest-openjdk), Mageia (libqb), SUSE (python-Django1), and Ubuntu (request-tracker4).

There's a decent number of laptops with fingerprint readers that are supported by Linux, and Gnome has some nice integration to make use of that for authentication purposes. But if you log in with a fingerprint, the moment you start any app that wants to access stored passwords you'll get a prompt asking you to type in your password, which feels like it somewhat defeats the point. Mac users don't have this problem - authenticate with TouchID and all your passwords are available after login. Why the difference?

Fingerprint detection can be done in two primary ways. The first is that a fingerprint reader is effectively just a scanner - it passes a graphical representation of the fingerprint back to the OS and the OS decides whether or not it matches an enrolled finger. The second is for the fingerprint reader to make that determination itself, either storing a set of trusted fingerprints in its own storage or supporting being passed a set of encrypted images to compare against. Fprint supports both of these, but note that in both cases all that we get at the end of the day is a statement of "The fingerprint matched" or "The fingerprint didn't match" - we can't associate anything else with that.

Apple's solution involves wiring the fingerprint reader to a secure enclave, an independently running security chip that can store encrypted secrets or keys and only release them under pre-defined circumstances. Rather than the fingerprint reader providing information directly to the OS, it provides it to the secure enclave. If the fingerprint matches, the secure enclave can then provide some otherwise secret material to the OS. Critically, if the fingerprint doesn't match, the enclave will never release this material.

And that's the difference. When you perform TouchID authentication, the secure enclave can decide to release a secret that can be used to decrypt your keyring. We can't easily do this under Linux because we don't have an interface to store those secrets. The secret material can't just be stored on disk - that would allow anyone who had access to the disk to use that material to decrypt the keyring and get access to the passwords, defeating the object. We can't use the TPM because there's no secure communications channel between the fingerprint reader and the TPM, so we can't configure the TPM to release secrets only if an associated fingerprint is provided.

So the simple answer is that fingerprint unlock doesn't unlock the keyring because there's currently no secure way to do that. It's not intransigence on the part of the developers or a conspiracy to make life more annoying. It'd be great to fix it, but I don't see an easy way to do so at the moment.

comments