Hírolvasó
Frissítsen, zero-day sérülékenységet javítottak a Chrome-ban!
malloc leak detection available in -current
OpenBSD -current just grew a new tool for developers working on OpenBSD to detect unsafe behaviors in their code. OpenBSD lets you more easily track memory allocations and whether allocations are properly freed after use.
In a message to tech@, Otto Moerbeek (otto@) announced the new functionality:
Subject: malloc leak detection available in -current From: Otto Moerbeek <otto () drijf ! net> Date: 2023-04-17 6:43:19 Hi, OpenBSD current now has built-in malloc leak detection. Make sure you run current and have debug symbols (OpenBSD base libraries have debug symbols, compile your own program with -g).
Matthew Garrett: Booting modern Intel CPUs
CPUs can't do anything without being told what to do, which leaves the obvious problem of how do you tell a CPU to do something in the first place. On many CPUs this is handled in the form of a reset vector - an address the CPU is hardcoded to start reading instructions from when power is applied. The address the reset vector points to will typically be some form of ROM or flash that can be read by the CPU even if no other hardware has been configured yet. This allows the system vendor to ship code that will be executed immediately after poweron, configuring the rest of the hardware and eventually getting the system into a state where it can run user-supplied code.
The specific nature of the reset vector on x86 systems has varied over time, but it's effectively always been 16 bytes below the top of the address space - so, 0xffff0 on the 20-bit 8086, 0xfffff0 on the 24-bit 80286, and 0xfffffff0 on the 32-bit 80386. Convention on x86 systems is to have RAM starting at address 0, so the top of address space could be used to house the reset vector with as low a probability of conflicting with RAM as possible.
The most notable thing about x86 here, though, is that when it starts running code from the reset vector, it's still in real mode. x86 real mode is a holdover from a much earlier era of computing. Rather than addresses being absolute (ie, if you refer to a 32-bit address, you store the entire address in a 32-bit or larger register), they are 16-bit offsets that are added to the value stored in a "segment register". Different segment registers existed for code, data, and stack, so a 16-bit address could refer to different actual addresses depending on how it was being interpreted - jumping to a 16 bit address would result in that address being added to the code segment register, while reading from a 16 bit address would result in that address being added to the data segment register, and so on. This is all in order to retain compatibility with older chips, to the extent that even 64-bit x86 starts in real mode with segments and everything (and, also, still starts executing at 0xfffffff0 rather than 0xfffffffffffffff0 - 64-bit mode doesn't support real mode, so there's no way to express a 64-bit physical address using the segment registers, so we still start just below 4GB even though we have massively more address space available).
Anyway. Everyone knows all this. For modern UEFI systems, the firmware that's launched from the reset vector then reprograms the CPU into a sensible mode (ie, one without all this segmentation bullshit), does things like configure the memory controller so you can actually access RAM (a process which involves using CPU cache as RAM, because programming a memory controller is sufficiently hard that you need to store more state than you can fit in registers alone, which means you need RAM, but you don't have RAM until the memory controller is working, but thankfully the CPU comes with several megabytes of RAM on its own in the form of cache, so phew). It's kind of ugly, but that's a consequence of a bunch of well-understood legacy decisions.
Except. This is not how modern Intel x86 boots. It's far stranger than that. Oh, yes, this is what it looks like is happening, but there's a bunch of stuff going on behind the scenes. Let's talk about boot security. The idea of any form of verified boot (such as UEFI Secure Boot) is that a signature on the next component of the boot chain is validated before that component is executed. But what verifies the first component in the boot chain? You can't simply ask the BIOS to verify itself - if an attacker can replace the BIOS, they can replace it with one that simply lies about having done so. Intel's solution to this is called Boot Guard.
But before we get to Boot Guard, we need to ensure the CPU is running in as bug-free a state as possible. So, when the CPU starts up, it examines the system flash and looks for a header that points at CPU microcode updates. Intel CPUs ship with built-in microcode, but it's frequently old and buggy and it's up to the system firmware to include a copy that's new enough that it's actually expected to work reliably. The microcode image is pulled out of flash, a signature is verified, and the new microcode starts running. This is true in both the Boot Guard and the non-Boot Guard scenarios. But for Boot Guard, before jumping to the reset vector, the microcode on the CPU reads an Authenticated Code Module (ACM) out of flash and verifies its signature against a hardcoded Intel key. If that checks out, it starts executing the ACM. Now, bear in mind that the CPU can't just verify the ACM and then execute it directly from flash - if it did, the flash could detect this, hand over a legitimate ACM for the verification, and then feed the CPU different instructions when it reads them again to execute them (a Time of Check vs Time of Use, or TOCTOU, vulnerability). So the ACM has to be copied onto the CPU before it's verified and executed, which means we need RAM, which means the CPU already needs to know how to configure its cache to be used as RAM.
Anyway. We now have an ACM loaded and verified, and it can safely be executed. The ACM does various things, but the most important from the Boot Guard perspective is that it reads a set of write-once fuses in the motherboard chipset that represent the SHA256 of a public key. It then reads the initial block of the firmware (the Initial Boot Block, or IBB) into RAM (or, well, cache, as previously described) and parses it. There's a block that contains a public key - it hashes that key and verifies that it matches the SHA256 from the fuses. It then uses that key to validate a signature on the IBB. If it all checks out, it executes the IBB and everything starts looking like the nice simple model we had before.
Except, well, doesn't this seem like an awfully complicated bunch of code to implement in real mode? And yes, doing all of this modern crypto with only 16-bit registers does sound like a pain. So, it doesn't. All of this is happening in a perfectly sensible 32 bit mode, and the CPU actually switches back to the awful segmented configuration afterwards so it's still compatible with an 80386 from 1986. The "good" news is that at least firmware can detect that the CPU has already configured the cache as RAM and can skip doing that itself.
I'm skipping over some steps here - the ACM actually does other stuff around measuring the firmware into the TPM and doing various bits of TXT setup for people who want DRTM in their lives, but the short version is that the CPU bootstraps itself into a state where it works like a modern CPU and then deliberately turns a bunch of the sensible functionality off again before it starts executing firmware. I'm also missing out the fact that this entire process only kicks off after the Management Engine says it can, which means we're waiting for an entirely independent x86 to boot an entire OS before our CPU even starts pretending to execute the system firmware.
Of course, as mentioned before, on modern systems the firmware will then reprogram the CPU into something actually sensible so OS developers no longer need to care about this[1][2], which means we've bounced between multiple states for no reason other than the possibility that someone wants to run legacy BIOS and then boot DOS on a CPU with like 5 orders of magnitude more transistors than the 8086.
tl;dr why can't my x86 wake up with the gin protected mode already inside it
[1] Ha uh except that on ACPI resume we're going to skip most of the firmware setup code so we still need to handle the CPU being in fucking 16-bit mode because suspend/resume is basically an extremely long reboot cycle
[2] Oh yeah also you probably have multiple cores on your CPU and well bad news about the state most of the cores are in when the OS boots because the firmware never started them up so they're going to come up in 16-bit real mode even if your boot CPU is already in 64-bit protected mode, unless you were using TXT in which case you have a different sort of nightmare that if we're going to try to map it onto real world nightmare concepts is one that involves a lot of teeth. Or, well, that used to be the case, but ACPI 6.4 (released in 2021) provides a mechanism for the OS to ask the firmware to wake the CPU up for it so this is invisible to the OS, but you're still relying on the firmware to actually do the heavy lifting here
comments
The specific nature of the reset vector on x86 systems has varied over time, but it's effectively always been 16 bytes below the top of the address space - so, 0xffff0 on the 20-bit 8086, 0xfffff0 on the 24-bit 80286, and 0xfffffff0 on the 32-bit 80386. Convention on x86 systems is to have RAM starting at address 0, so the top of address space could be used to house the reset vector with as low a probability of conflicting with RAM as possible.
The most notable thing about x86 here, though, is that when it starts running code from the reset vector, it's still in real mode. x86 real mode is a holdover from a much earlier era of computing. Rather than addresses being absolute (ie, if you refer to a 32-bit address, you store the entire address in a 32-bit or larger register), they are 16-bit offsets that are added to the value stored in a "segment register". Different segment registers existed for code, data, and stack, so a 16-bit address could refer to different actual addresses depending on how it was being interpreted - jumping to a 16 bit address would result in that address being added to the code segment register, while reading from a 16 bit address would result in that address being added to the data segment register, and so on. This is all in order to retain compatibility with older chips, to the extent that even 64-bit x86 starts in real mode with segments and everything (and, also, still starts executing at 0xfffffff0 rather than 0xfffffffffffffff0 - 64-bit mode doesn't support real mode, so there's no way to express a 64-bit physical address using the segment registers, so we still start just below 4GB even though we have massively more address space available).
Anyway. Everyone knows all this. For modern UEFI systems, the firmware that's launched from the reset vector then reprograms the CPU into a sensible mode (ie, one without all this segmentation bullshit), does things like configure the memory controller so you can actually access RAM (a process which involves using CPU cache as RAM, because programming a memory controller is sufficiently hard that you need to store more state than you can fit in registers alone, which means you need RAM, but you don't have RAM until the memory controller is working, but thankfully the CPU comes with several megabytes of RAM on its own in the form of cache, so phew). It's kind of ugly, but that's a consequence of a bunch of well-understood legacy decisions.
Except. This is not how modern Intel x86 boots. It's far stranger than that. Oh, yes, this is what it looks like is happening, but there's a bunch of stuff going on behind the scenes. Let's talk about boot security. The idea of any form of verified boot (such as UEFI Secure Boot) is that a signature on the next component of the boot chain is validated before that component is executed. But what verifies the first component in the boot chain? You can't simply ask the BIOS to verify itself - if an attacker can replace the BIOS, they can replace it with one that simply lies about having done so. Intel's solution to this is called Boot Guard.
But before we get to Boot Guard, we need to ensure the CPU is running in as bug-free a state as possible. So, when the CPU starts up, it examines the system flash and looks for a header that points at CPU microcode updates. Intel CPUs ship with built-in microcode, but it's frequently old and buggy and it's up to the system firmware to include a copy that's new enough that it's actually expected to work reliably. The microcode image is pulled out of flash, a signature is verified, and the new microcode starts running. This is true in both the Boot Guard and the non-Boot Guard scenarios. But for Boot Guard, before jumping to the reset vector, the microcode on the CPU reads an Authenticated Code Module (ACM) out of flash and verifies its signature against a hardcoded Intel key. If that checks out, it starts executing the ACM. Now, bear in mind that the CPU can't just verify the ACM and then execute it directly from flash - if it did, the flash could detect this, hand over a legitimate ACM for the verification, and then feed the CPU different instructions when it reads them again to execute them (a Time of Check vs Time of Use, or TOCTOU, vulnerability). So the ACM has to be copied onto the CPU before it's verified and executed, which means we need RAM, which means the CPU already needs to know how to configure its cache to be used as RAM.
Anyway. We now have an ACM loaded and verified, and it can safely be executed. The ACM does various things, but the most important from the Boot Guard perspective is that it reads a set of write-once fuses in the motherboard chipset that represent the SHA256 of a public key. It then reads the initial block of the firmware (the Initial Boot Block, or IBB) into RAM (or, well, cache, as previously described) and parses it. There's a block that contains a public key - it hashes that key and verifies that it matches the SHA256 from the fuses. It then uses that key to validate a signature on the IBB. If it all checks out, it executes the IBB and everything starts looking like the nice simple model we had before.
Except, well, doesn't this seem like an awfully complicated bunch of code to implement in real mode? And yes, doing all of this modern crypto with only 16-bit registers does sound like a pain. So, it doesn't. All of this is happening in a perfectly sensible 32 bit mode, and the CPU actually switches back to the awful segmented configuration afterwards so it's still compatible with an 80386 from 1986. The "good" news is that at least firmware can detect that the CPU has already configured the cache as RAM and can skip doing that itself.
I'm skipping over some steps here - the ACM actually does other stuff around measuring the firmware into the TPM and doing various bits of TXT setup for people who want DRTM in their lives, but the short version is that the CPU bootstraps itself into a state where it works like a modern CPU and then deliberately turns a bunch of the sensible functionality off again before it starts executing firmware. I'm also missing out the fact that this entire process only kicks off after the Management Engine says it can, which means we're waiting for an entirely independent x86 to boot an entire OS before our CPU even starts pretending to execute the system firmware.
Of course, as mentioned before, on modern systems the firmware will then reprogram the CPU into something actually sensible so OS developers no longer need to care about this[1][2], which means we've bounced between multiple states for no reason other than the possibility that someone wants to run legacy BIOS and then boot DOS on a CPU with like 5 orders of magnitude more transistors than the 8086.
tl;dr why can't my x86 wake up with the gin protected mode already inside it
[1] Ha uh except that on ACPI resume we're going to skip most of the firmware setup code so we still need to handle the CPU being in fucking 16-bit mode because suspend/resume is basically an extremely long reboot cycle
[2] Oh yeah also you probably have multiple cores on your CPU and well bad news about the state most of the cores are in when the OS boots because the firmware never started them up so they're going to come up in 16-bit real mode even if your boot CPU is already in 64-bit protected mode, unless you were using TXT in which case you have a different sort of nightmare that if we're going to try to map it onto real world nightmare concepts is one that involves a lot of teeth. Or, well, that used to be the case, but ACPI 6.4 (released in 2021) provides a mechanism for the OS to ask the firmware to wake the CPU up for it so this is invisible to the OS, but you're still relying on the firmware to actually do the heavy lifting here
comments
Kernel prepatch 6.3-rc7
The 6.3-rc7 kernel prepatch is out for
testing. "Let's hope we have just one more calm week, and we'll have
had a nice uneventful release cycle. Knock wood".
Duffy: Run an open source-powered virtual conference!
On her blog, Máirín Duffy writes
about using open-source software to run a virtual conference. The Fedora design team
recently ran the first Creative
Freedom Summit as a virtual conference for FOSS creative tools. The team
could have used the same non-open-source platform that is used by the Flock Fedora conference, but took a
different path:
Using Matrix's Element client, we embedded the live stream video and an
Etherpad into a public Matrix room for the conference. We used attendance
in the channel to monitor overall conference attendance. We had live chat
going throughout the conference and took questions from audience members
both from the chat and the embedded Q&A Etherpad.
Back in 2020, the Linux Plumbers Conference also put together a virtual conference using free software, as did LibrePlanet and likely others.
[$] TOTP authentication with free software
One-time passwords (OTPs) are increasingly used as a defense against
phishing and other password-stealing attacks, usually as a part of a
two-factor authentication process. Perhaps the most commonly
used technique is sending a numeric code to a phone via SMS, but SMS OTPs
have security problems of their own. An alternative is to use time-based
one-time passwords (TOTPs). The normal TOTP situation is to have all
of the data locked into a proprietary phone app, but it need not be that
way.
Security updates for Friday
Security updates have been issued by Debian (haproxy and openvswitch), Fedora (bzip3, libyang, mingw-glib2, thunderbird, xorg-x11-server, and xorg-x11-server-Xwayland), and Ubuntu (apport, ghostscript, linux-bluefield, node-thenify, and python-flask-cors).
Stable kernels 6.2.11, 6.1.24, and 5.15.107
[$] Process-level kernel samepage merging control
The kernel
samepage merging (KSM) feature can save significant amounts of memory
with some types of workloads, but security concerns have greatly limited
its use. Even when KSM can be safely enabled, though, the control interface
provided by the kernel makes it unlikely that KSM actually will be used. A
small patch
series from Stefan Roesch aims to change this situation by improving
and simplifying how KSM is managed.
Security updates for Thursday
Security updates have been issued by Debian (chromium, firefox-esr, lldpd, and zabbix), Fedora (ffmpeg, firefox, pdns-recursor, polkit, and thunderbird), Oracle (kernel and nodejs:14), Red Hat (nodejs:14, openvswitch2.17, openvswitch3.1, and pki-core:10.6), Slackware (mozilla), SUSE (nextcloud-desktop), and Ubuntu (exo, linux, linux-kvm, linux-lts-xenial, linux-aws, smarty3, and thunderbird).
Bug bounty programot indít az OpenAI
Az OpenAI mesterséges intelligencia kutatólaboratórium bejelentette, hogy bug bounty programot indít a regisztrált biztonsági kutatók számára, akik így pénzjutalom ellenében bejelenthetik az OpenAI termékcsaládban felfedezett sebezhetőségeket. A jutalom a bejelentett hibák súlyosságától, valamint annak hatásaitól függ, így az összeg 200 dollártól egészen 20.000 dollárig terjedhet. Az OpenAI Bug Bounty Program egy hatékony módja annak, hogy […]
The post Bug bounty programot indít az OpenAI first appeared on Nemzeti Kibervédelmi Intézet.
Adatszivárgás érte a Hyundai olasz és francia ügyfeleit
A Hyundai autógyártó cég nyilvánosságra hozta, hogy egy adatvédelmi incidens következtében a támadók sikeresen hozzáfértek az olasz és francia autótulajdonosok és tesztvezetők adataihoz. A Twitteren közzétett jelentések szerint a kiszivárgott adatok között e-mailcímek, fizikai címek, telefonszámok, illetve a járművek alvázszámai szerepletek, azonban a Hyundai közleménye szerint a támadók pénzügyi adatokhoz és egyéb azonosítókhoz nem fértek […]
The post Adatszivárgás érte a Hyundai olasz és francia ügyfeleit first appeared on Nemzeti Kibervédelmi Intézet.
[$] LWN.net Weekly Edition for April 13, 2023
The LWN.net Weekly Edition for April 13, 2023 is available.
[$] Searching for an elusive orchid pollinator
Orchids are, of course,
flowers, and flowers generally need pollinators
in order to reproduce. A seemingly offhand comment about the unknown nature
of the pollinator(s) for a species of orchid in Western Australia
has led Paul Hamilton to undertake a multi-year citizen-science project to
try to fill that hole. He came to Everything Open 2023 to
give a report on the progress of the search.
[$] The early days of Linux
My name is Lars Wirzenius, and I was there when Linux started. Linux
is now a global success, but its beginnings were rather more humble.
These are my memories of the earliest days of Linux, its creation, and the
start of its path to where it is today.
Security updates for Wednesday
Security updates have been issued by Fedora (chromium, ghostscript, glusterfs, netatalk, php-Smarty, and skopeo), Mageia (ghostscript, imgagmagick, ipmitool, openssl, sudo, thunderbird, tigervnc/x11-server, and vim), Oracle (curl, haproxy, and postgresql), Red Hat (curl, haproxy, httpd:2.4, kernel, kernel-rt, kpatch-patch, and postgresql), Slackware (mozilla), SUSE (firefox), and Ubuntu (dotnet6, dotnet7, firefox, json-smart, linux-gcp, linux-intel-iotg, and sudo).
A ChatGPT használatával titkos céges adatokat szivárogtattak ki a Samsung alkalmazottai
Szigorúan titkos adatok szivárogtak ki a Samsungtól, mert a cég alkalmazottai – bár nem károkozási, hanem tesztelési szándékkal – feltöltötték azokat az egyre népszerűbb ChatGPT szolgáltatásba. A megosztott adatok között belső dokumentumok és forráskódok is szerepeltek, amelyet a Samsung mérnökei tesztelési célzattal adtak át a ChatGPT-nek, hogy az optimalizálja a Samsung által tervezett chipek hibáinak […]
The post A ChatGPT használatával titkos céges adatokat szivárogtattak ki a Samsung alkalmazottai first appeared on Nemzeti Kibervédelmi Intézet.
Újabb zero day sérülékenységek miatt adott ki sürgősségi frissítést az Apple
Az Apple ismét soron kívüli frissítést adott ki múlt hét pénteken, amellyel két – régebbi eszközöket is érintő – nulladik napi sérülékenység került javításra. A cég által hétfőn közzétett közlemény szerint a kiberbűnözők aktívan ki is használják a sebezhetőségeket. A szóban forgó sérülékenységek közül a CVE-2023-28206 olyan out-of-bounds írási hiba az IOSurfaceAccelerator objektumon belül, amelynek […]
The post Újabb zero day sérülékenységek miatt adott ki sürgősségi frissítést az Apple first appeared on Nemzeti Kibervédelmi Intézet.
Újabb kémprogrammal vették célba az iPhone felhasználókat
A Microsoft és a Citizen Lab fedezete fel azt az izraeli székhelyű QuaDream céget, amely az iPhone felhasználók észrevétlen megfigyelésére készített kereskedelmi kémprogramot. A kémprogrammal történő fertőzés során egy ENDOFDAYS elnevezésű zero-click exploit kerül kihasználására. 2021. január és november között az iOS 14 egyes verzióinak nulladik napi sérülékenységeit kihasználva a támadók – a Citizen Lab megfogalmazása szerint […]
The post Újabb kémprogrammal vették célba az iPhone felhasználókat first appeared on Nemzeti Kibervédelmi Intézet.