0patch offers two more years of updates for Windows 7 and Windows Server 2008 R2

[Papusan]

0patch offers two more years of updates for Windows 7 and Windows Server 2008 R2 techspot.com

 

The company has already promised "two more years" of critical security patches for the Windows 7 codebase, extending the support period "at least" until January 2025 with a possible further extension dependent on client demand.

 

 

https://blog.0patch.com/2022/10/two-more-years-of-critical-security.html

 

Two More Years of Critical Security Patches for Windows 7 and Windows Server 2008 R2
Extended Security Updates about to be terminated? Don't worry, we have your back.

 

 

 

 

[Etern4l]

Sounds too good to be true TBH. How can they patch software they don't have source code for?

[Aaron44126]

Microsoft is supporting Windows Server 2008 R2 until at least January 2024 for Azure customers, and I am assuming that those patches will be able to be shoved onto Windows 7 somehow, since the codebase and patches are largely the same?

[Etern4l]

Ugh

 

 

[jaybee83]

50 minutes ago, Aaron44126 said:

Microsoft is supporting Windows Server 2008 R2 until at least January 2024 for Azure customers, and I am assuming that those patches will be able to be shoved onto Windows 7 somehow, since the codebase and patches are largely the same?

wow that sounds....wonky. but hey, if it works, why not? more options! 😄 

[Raiderman]

Nobody needs their so called "critical Patches"  Windows 7 doesnt have any need for any such patches. If those types of patches were needed, they would have found them years ago, and microsofts "critical patches" tend to break perfectly functioning systems....aka windows 10. Whats needed for winodws 7 is continued driver support, but we know that wont happen. Windows 7 is actually fun to tweak, and customize....oh, and control myself without big brother MS ****ing things up.

[Sandy Bridge]

On 1/11/2023 at 2:49 PM, Etern4l said:

Sounds too good to be true TBH. How can they patch software they don't have source code for?

By being really incredible programmers.

 

More specifically, their software overwrites the vulnerable part of Windows in-memory, while it is running, rather than on disk.  This prevents Windows from overwriting their patches due to its file protection system seeing modified files, and also prevents hackers from exploiting the security flaws, which are no longer present in the in-memory version of Windows (which is what is really important, programs always run in memory even though they are stored on disk while not running).

 

I know a guy who has added new functionality to an early 2000s strategy game by using a similar technique, in that case hooking into where functions are registered in the in-memory version of the code and redirecting the old functions to new ones that he has compiled from C or C++ code and which provide that new functionality.  Pretty incredible stuff.  I'm a good enough programmer to know conceptually that this is possible with some Windows APIs that could let you do this sort of thing, but am not nearly knowledgeable enough in assembly, in-memory executable structures, and reverse engineering to pull off anything like 0Patch.  Let alone also knowing enough to identify the security flaws and fix them.  0Patch probably relies in part on publicly available reports of the security flaws to know what to patch, and most patches will fall into several common categories, such as buffer overflows, but it's no mean feat.  There's a reason they charge for it, people who have that much knowledge of the Dark Arts can command a high salary.

 

I don't know that you could use those APIs on sandboxed Windows Store style applications, but for classic Win32 applications, and evidently for Windows itself, it is perfectly possible to write a program that modifies another program while it is running.  We're used to living in the post-MS-DOS world, where programs have their own memory spaces, you aren't supposed to be able to overwrite another program's memory.  Not the case with these APIs.  There's a sense of power that comes with realizing there is a way to do that even today, and that if you know enough about the program you are trying to modify - which is the really difficult part - you can modify it to behave how you like, regardless of how it was intended to behave. 

 

