0Patch fixes vulnerabilities (CVE-2022-26809 and CVE-2022-22019) in Windows

Topic

New Reply

OK, all of you down here with me in the Win 7 Untouchables bin, take heart; 0Patch IS working for you! Example:

“The ACROS Security team around founder Mitja Kolsek has released a micro patch to close the Remote Procedure Call Runtime Integer Overflows vulnerabilities CVE-2022-26809 and CVE-2022-22019). The patch is available for Windows 7 SP1, Windows Server 2008 R2, up to Windows 10 (v1803 to v2004). The micro-patch is available for all customers with the 0patch agent who own a Pro or Enterprise license of ACROS Security.”

https://borncity.com/win/2022/05/18/0patch-fixt-schwachstellen-cve-2022-26809-and-cve-2022-22019-in-windows/

See? They ARE on the job !

Win7 Pro SP1 64-bit, Dell Latitude E6330 ("The Tank"), Intel CORE i5 "Ivy Bridge", 12GB RAM, Group "0Patch", Multiple Air-Gapped backup drives in different locations. Linux Mint Newbie
--
"The more kinks you put in the plumbing, the easier it is to stop up the pipes." -Scotty

5 users thanked author for this post.

jburk07, Cybertooth, LHiggins, AJNorth, Alex5723

Reply | Quote

Replies

https://blog.0patch.com/

by Mitja Kolsek, the 0patch Team

April 2022 Windows Updates included a fix for a critical remotely exploitable vulnerability in Windows Remote Procedure Call Runtime (CVE-2022-26809). The vulnerability was found and reported by company Cyber-Kunlun founded by security researcher mj0011, but no proof-of-concept was published at the time.

As is often the case, the research community “diffed” Microsoft’s patch (see Ben Barnea and Ophir Harpaz of Akamai and MalwareTech) and quickly found that the vulnerability must have been an integer overflow: if a special kind of RPC packets were sent to the RPC server, and very many of them, a buffer size on the server side would grow and grow until it would have to exceed 4 GB (the highest number one can represent with 32 bits), at which point said buffer size would “overflow”..

For a few weeks attackers and defenders alike were looking for more data and either searching for, or trying to create a POC. On May 1st, a GitHub repository from user yuanLink appeared with what looked like a POC for this issue, along with a detailed analysis of the vulnerability seemingly from the same user. We took the POC and after some modifications we were able to reach the vulnerable code and see the buffer size growing with each received packet.

This allowed us to fix two birds with one stone, so to speak, and we created a single micropatch to address both CVE-2022-26809 and CVE-2022-22019…

3 users thanked author for this post.

jburk07, Nibbled To Death By Ducks, Cybertooth

Reply | Quote