David W
- 63 Followers
- 232 Following
- 217 Posts
vulns | radio | amateur astrophotography
McSweeney's"The remaining 5 percent concerns only the final portion of the hill, the tendency of the boulder to inevitably roll back down to the very beginning, the eternal nature of my punishment, and the fact that Hades has not technically agreed to alter any terms."
https://www.mcsweeneys.net/articles/i-sisyphus-am-ninety-five-percent-of-the-way-there
https://www.mcsweeneys.net/articles/i-sisyphus-am-ninety-five-percent-of-the-way-there
Sebastian Schinzel
Rairii 
hi everyone
given one #bitlocker #0day is already out there, here's my own bitlocker 0day, I added it to my repo listing bitlocker attacks.
Introducing "ram leak": https://github.com/Wack0/bitlocker-attacks#ram-leak
As we all know, the boot environment allows booting from a ramdisk. This involves loading a file from disk into RAM, as expected.
However, "file" and "disk" can be arbitrarily chosen, and "disk" being a BitLocker encrypted partition is a supported scenario. Using another trick (same one used with bitpixie earlier) it's possible to get the keys derived without going through the legacy integrity validation checks too if relevant.
You can see where this is going. It's possible to leak any file from a bitlocker encrypted OS partition into RAM as long as you can get the keys derived (ie, TPM-only scenario).
The catch is that booting into the NT kernel marks that memory area as free so it could get overwritten there, but there are other ways to dump the memory area, and a PoC is included with my preferred method (it's only a PoC so just displays a hexdump of the first sector of the file)
The video shows successful exploitation in my test VM, it has secure boot enabled (you can tell because VMware shows an efi shell option on the boot menu when secure boot is disabled).
#infosec #windows
given one #bitlocker #0day is already out there, here's my own bitlocker 0day, I added it to my repo listing bitlocker attacks.
Introducing "ram leak": https://github.com/Wack0/bitlocker-attacks#ram-leak
As we all know, the boot environment allows booting from a ramdisk. This involves loading a file from disk into RAM, as expected.
However, "file" and "disk" can be arbitrarily chosen, and "disk" being a BitLocker encrypted partition is a supported scenario. Using another trick (same one used with bitpixie earlier) it's possible to get the keys derived without going through the legacy integrity validation checks too if relevant.
You can see where this is going. It's possible to leak any file from a bitlocker encrypted OS partition into RAM as long as you can get the keys derived (ie, TPM-only scenario).
The catch is that booting into the NT kernel marks that memory area as free so it could get overwritten there, but there are other ways to dump the memory area, and a PoC is included with my preferred method (it's only a PoC so just displays a hexdump of the first sector of the file)
The video shows successful exploitation in my test VM, it has secure boot enabled (you can tell because VMware shows an efi shell option on the boot menu when secure boot is disabled).
#infosec #windows
Will Dormann@jwildeboer @darkcyberman @larsmb @dazo
How many Linux kernel CVEs were there in 2025? 5500?
How does Red Hat determine which of these to cherry pick as worth backporting?
buherator
While this vulnerability seems to be discovered using AI ("Xint Code"), I have to assume that they also let the AI decide how to do the vulnerability coordination as well.
major builds are out as of this writing😂
No distros have official updates for CVE-2026-31431. Fedora 42 and newer have updates, but no official advisory or acknowledgement of CVE-2026-31431. So with them it's unclear if it's even intentional. Red Hat, Ubuntu, Amazon Linux, and Suse all have advisories as of now, but NO updates.disable the algif_aead moduleas a mitigation. 😂
Bespoke distros like RHEL don't use a module, it's compiled into the kernel.
I can't figure out what the Xint Code angle is with this copyfail stuff. On one hand, yes, it is a true vulnerability that affects a LOT of Linux distros available. And they did submit the bug for fixing to the upstream kernel people.
BUT the CVE has only existed for a week. And NONE of the distros IN THEIR ADVISORY had updates available at the time that they pulled the trigger for publication of the shiny copy.fail website.
I struggle to think of how this even happens. In all my years of infosec, you're either on board with doing CVD (e.g. coordinating with the former CERT/CC) or you're not (dropping 0day). But this all fits bizarrely in the middle. The publication gives the guise that they did the right thing, (and please use our AI services). But at the same time, they clearly chose to release the vulnerability details and functional exploit before any distro had the ability to properly do anything about it.
Either these Xint Code (Theori) people have a hidden agenda or ulterior motive that we aren't aware of yet. Or they're just really bad at coordinated vulnerability disclosure. You pick.
quarkslabTired of reversing the same libc for the 100th time? 👀
Meet SightHouse, our open-source tool that automatically detects third-party library functions in binaries.
High-confidence function mapping. Works with any disassembler. By @madsquirrel & Sami.
🔗 https://blog.quarkslab.com/sighthouse-automated-function-identification.html
Xe