Secure Boot

4 Articles

This Week In Security: Another Record Patch Tuesday, LAME Is More Secure, Secure Boot Is Less Secure, And Milk Malware

July 17, 2026 by 18 Comments

Following the reports last week using the Windows Global Device ID (GDID) in tracking a malware operators behavior, here is a comprehensive write-up about what goes into the GDID and how it is used. It’s worth noting that the GDID itself was not used to catch the malware operator, however once a suspect was identified, the GDID was used to correlate behavior across various Microsoft products on the Internet.

The GDID is generated and assigned during a Windows install, but a re-install of Windows will generate a new GDID. Developer [SmtimesIWndr] tracks the generation and tracking of the GDID through the various Windows libraries and services, identifying where it appears to be created and how it is passed to other services like Azure.

Worth noting is your GDID is a unique, personally identifiable piece of information; if you go exploring and extract it from your Windows install, be sure to keep it private!

LAME mp3 updates

Those of us who were around for the dawn of MP3 files may remember the LAME encoder and library. After almost 10 years, there is a new LAME release.

Notably, this includes two security fixes, one for a stack buffer overflow based on malicious input to the Blade encoder, and an integer underflow in the AIFF header parser. Both of the fixed bugs feel very old-school, which seems appropriate given the age of the library and most of the related code.

Buffer overflows impacting the stack are some of the simplest and most direct forms of vulnerabilities, where it is possible to write past the end of a buffer and control how the function returns and instead execute arbitrary code. Integer under-flows, similarly, impact memory management; usually caused by allowing a variable that stores the size of a buffer to go negative. Since sizes are typically unsigned positive numbers, a negative is interpreted as an enormous positive number, writing past the proper buffer length.

Despite the new findings, the LAME codebase has been extremely resilient over the years, and considering the number of programs that likely still use LAME under the covers to process audio, seeing the project wake up with security fixes is great news.

Recovering Passwords from BIOS

Researchers have found a vulnerability in Dell BIOS code that allows extraction of the administrator password from the BIOS flash chips, either with physical access via a flash programmer, or via administrator or root level access to the operating system and reading the contents of the flash chip.

Dell used a 20 byte key to encrypt a 32 byte password field: for any admin password of 12 characters or fewer, the password is stored in completely plaintext. For longer passwords, characters beyond the first 12 are encrypted – but the random bytes are computed from the first character of the password mixed with fixed device data, yielding only 256 possible encryption seeds for the remaining bytes.

Using the BIOS admin password for evil requires local access, so the attack surface is small, however as the researchers note it controls the boot order and may allow an attacker with physical access to then boot an unsigned OS or bypass full-disk encryption, so it’s serious.

Continue reading “This Week In Security: Another Record Patch Tuesday, LAME Is More Secure, Secure Boot Is Less Secure, And Milk Malware” →

This Week In Security: Sharepoint, Initramfs, And More

July 25, 2025 by 12 Comments

There was a disturbance in the enterprise security world, and it started with a Pwn2Own Berlin. [Khoa Dinh] and the team at Viettel Cyber Security discovered a pair of vulnerabilities in Microsoft’s SharePoint. They were demonstrated at the Berlin competition in May, and patched by Microsoft in this month’s Patch Tuesday.

This original exploit chain is interesting in itself. It’s inside the SharePoint endpoint, /_layouts/15/ToolPane.aspx. The code backing this endpoint has a complex authentication and validation check. Namely, if the incoming request isn’t authenticated, the code checks for a flag, which is set true when the referrer header points to a sign-out page, which can be set arbitrarily by the requester. The DisplayMode value needs set to Edit, but that’s accessible via a simple URL parameter. The pagePath value, based on the URL used in the call, needs to start with /_layouts/ and end with /ToolPane.aspx. That particular check seems like a slam dunk, given that we’re working with the ToolPane.aspx endpoint. But to bypass the DisplayMode check, we added a parameter to the end of the URL, and hilariously, the pagePath string includes those parameters. The simple work-around is to append another parameter, foo=/ToolPane.aspx.

Putting it together, this means a POST of /_layouts/15/ToolPane.aspx?DisplayMode=Edit&foo=/ToolPane.aspx with the Referrer header set to /_layouts/SignOut.aspx. This approach bypasses authentication, and allows a form parameter MSOTlPn_DWP to be specified. These must be a valid file on the target’s filesystem, in the _controltemplates/ directory, ending with .iscx. But it grants access to all of the internal controls on the SafeControls list.

