Hírolvasó

Fejlesztők figyelem: hasznos biztonsági eszközt tett közzé ingyenesen a Google

2 év 8 hónap óta

A Google kedden egy kifejezetten fejlesztőknek szánt hasznos nyílt forráskódú és teljesen ingyenes eszközt jelentett be. Az OSV-Scanner egyfajta sérülékenységvizsgáló eszköz, amivel könnyen felderíthetővé válnak a különböző projektek dependenciáiból eredő sebezhetőségi információi.

The post Fejlesztők figyelem: hasznos biztonsági eszközt tett közzé ingyenesen a Google first appeared on Nemzeti Kibervédelmi Intézet.

NKI

Security updates for Wednesday

2 év 8 hónap óta
Security updates have been issued by Debian (pngcheck), Fedora (qemu), Mageia (admesh, busybox, emacs, libarchive, netkit-telnet, ruby, rxvt-unicode, and shadowutils), Oracle (bcel and kernel), Red Hat (389-ds-base, bcel, dbus, firefox, grub2, kernel, kernel-rt, kpatch-patch, thunderbird, and usbguard), Scientific Linux (bcel), SUSE (containerd, firefox, grafana, java-1_8_0-openjdk, libtpms, net-snmp, and wireshark), and Ubuntu (pillow).
corbet

Everything Open call for proposals

2 év 8 hónap óta
Everything Open is, seemingly, the future form of the conference once known as linux.conf.au; see this page for a discussion of the reasoning behind the change. The inaugural event will be held March 14 to 16 in Melbourne, Australia, and the call for proposals has gone out now, with a deadline of January 15. "Our aim is to create a deeply technical conference where we bring together industry leaders and experts on a wide range of subjects."
corbet

rpki-client 8.2 released

2 év 8 hónap óta
A new release of the OpenBSD rpki-client, a key component in BGP routing security is available.

The announcement by Sebastian Benoit (benno@) reads,

From: Sebastian Benoit <benno () openbsd ! org> Date: Tue, 13 Dec 2022 23:18:32 +0000 To: openbsd-tech Subject: rpki-client 8.2 released rpki-client 8.2 has just been released and will be available in the rpki-client directory of any OpenBSD mirror soon. rpki-client is a FREE, easy-to-use implementation of the Resource Public Key Infrastructure (RPKI) for Relying Parties (RP) to facilitate validation of BGP announcements. The program queries the global RPKI repository system and validates untrusted network inputs. The program outputs validated ROA payloads, BGPsec Router keys, and ASPA payloads in configuration formats suitable for OpenBGPD and BIRD, and supports emitting CSV and JSON for consumption by other routing stacks.

Read more…

Aktívan kihasznált zero day sérülékenységet javított az Apple

2 év 8 hónap óta

Az Apple biztonsági frissítést adott ki az iOS/iPadOS 15.7.2, a Safari 16.2, a tvOS 16.2 és a macOS Ventura 13.1 rendszerekhez, ugyanis egy feltehetően aktívan kihasznált zero day sérülékenységet fedeztek fel a felsorolt szoftverek korábbi verzióiban.

The post Aktívan kihasznált zero day sérülékenységet javított az Apple first appeared on Nemzeti Kibervédelmi Intézet.

NKI

Matthew Garrett: Trying to remove the need to trust cloud providers

2 év 8 hónap óta
First up: what I'm covering here is probably not relevant for most people. That's ok! Different situations have different threat models, and if what I'm talking about here doesn't feel like you have to worry about it, that's great! Your life is easier as a result. But I have worked in situations where we had to care about some of the scenarios I'm going to describe here, and the technologies I'm going to talk about here solve a bunch of these problems.

So. You run a typical VM in the cloud. Who has access to that VM? Well, firstly, anyone who has the ability to log into the host machine with administrative capabilities. With enough effort, perhaps also anyone who has physical access to the host machine. But the hypervisor also has the ability to inspect what's running inside a VM, so anyone with the ability to install a backdoor into the hypervisor could theoretically target you. And who's to say the cloud platform launched the correct image in the first place? The control plane could have introduced a backdoor into your image and run that instead. Or the javascript running in the web UI that you used to configure the instance could have selected a different image without telling you. Anyone with the ability to get a (cleverly obfuscated) backdoor introduced into quite a lot of code could achieve that. Obviously you'd hope that everyone working for a cloud provider is honest, and you'd also hope that their security policies are good and that all code is well reviewed before being committed. But when you have several thousand people working on various components of a cloud platform, there's always the potential for something to slip up.

