I frequently grump about what the #CVE system has become in practice. Folks may think that I’m not a proponent of the program. That’s not true at all. I’m an advocate for it, and for all those who pour their time and talent into it (often voluntarily).
But, IMO it is an overstatement to say that a CVE is a critical element in coordinating response to emerging vulnerabilities like heartbleed or log4shell. Embargoed critical vulns are rarely identified with CVEs among defenders.
This is what the #CVE and CPE system does.
We can chose to make the system different.
I’m actually quite OK with this.
The broader community is very good at detecting situations like these as damage, and routing around.
Just like the Internet. Right?
We had public disclosure and known vulnerability databases before CVE. And nothing is stopping those who have a shared need from coming together to fill a vacuum…
Reflecting tonight on the #CVE program, all it has given us, and how frustrated I’ve been because of what does, and what it fails to do.
Unfortunately there is no point in claiming that the purpose of a system is to do what it constantly fails to do…
In a last minute change, #CISA extended its contract with #MITRE to run the #CVE Program until March 2026 but there are already multiple efforts to create alternative, international versions of the platform outside of the control of the US government
I see a couple online news sources stating that CISA has extended the funding. They are using statements such as the following:
CISA says the U.S. government has extended funding to ensure no continuity issues with the critical Common Vulnerabilities and Exposures (CVE) program.
They leave out the sourcing on this. Who said it? How was it said? Via direct email requesting a comment? X post? Was it official or OTR? Like, I believe them but please provide SOME form of indication of provenance when claiming statements are made by the US Gov.
I'm a very infrequent poster on any social media platform, so the chances of this getting any kind of attention are slim... But it's worth a try.
I've been investigating #CVE-2024-50302, one of the vulnerabilities purportedly used in the Cellebrite 0-day chain. (This CVE received a bit of attention due to it's reported use in the wild while being a "low scoring" CVE based on CVSS.)
The fix was simple. Just change a heap allocation call in hid_alloc_report_buf to a zero-initialized version. Cool.
However, identifying the trigger for the info leak as elluded me. I'll try to set a bit of high level background context for searching for the bug.
The quirks or kernel behaviors triggered by emulating an "Anton device" apparently allow uninitialized bytes allocated by the vulnerable function to be sent from the host to the device via crafted HID reports (there's actually another VID/PID that should enable the same behavior since the exact same quirk class is specified.)
An "Anton device" is a special kind of multitouch device, handled by the hid-multitouch driver. I'm assuming the usbhid transport driver is used since USB devices were emulated, and not some other kind (I2C, or bluetooth for instance)
HID reports include 'INPUT', 'OUTPUT', and 'FEATURE' requests. INPUT reports are sent from the device to the host. OUTPUT reports are sent from the host to the device. And FEATURE reports can go either direction depending on what they are used for.
Considering there wasn't any fix related to INPUT reports being incorrectly sent from host to device, I've focused on execution paths related to OUTPUT reports and FEATURE reports that are sent to the device via SET_REPORT (I did look into GET_REPORT paths too, but that request type is for requesting and then receiving report data, rather than sending a report)
This is where I've hit my biggest roadblock. It seems that every execution flow for the hid-multitouch device driver that allocates a buffer with the vulnerable function ,hid_alloc_report_buf, to be used in a SET_REPORT request or passed to an OUTPUT endpoint, ends up passing the bytes allocated to the hid_output_report, which memsets the bytes to be used for the report to zero. I can't find a discrepancy in the calculation of the number of bytes to memset, and the number of bytes to send. (And if there was, that would be it's own vulnerability...)
There are a few paths through a GET_REPORT request where hid_alloc_report_buf allocates a buffer that is attached to the USB request structure, however that buffer shouldn't be transferred to the device. That path is also not unique to the behaviors enabled by an Anton device.
So I'm either missin the control/dataflow path that results in the uninitialized buffers getting transferred via the "send" pipes as a part of otherwise expected behavior, or there's something else going on. And if there's something else going it's hard to imagine it's not some separate bug or abusing other vulnerabilities to manipulate the kernel structures to artificially "build" an info leak path.
That's all for now... but that is likely to be my platform activity for the year...
#ESETresearch has discovered a zero day exploit abusing #CVE-2025-24983 vulnerability in the Windows kernel 🪟 to elevate privileges (#LPE). First seen in the wild in March 2023, the exploit was deployed through #PipeMagic backdoor on the compromised machines.
The exploit targets Windows 8.1 and Server 2012 R2. The vulnerability affects OSes released before Windows 10 build 1809, including still supported Windows Server 2016. It does not affect more recent Windows OSes such as Windows 11.
The vulnerability is a use after free in Win32k driver. In a certain scenario achieved using the #WaitForInputIdle API, the #W32PROCESS structure gets dereferenced one more time than it should, causing UAF. To reach the vulnerability, a race condition must be won.
The patches were released today. Microsoft advisory with security update details is available here:
A detailed, well-written, and hilarious breakdown of the details of CVE-2024-55591, one of the latest Fortinet fiascos:
When the answer to major draw backs with a language is use it better that’s a dead end for me.Try browsing the list of somewhat recent #CVE rated critical, as I just did to verify. A majority of them is not related to any memory errors. Will you tell all them "just use a different programming language"?
And again with OOP. Why hack it into a language rather than use a language that supports it.Have you seen existing C code? For anything non-trivial, most code uses some OOP, and it comes quite natural in C, certainly no "hacking". You don't need a
class keyword to do that.If it came out today you’d have an incredibly hard time convincing anyone to use it over other languages.It doesn't come out today, it's been there for a long time, and it's standardized, proven and stable. Sounds like you seriously misunderstood my points, which were, in a nutshell: For applications and similar, just use whatever suits you; for operating systems do experiments in lab/research projects (as was done with Unix), because existing and established ones are relied upon by lots of software. Just to make that perfectly clear, that doesn't mean they should use C forever, it means they should wait for a potential replacement to reach a similar state of stability with independent standards and competing implementations.
Who is paying attention to #EvilSocket on X and wheres the conversation happening? I'd like to follow whoever's mastodon is talking about it.
If no one is, then there is a #Linux unauth #RCE being disclosed to openwall on the 30th.
Appears to affect Linux and #BSD with a 9.9 CVSS score.
From reading X thread seems to be not kernel or user space. Assuming protocol implementation?
https://x.com/evilsocket/status/1838169889330135132
🚨 Microsoft has patched CVE-2024-38077, a critical RCE flaw in Windows Remote Desktop Licensing Service (CVSS 9.8). 79k instances exposed online. Apply patches immediately!