Hírolvasó

Egy szofisztikált adathalász kampány Microsoft Word dokumentumot használ az Agent Tesla, az OriginBotnet és az OriginLogger nevű káros kódok terjesztésére és információgyűjtésre.

The post Agent Teslát terjeszt egy újabb kifinomult adathalász kampány first appeared on Nemzeti Kibervédelmi Intézet.

Can you really do 3D printing from OpenBSD? Cue suspenseful music whilst I formulate my answer, which is: Yes.

If you aren’t familiar with the 3D printing process, it’s divided into several steps, vaguely analogous to writing, compiling and running a program in a compiled language.

Read more…

A Mac-es termékek népszerűsége miatt egyre több káros kód készül erre a platformra, amire a magánfelhasználók mellett a vállalkozásoknak is érdemes figyelembe venni. A Stealer, Pureland, Atomic Stealer és Realst után újabb macOS-re összpontosító információlopó program jelent meg, a MetaStealer.

The post Egyre több macOS-es káros kód jelenik meg a kiberbűnözői piacon first appeared on Nemzeti Kibervédelmi Intézet.

The LWN.net Weekly Edition for September 14, 2023 is available.

TPMs contain a set of registers ("Platform Configuration Registers", or PCRs) that are used to track what a system boots. Each time a new event is measured, a cryptographic hash representing that event is passed to the TPM. The TPM appends that hash to the existing value in the PCR, hashes that, and stores the final result in the PCR. This means that while the PCR's value depends on the precise sequence and value of the hashes presented to it, the PCR value alone doesn't tell you what those individual events were. Different PCRs are used to store different event types, but there are still more events than there are PCRs so we can't avoid this problem by simply storing each event separately.

This is solved using the event log. The event log is simply a record of each event, stored in RAM. The algorithm the TPM uses to calculate the PCR values is known, so we can reproduce that by simply taking the events from the event log and replaying the series of events that were passed to the TPM. If the final calculated value is the same as the value in the PCR, we know that the event log is accurate, which means we now know the value of each individual event and can make an appropriate judgement regarding its security.

If any value in the event log is invalid, we'll calculate a different PCR value and it won't match. This isn't terribly helpful - we know that at least one entry in the event log doesn't match what was passed to the TPM, but we don't know which entry. That means we can't trust any of the events associated with that PCR. If you're trying to make a security determination based on this, that's going to be a problem.

PCR 7 is used to track information about the secure boot policy on the system. It contains measurements of whether or not secure boot is enabled, and which keys are trusted and untrusted on the system in question. This is extremely helpful if you want to verify that a system booted with secure boot enabled before allowing it to do something security or safety critical. Unfortunately, if the device gives you an event log that doesn't replay correctly for PCR 7, you now have no idea what the security state of the system is.

We ran into that this week. Examination of the event log revealed an additional event other than the expected ones - a measurement accompanied by the string "Boot Guard Measured S-CRTM". Boot Guard is an Intel feature where the CPU verifies the firmware is signed with a trusted key before executing it, and measures information about the firmware in the process. Previously I'd only encountered this as a measurement into PCR 0, which is the PCR used to track information about the firmware itself. But it turns out that at least some versions of Boot Guard also measure information about the Boot Guard policy into PCR 7. The argument for this is that this is effectively part of the secure boot policy - having a measurement of the Boot Guard state tells you whether Boot Guard was enabled, which tells you whether or not the CPU verified a signature on your firmware before running it (as I wrote before, I think Boot Guard has user-hostile default behaviour, and that enforcing this on consumer devices is a bad idea).

But there's a problem here. The event log is created by the firmware, and the Boot Guard measurements occur before the firmware is executed. So how do we get a log that represents them? That one's fairly simple - the firmware simply re-calculates the same measurements that Boot Guard did and creates a log entry after the fact[1]. All good.

Except. What if the firmware screws up the calculation and comes up with a different answer? The entry in the event log will now not match what was sent to the TPM, and replaying will fail. And without knowing what the actual value should be, there's no way to fix this, which means there's no way to verify the contents of PCR 7 and determine whether or not secure boot was enabled.

But there's still a fundamental source of truth - the measurement that was sent to the TPM in the first place. Inspired by Henri Nurmi's work on sniffing Bitlocker encryption keys, I asked a coworker if we could sniff the TPM traffic during boot. The TPM on the board in question uses SPI, a simple bus that can have multiple devices connected to it. In this case the system flash and the TPM are on the same SPI bus, which made things easier. The board had a flash header for external reprogramming of the firmware in the event of failure, and all SPI traffic was visible through that header. Attaching a logic analyser to this header made it simple to generate a record of that. The only problem was that the chip select line on the header was attached to the firmware flash chip, not the TPM. This was worked around by simply telling the analysis software that it should invert the sense of the chip select line, ignoring all traffic that was bound for the flash and paying attention to all other traffic. This worked in this case since the only other device on the bus was the TPM, but would cause problems in the event of multiple devices on the bus all communicating.