This API is the specific one I've used to overwrite another program's memory (along with a few of its sibling APIs to read the structure of the program's data and know what I want to modify).  It's intended to be used for debuggers; if it's the one 0Patch is using it, they're repurposed it for a different type of de-bugging.  I've only used it for proof-of-concept programs, since I don't have sufficient knowledge of adjacent skill sets to make something really impressive with it, but it works as advertised.

 

It's also worth noting that you want to think about whether you trust the people writing these sorts of programs - your thought of "this may be too good to be true" is a good instinct.  Like anti-virus programs, they reach rather deep into your system to do what they do.  I have no reason to believe 0Patch is not trustworthy, and politically they're from Slovenia which has a good reputation, but I am not Bruce Schneier or Brian Krebs.  If you are enough of a Real Programmer to write 0Patch and fix these flaws, you are also enough of a Real Programmer to write software that would add security holes to a system.

[Etern4l]

All I am hearing so far is "really incredible hackers". If you allow 3rd party software to somehow "patch" shared libraries, arbitrary applications, and the kernel in memory, which would be nuts - if an OS made actually all of that possible (BTW how do we know if any of the alleged "patching" actually happens?), I would immediately delete it. The whole thing sounds sketchy as hell due to the violation of basic modern OS design principles and for the reasons you mentioned in the last paragraph. Based on the information at hand so far, I wouldn't touch this thing with a barge pole. 

[Sandy Bridge]

On 1/13/2023 at 1:03 AM, Etern4l said:

All I am hearing so far is "really incredible hackers". If you allow 3rd party software to somehow "patch" shared libraries, arbitrary applications, and the kernel in memory, which would be nuts - if an OS made actually all of that possible (BTW how do we know if any of the alleged "patching" actually happens?), I would immediately delete it. The whole thing sounds sketchy as hell due to the violation of basic modern OS design principles and for the reasons you mentioned in the last paragraph. Based on the information at hand so far, I wouldn't touch this thing with a barge pole. 

For user mode programs, one of the programs you can use to view (and edit) running memory of other programs is HxD Hex Editor.  Go to Tools -> Main Memory, choose the program whose memory you want to examine, and you can start viewing it and editing it.  This could be used to verify patching happened in a equivalent process for user mode programs.  There are probably tools that offer a similar experience for kernel-mode programs, but I don't know what those tools are.

 

0Patch almost certainly uses a kernel-mode driver to apply its updates, since a user-mode program shouldn't be able to patch kernel-level components.  Their user manual mentions that you must install it with an administrator account, which would be required for installing a kernel-mode driver.

 

But just like you can do sketchy things with other user-mode programs as a user-mode program, once you have a kernel-level driver installed, you can do quite a bit at the OS/kernel level.  This is why you'll occasionally read about a flawed update to an anti-virus program causing havoc; they also are putting tentacles all over the place to do what they do, with kernel-level drivers, and are another category of program where thought about, "do I trust the developers of this program?" should be made before installing them.

 

It's also worth noting that Windows NT (the core architecture of Windows today) dates from the early 1990s, and was not considered a cutting-edge design even at the time, but a pragmatic one.  GNU was following then-modern OS design principles with its HURD kernel, but Linux and Windows NT went with older monolithic designs.  Sandboxing wasn't really a thing, and while there was a whole lot more protection from accidentally trampling on other applications than there was in DOS-based Windows (especially in the early days in Real Mode), there weren't a lot of guardrails against intentionally trampling beyond the user/kernel mode split.  A walled garden like iOS can restrict some of the abusable APIs to only be used by first-party software, but Windows NT was not designed like that, and at a time when most computers weren't networked, the security threat model was different.

 

The upshot is this is why it's important to be careful about downloading programs from the Internet, and why (from a security standpoint) Microsoft launched the Microsoft Store where applications are more restricted than traditional Win32 applications, with sandboxing that follows those modern principles that didn't exist when Win32 was created.

 

I don't yet feel like I have enough information to say whether 0Patch is trustworthy.  Which, if they are, is probably one of their main business challenges.  The tradeoff of using their product is you are definitely screwed if they aren't trustworthy, while you are potentially screwed if you don't use their product and a hacker exploits a flaw on your system that their software would have protected you from.  The lower-risk of a user you are, the less potential upside there is in the risk of trusting 0Patch.

 

For additional reading, I'd recommend the book, Showstopper! by G. Pascal Zachary, about the development of Windows NT.