Let's imagine a large enterprise with a whole bunch of laptops used by developers. If someone has the ability to push a new package to one of those laptops, they're in a good position to obtain credentials belonging to the user of that laptop. That means anyone with that ability effectively has the ability to obtain arbitrary other privileges - they just need to target someone with the privilege they want. You can largely mitigate this by ensuring that the group of people able to do this is as small as possible, and put technical barriers in place to prevent them from pushing new packages unilaterally.

Now imagine this in the cloud scenario. Anyone able to interfere with the control plane (either directly or by getting code accepted that alters its behaviour) is in a position to obtain credentials belonging to anyone running in that cloud. That's probably a much larger set of people than have the ability to push stuff to laptops, but they have much the same level of power. You'll obviously have a whole bunch of processes and policies and oversights to make it difficult for a compromised user to do such a thing, but if you're a high enough profile target it's a plausible scenario.

How can we avoid this? The easiest way is to take the people able to interfere with the control plane out of the loop. The hypervisor knows what it booted, and if there's a mechanism for the VM to pass that information to a user in a trusted way, you'll be able to detect the control plane handing over the wrong image. This can be achieved using trusted boot. The hypervisor-provided firmware performs a "measurement" (basically a cryptographic hash of some data) of what it's booting, storing that information in a virtualised TPM. This TPM can later provide a signed copy of the measurements on demand. A remote system can look at these measurements and determine whether the system is trustworthy - if a modified image had been provided, the measurements would be different. As long as the hypervisor is trustworthy, it doesn't matter whether or not the control plane is - you can detect whether you were given the correct OS image, and you can build your trust on top of that.

(Of course, this depends on you being able to verify the key used to sign those measurements. On real hardware the TPM has a certificate that chains back to the manufacturer and uniquely identifies the TPM. On cloud platforms you typically have to retrieve the public key via the metadata channel, which means you're trusting the control plane to give you information about the hypervisor in order to verify what the control plane gave to the hypervisor. This is suboptimal, even though realistically the number of moving parts in that part of the control plane is much smaller than the number involved in provisioning the instance in the first place, so an attacker managing to compromise both is less realistic. Still, AWS doesn't even give you that, which does make it all rather more complicated)