With the aid of this analyser plugin, I was able to dump all the TPM traffic and could then search for writes that included the "0182" sequence that corresponds to the command code for a measurement event. This gave me a couple of accesses to the locality 3 registers, which was a strong indication that they were coming from the CPU rather than from the firmware. One was for PCR 0, and one was for PCR 7. This corresponded to the two Boot Guard events that we expected from the event log. The hash in the PCR 0 measurement was the same as the hash in the event log, but the hash in the PCR 7 measurement differed from the hash in the event log. Replacing the event log value with the value actually sent to the TPM resulted in the event log now replaying correctly, supporting the hypothesis that the firmware was failing to correctly reconstruct the event.

What now? The simple thing to do is for us to simply hard code this fixup, but longer term we'd like to figure out how to reconstruct the event so we can calculate the expected value ourselves. Unfortunately there doesn't seem to be any public documentation on this. Sigh.

[1] What stops firmware on a system with no Boot Guard faking those measurements? TPMs have a concept of "localities", effectively different privilege levels. When Boot Guard performs its initial measurement into PCR 0, it does so at locality 3, a locality that's only available to the CPU. This causes PCR 0 to be initialised to a different initial value, affecting the final PCR value. The firmware can't access locality 3, so can't perform an equivalent measurement, so can't fake the value.

comments

The "Common Vulnerabilities and Exposures" (CVE) system was launched late in the previous century (September 1999) to track vulnerabilities in software. Over the years since, it has had a somewhat checkered reputation, along with some some attempts to replace it, but CVE numbers are still the only effective way to track vulnerabilities. While that can certainly be useful, the CVE-assignment (and severity scoring) process is not without its problems. The prominence of CVE numbers, and the consequent increase in "reputation" for a reporter, have combined to create a system that can be—and is—actively gamed. Meanwhile, the organizations that oversee the system are ultimately not doing a particularly stellar job.

The 6.5.3, 6.4.16, and 6.1.53 stable kernel updates have been released; each contains a large number of important fixes. Note that the 6.4.x line ends with 6.4.16.

Security updates have been issued by Debian (e2guardian), Fedora (libeconf), Red Hat (dmidecode, kernel, kernel-rt, keylime, kpatch-patch, libcap, librsvg2, linux-firmware, and qemu-kvm), Slackware (mozilla), SUSE (chromium and shadow), and Ubuntu (cups, dotnet6, dotnet7, file, flac, and ruby-redcloth).

A Kínával összefüggésbe hozott APT csoportok egyre szélesebb körben célozzák a különböző iparágak szervezeteit.

The post A kínai Redfly kritikus infrastruktúrákat céloz a ShadowPad kampányban first appeared on Nemzeti Kibervédelmi Intézet.

A Google szeptember 11-én soron kívüli biztonsági javításokat adott ki a webböngészőjének kritikus biztonsági hibájára, amelyet a vállalat közlése szerint a kiberbűnözők aktívan kihasználnak.

The post Kritikus sebezhetőség a Google Chrome-ban first appeared on Nemzeti Kibervédelmi Intézet.

The GCC stack-protector feature detects stack-based buffer overruns by putting a canary value on the stack and noticing if that value is changed. It turns out, though, that dynamically allocated local variables (such as variable-length arrays and space obtained with alloca()) are placed beyond the canary, so overflows of those variables will not be detected. As a result, arm64 binaries built with vulnerable versions of GCC are not as protected as they should be and need to be rebuilt.

Dynamic allocations are just as susceptible to overflows as other locals. In fact, they're arguably more susceptible because they're almost always arrays, whereas fixed locals are often integers, pointers, or other types to which variable-length data is never written. GCC's own heuristics for when to use a stack guard reflect this.

Kees Cook, meanwhile, has pointed out that the kernel no longer uses variable-length arrays, so kernel builds should not be affected by this vulnerability.

Arduino has emerged as one of the prime success stories of the open-hardware movement. In recent years, the company has shifted its focus toward Internet of Things (IoT) applications. As part of this transformation, it has completely redesigned its open-source integrated development environment (IDE), adding a more professional feature set for its hobbyist target audience. If you have experimented with Arduino in the past, but have lost track of its progress, now might be a good time to give it another try.