There’s an entire second half to [Khoa Dinh]’s write-up, detailing the discovery of a deserialization bug in one of those endpoints, that also uses a clever type-confusion sort of attack. The end result was remote code execution on the SharePoint target, with a single, rather simple request. Microsoft rolled out patches to fix the exploit chain. The problem is that Microsoft often opts to fix vulnerabilities with minimal code changes, often failing to fix the underlying code flaws. This apparently happened in this case, as the authentication bypass fix could be defeated simply by adding yet another parameter to the URL.

These bypasses were found in the wild on July 19th, and Microsoft quickly confirmed. The next day, the 20th, Microsoft issued an emergency patch to address the bypasses. The live exploitation appears to be coming from a set of Chinese threat actors, with a post-exploitation emphasis on stealing data and maintaining access. There seem to be more than 400 compromised systems worldwide, with some of those being rather high profile.

Continue reading “This Week In Security: Sharepoint, Initramfs, And More” →

This Week In Security: Broken Shims, LassPass, And Toothbrushes?

February 9, 2024 by 8 Comments

Linux has a shim problem. Which naturally leads to a reasonable question: What’s a shim, and why do we need it? The answer: Making Linux work wit Secure Boot, and an unintended quirk of the GPLv3.

Secure Boot is the verification scheme in modern machines that guarantees that only a trusted OS can boot. When Secure Boot was first introduced, many Linux fans suggested it was little more than an attempt to keep Linux distros off of consumer’s machines. That fear seems to have been unwarranted, as Microsoft has dutifully kept the Linux Shim signed, so we can all run Linux distros on our Secure Boot machines.

So the shim. It’s essentially a first-stage bootloader, that can boot a signed GRUB2 or other target. You might ask, why can’t we just ask Microsoft to sign GRUB2 directly? And that’s where the GPLv3 comes in. That license has an “anti-tivoization” section, which specifies “Installation Information” as part of what must be provided as part of GPLv3 compliance. And Microsoft’s legal team understands that requirement to apply to even this signing process. And it would totally defeat the point of Secure Boot to release the keys, so no GPLv3 code gets signed. Instead, we get the shim.

Now that we understand the shim, let’s cover how it’s broken. The most serious vulnerability is a buffer overflow in the HTTP file transfer code. The buffer is allocated based on the size in the HTTP header, but a malicious HTTP server can set that value incorrectly, and the shim code would happily write the real HTTP contents past the end of that buffer, leading to arbitrary code execution. You might ask, why in the world does the shim have HTTP code in it at all? The simple answer is to support UEFI HTTP Boot, a replacement for PXE boot.

The good news is that this vulnerability can only be triggered when using HTTP boot, and only by connecting to a malicious server or via a man-in-the-middle attack. With this in mind, it’s odd that this vulnerability is rated a 9.8. Specifically, it seems incorrect that this bug is rated low complexity, or a general network attack vector. In Red Hat’s own write-up of the vulnerability, they argue that the exploitation is high complexity, and is only possible from an adjacent network. There were a handful of lesser vulnerabilities found, and these were all fixed with shim 15.8. Continue reading “This Week In Security: Broken Shims, LassPass, And Toothbrushes?” →

This Week In Security: .zip Domains, Zip Scanning

May 19, 2023 by 17 Comments

The world may not be ready, but the .zip Top Level Domain (TLD) is here. It’s a part of the generic TLD category, which was expanded to allow applications for custom TLDs. Google has led the charge, applying for 101 such new TLDs, with .zip being one of the interesting ones. Public registration for .zip domains has been open for a couple weeks, and some interesting domains have been registered, like update.zip, installer.zip, and officeupdate.zip.

The obvious question to ask is whether this new TLD can be abused for scamming and phishing purposes. And the answer is yes, sure it can. One of the trickiest ways is to use the AT symbol @ in a URL, which denotes user info at the beginning of the URL. It usually is used to include a username and password, like http://username:password@192.168.1.1/. That is pretty obvious, but what about https://google.com@bing.com? Still looks weird. The catch that really prevents this technique being abused is that slashes are disallowed in user data, so a abusive URL like https://google.com∕gmail∕inbox@bing.com is right out.

Except, take a look at that last link. Looks like it has slashes in it, so it should take you to google, and ignore the AT symbol. But it doesn’t, it goes to Bing. You may have guessed, it’s Unicode shenanigans again. Those aren’t slashes, they’re U2215, the division slash. And that means that a .zip TLD could be really sneaky, if the apparent domain is one you trust. Continue reading “This Week In Security: .zip Domains, Zip Scanning” →