Ok, so we can (largely) decouple our trust in the VM from having to trust the control plane. But we're still relying on the hypervisor to provide those attestations. What if the hypervisor isn't trustworthy? This sounds somewhat ridiculous (if you can't run a trusted app on top of an untrusted OS, how can you run a trusted OS on top of an untrusted hypervisor?), but AMD actually have a solution for that. SEV ("Secure Encrypted Virtualisation") is a technology where (handwavily) an encryption key is generated when a new VM is created, and the memory belonging to that VM is encrypted with that key. The hypervisor has no access to that encryption key, and any access to memory initiated by the hypervisor will only see the encrypted content. This means that nobody with the ability to tamper with the hypervisor can see what's going on inside the OS (and also means that nobody with physical access can either, so that's another threat dealt with).

But how do we know that the hypervisor set this up, and how do we know that the correct image was booted? SEV has support for a "Launch attestation", a CPU generated signed statement that it booted the current VM with SEV enabled. But it goes further than that! The attestation includes a measurement of what was booted, which means we don't need to trust the hypervisor at all - the CPU itself will tell us what image we were given. Perfect.

Except, well. There's a few problems. AWS just doesn't have any VMs that implement SEV yet (there are bare metal instances that do, but obviously you're building your own infrastructure to make that work). Google only seem to provide the launch measurement via the logging service - and they only include the parsed out data, not the original measurement. So, we still have to trust (a subset of) the control plane. Azure provides it via a separate attestation service, but again it doesn't seem to provide the raw attestation and so you're still trusting the attestation service. For the newest generation of SEV, SEV-SNP, this is less of a big deal because the guest can provide its own attestation. But Google doesn't offer SEV-SNP hardware yet, and the driver you need for this only shipped in Linux 5.19 and Azure's SEV Ubuntu images only offer up to 5.15 at the moment, so making use of that means you're putting your own image together at the moment.

And there's one other kind of major problem. A normal VM image provides a bootloader and a kernel and a filesystem. That bootloader needs to run on something. That "something" is typically hypervisor-provided "firmware" - for instance, OVMF. This probably has some level of cloud vendor patching, and they probably don't ship the source for it. You're just having to trust that the firmware is trustworthy, and we're talking about trying to avoid placing trust in the cloud provider. Azure has a private beta allowing users to upload images that include their own firmware, meaning that all the code you trust (outside the CPU itself) can be provided by the user, and once that's GA it ought to be possible to boot Azure VMs without having to trust any Microsoft-provided code.

Well, mostly. As AMD admit, SEV isn't guaranteed to be resistant to certain microarchitectural attacks. This is still much more restrictive than the status quo where the hypervisor could just read arbitrary content out of the VM whenever it wanted to, but it's still not ideal. Which, to be fair, is where we are with CPUs in general.

(Thanks to Leonard Cohnen who gave me a bunch of excellent pointers on this stuff while I was digging through it yesterday)

comments

[$] The return of lazy imports for Python

2 év 8 hónap óta
Back in September, we looked at a Python Enhancement Proposal (PEP) to add "lazy" imports to the language; the execution of such an import would be deferred until its symbols were needed in order to save program-startup time. While the problem of startup time for short-running, often command-line-oriented, tools is widely acknowledged in the Python community, and the idea of deferring imports is generally popular, there are concerns about the effect of the feature on the ecosystem as a whole. Since our article, the PEP has been revised and discussed further, but the feature was recently rejected by the steering council (SC) because of those concerns; that has not completely ended the quest for lazy imports, however.
jake

Miller: Upcoming releases and more fun stuff

2 év 8 hónap óta
Bugzilla project lead Dave Miller has posted a plan for several upcoming releases of the bug-tracking tool. The post starts with: "Surprise! Bugzilla’s not dead yet. :-)". It is, in effect, an update to his August posting to the Bugzilla developers mailing list. In the new post, he outlines the plan for releases of multiple branches, lists specific areas where help is needed, and describes some project infrastructure improvements. I would like to put out a new multi-branch release of Bugzilla as soon as we can get all the pieces in place to do so. I was hoping to do this within a few weeks of the original post to the developers list, but that was back in August and it hasn’t happened yet. At this point I think we’ll be really lucky if it happens before the end of December; though mid-January is definitely a possibility. As a forewarning to everyone, there will be security content in it, and that’s part of the holdup.
jake

Security updates for Tuesday

2 év 8 hónap óta
Security updates have been issued by Debian (node-tar and pngcheck), SUSE (colord, containerd, and tiff), and Ubuntu (containerd, linux-azure, linux-azure, linux-azure-5.4, linux-oem-5.17, and vim).
corbet

Git 2.39.0 released

2 év 8 hónap óta
Version 2.39.0 of the Git source-code management system is out. "It is comprised of 483 non-merge commits since v2.38.0, contributed by 86 people, 31 of which are new faces". This release seems to mostly offer incremental improvements; see the announcement or this GitHub blog post for details.
corbet

A Chrome-nál is beköszönt a jelszómentesség

2 év 8 hónap óta

A Google – mintegy két hónapos tesztidőszak után – bevezette a Passkey funkciót a Chrome 108-as verziójában, ami Windows 11, macOS és Android rendszereken érhető el. Ahogy azt egy korábbi IT biztonsági tippünkben már említettük, a Passkey használatával a WebAuthentication (vagy „WebAuthn”) szabványra épülő hitelesítési folyamat során a felhasználók biometrikus azonosítással, például Face ID vagy […]

The post A Chrome-nál is beköszönt a jelszómentesség first appeared on Nemzeti Kibervédelmi Intézet.

NKI

LibreSSL 3.7.0 Released

2 év 8 hónap óta
A new development release of LibreSSL is out, and should be arriving on a mirror near you shortly.

Brent Cook (bcook@)'s announcement reads,

We have released LibreSSL 3.7.0, which will be arriving in the LibreSSL directory of your local OpenBSD mirror soon. This is a development release from the 3.7.x branch, which will eventually ship with OpenBSD 7.3.

Read more…

[$] Development statistics for the 6.1 kernel (and beyond)

2 év 8 hónap óta
The 6.1 kernel was released on December 11; by the time of this release, 13,942 non-merge changesets had been pulled into the mainline, growing the kernel by 412,000 lines of code. This is thus not the busiest development cycle ever, but neither is it the slowest, and those changesets contained a number of fundamental changes. This release will also be the long-term-support kernel for 2022. Read on for a look at where the work in 6.1 came from.
corbet

Security updates for Monday

2 év 8 hónap óta
Security updates have been issued by Debian (cacti, grub2, hsqldb, node-eventsource, and openexr), Fedora (bcel, keylime, rust-capnp, rust-sequoia-octopus-librnp, xfce4-screenshooter, and xfce4-settings), Oracle (nodejs:18), Scientific Linux (grub2), Slackware (libarchive), SUSE (go1.18, go1.19, nautilus, opera, python-slixmpp, and samba), and Ubuntu (python2.7, python3.5, qemu, and squid3).
jake

Matthew Garrett: Quick update on Pluton and Linux

2 év 8 hónap óta
I've been ridiculously burned out for a while now but I'm taking the month off to recover and that's giving me an opportunity to catch up on a lot of stuff. This has included me actually writing some code to work with the Pluton in my Thinkpad Z13. I've learned some more stuff in the process, but based on everything I know I'd still say that in its current form Pluton isn't a threat to free software.

So, first up: by default on the Z13, Pluton is disabled. It's not obviously exposed to the OS at all, which also means there's no obvious mechanism for Microsoft to push out a firmware update to it via Windows Update. The Windows drivers that bind to Pluton don't load in this configuration. It's theoretically possible that there's some hidden mechanism to re-enable it at runtime, but that code doesn't seem to be in Windows at the moment. I'm reasonably confident that "Disabled" is pretty genuinely disabled.

Second, when enabled, Pluton exposes two separate devices. The first of these has an MSFT0101 identifier in ACPI, which is the ID used for a TPM 2 device. The Pluton TPM implementation doesn't work out of the box with existing TPM 2 drivers, though, because it uses a custom start method. TPM 2 devices commonly use something called a "Command Response Buffer" architecture, where a command is written into a buffer, the TPM is told to do a thing, and the response to the command ends up in another buffer. The mechanism to tell the TPM to do a thing varies, and an ACPI table exposed to the OS defines which of those various things should be used for a given TPM. Pluton systems have a mechanism that isn't defined in the existing version of the spec (1.3 rev 8 at the time of writing), so I had to spend a while staring hard at the Windows drivers to figure out how to implement it. The good news is that I now have a patch that successfully gets the existing Linux TPM driver code work correctly with the Pluton implementation.

The second device has an MSFT0200 identifier, and is entirely not a TPM. The Windows driver appears to be a relatively thin layer that simply takes commands from userland and passes them on to the chip - I haven't found any userland applications that make use of this, so it's tough to figure out what functionality is actually available. But what does seem pretty clear from the code I've looked at is that it's a component that only responds when it's asked - if the OS never sends it any commands, it's not able to do anything.

One key point from this recently published Microsoft doc is that the whole "Microsoft can update Pluton firmware" thing does just seem to be the ability for the OS to push new code to the chip at runtime. That means Microsoft can't arbitrarily push new firmware to the chip - the OS needs to be involved. This is unsurprising, but it's nice to see some stronger confirmation of that.

Anyway. tl;dr - Pluton can (now) be used as a regular TPM. Pluton also exposes some additional functionality which is not yet clear, but there's no obvious mechanism for it to compromise user privacy or restrict what users can run on a Free operating system. The Pluton firmware update mechanism appears to be OS mediated, so users who control their OS can simply choose not to opt in to that.

comments