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.
Patch Tuesday Crushes Records
Last month, Microsoft broke records for the number of security fixes in the June monthly Patch Tuesday roundup. This month, Microsoft broke records for the number of security fixes in the July monthly Patch Tuesday roundup.
This month includes a record 60 plus patches for critical vulnerabilities in Windows, as well as fixes for previous Bitlocker bypasses, and an AI prompt injection which could allow web sites to trigger Copilot in Microsoft Edge on Android and execute arbitrary prompts. Another bug patched this month allowed privilege escalation and code execution over DHCP, potentially impacting all Windows installs on the same physical network or public hotspot.
Microsoft credits AI assisted tooling with the record-breaking number of bugs discovered, and indicates it’s unlikely to slow down next month.
LegacyHive Windows Vulnerability
It’s a week with a Patch Tuesday, which now seems to mean it’s a week with a new exploit from NightmadeEclipse, the researcher who previously made news for being quite upset with the responses from the Microsoft security group. After then creating a public outcry by threatening prosecution, Microsoft recently has seemed simply to be fixing bugs disclosed by NightmareEclipse in the next series of security updates.
This month, we have LegacyHive, an exploit which allows loading the “hive”, or collection of registry settings and configuration files, of another user. The Windows registry is typically used to store preferences, settings, auto-launched applications, and other important settings, so being able to access other users registry groups seems significant.
Fairlife Dairy Suspends Production
Fairlife Dairy, owned by Coca-Cola, has suspended US operations due to a ransomware attack. Filings with the SEC simply say that production facilities are impacted and will be temporarily suspended, with no estimate as to when they will be restored.
Typically when a food-processing facility goes offline, the delays for restoring service can be significant due to the sanitization requirements.
CPAN and Perl April Task Force
The April Task Force has been announced (yes, in July) with a focus on enhancing the security posture of Perl and the CPAN library.
Given the absolute havoc wreaked on the NPM and PyPi repositories in 2026, proactive measures to protect other repositories seem prudent. Funded by the Perl and Raku Foundation and the Linux Foundation, the April Task Force will be focused on supply chain security, vulnerability patching, and processing reported vulnerabilities and CVEs.
Perl may not be the juggernaut language it once was, but it’s still used widely, so any preventative measures are good news.
Secure Boot vulnerable
Researchers from ESET enumerated 11 boot loaders signed by Microsoft that can be used to bypass secure boot protections and execute arbitrary code.
Secure Boot was designed to only boot code signed by trusted organizations (in this case, Microsoft). Those of us running Linux typically know it as “the option in the BIOS to turn off to get a kernel to run properly”, but for corporate fleets, Secure Boot protections help protect disk encryption and prevent malware installs.
During boot, a Secure Boot protected system validates the code it is about to launch to ensure it is signed by a trusted organization, establishing a chain of trust where each component then validates the next before launching. Often, to enable other tools or Linux distributions to boot, a “shim” boot loader is created and signed by an organization trusted by the UEFI install, which then loads and validates the actual boot loader or kernel.
Over the years, many such shims have been signed, but updates have lagged and security vulnerabilities have been found. Even unused old boot loader code remains signed and viable, allowing attackers to replace a modern version with a vulnerable, still valid, old version.
Microsoft has removed several of the vulnerable boot loaders via recent Windows patches, however systems that are not updated and systems that do not run Windows will still likely be vulnerable.
Being able to rescue you motherboard isn’t a “vulnerability”
That BIOS password is mind boggling to me, why only encrypt after the 12th character on the password, and how was it not caught?! It is so strange, and the 12 character seems very oddly arbitrary, but more like it was a deliberate choice than an accident, as surely accidentally it would be only the first byte or two that could slip through accidentally and justifiably not be noticed – 12 Character is just too huge a mistake to have passed even the most basic validation your code works…
And now I’m curious if the motherboard even allows you to unenroll the MS secure boot keys, last time I fought with secure boot stuff it seemed to be way way too much work to get that system to actually do what I darned wanted, so I did just turn the secure boot off (frankly don’t need it, was just curious if I could get secure boot to deny Windon’t etc).
“For longer passwords, characters beyond the first 12 are encrypted”…. Indeed, what was that feature meeting like at Dell? Is there a test plan that makes sure the first 12 bytes are not encrypted? Is it encryption when the key material is the first byte, or obfuscation?