Ars Technica reports on a credential-stealing Trojan horse that would infect only some of those who installed the "Free Download Manager". The article is based on a Kaspersky report that details the malicious payload offered up at that site from 2020 to 2022. The site, freedownloadmanager[.]org, offered a benign version of a Linux offering known as the Free Download Manager. Starting in 2020, the same domain at times redirected users to the domain deb.fdmpkg[.]org, which served a malicious version of the app. The version available on the malicious domain contained a script that downloaded two executable files to the /var/tmp/crond and /var/tmp/bs file paths. The script then used the cron job scheduler to cause the file at /var/tmp/crond to launch every 10 minutes. With that, devices that had installed the booby-trapped version of Free Download Manager were permanently backdoored.

Security updates have been issued by Debian (node-cookiejar and orthanc), Oracle (firefox, kernel, and kernel-container), Red Hat (flac and httpd:2.4), Slackware (vim), SUSE (python-Django, terraform-provider-aws, terraform-provider-helm, and terraform-provider-null), and Ubuntu (c-ares, curl, linux-azure, linux-azure-5.15, linux-azure-fde, linux-azure-fde-5.15, linux-raspi, and linux-ibm, linux-ibm-5.4).

Next up in the series of p2k23 hackathon reports is this from Landry Breuil (landry@), who writes,

It's been a while since the last p2k19 in bucarest… and this time in a new place, city, country, lovely ireland with a lovely weather at this time of the year.

As usual, i wanted to play with things that were left on the side for a while (upgrading mail/stalwart stack to the new all-bundled-in-one layout to play with JMAP… or testing matthieu@'s work on wayland) - but i was of course mostly distracted from those interesting topics by …firefox, you guess it. Dammit, not again !

Read more…

Linus Torvalds released 6.6-rc1 and closed the 6.6 merge window on September 10. At that point, 12,230 non-merge changesets had been pulled into the mainline repository, which is exactly 500 more than were pulled for 6.5 at this stage in the cycle. Over 7,000 of those changes were pulled after our first-half summary was written; they brought a fair amount of new functionality with them. Read on for an overview of those changes.

Security updates have been issued by Debian (frr, kernel, libraw, mutt, and open-vm-tools), Fedora (cjose, pypy, vim, wireshark, and xrdp), Gentoo (apache), Mageia (chromium-browser-stable, clamav, ghostscript, librsvg, libtiff, openssl, poppler, postgresql, python-pypdf2, and unrar), Red Hat (flac), SUSE (firefox, geoipupdate, icu73_2, libssh2_org, rekor, skopeo, and webkit2gtk3), and Ubuntu (linux-azure, linux-azure-4.15, linux-azure-5.4, linux-gcp-5.4, linux-gkeop, linux-raspi, linux-raspi-5.4, linux-xilinx-zynqmp, linux-gcp, linux-gcp-6.2, linux-ibm, linux-oracle, linux-starfive, linux-gcp-5.15, linux-gkeop-5.15, and opendmarc).

Linus has released 6.6-rc1 and closed the merge window for this release.

All the stats for 6.6 look fairly normal so far - as always, the bulk of the patch is drivers (a bit of everything, but networking and gpu are the two biggest areas), with arch updates coming in as a notable second, and then we have tooling and documentation.

Next up in our reports from the p2k23 hackathon is one from Jeremy Evans (jeremy@). Jeremy writes:

My travel to Dublin started off not so great, with the airline figuring out they had to replace the copilot's chair in the cockpit after everyone had boarded, forcing everyone to deplane and then reboard an hour later. I ended up getting to Dublin a couple hours later than scheduled. This was the day before the hackathon started, so thankfully I didn't miss any hacking time. After I arrived, I took a brief nap, then found out where the hackroom was.

Read more…

The p2k23 OpenBSD packages hackathon just concluded, and Marc Espie (espie@) wrote in with this report:

Off to Dublin, or almost.

This ports hackathon started with a reminder that real-life bugs do matter: my morning flight was cancelled and I arrived in Dublin late that day.

Turns out that air traffic uses named waypoints, which are supposed to be unique, but there's no central name registry, and two local waypoints ended up with the same name, which caused huge confusion in air traffic to Ireland: planes making large detours. As it turns out, there ARE some safety regulations, so crews can't fly forever, and Aer Lingus had to cancel my flight: no idea whether the plane didn't make it to Paris, or if the crew logged so many hours that they couldn't fly back.
(all of this info courtesy of sthen@ and mlarkin@, one being the thorough guy who always finds out the most obscure details, and the other one having actual flying experience)

Read more…