From Vulnerability Note VU#817544: Windows 8.0 and later fail to properly randomize all applications if system-wide mandatory ASLR is enabled via EMET or Windows Defender Exploit Guard: “Microsoft Windows 8.0 introduced a change in how system-wide mandatory ASLR is implemented. This change requires system-wide bottom-up ASLR to be enabled for mandatory ASLR to receive entropy. Tools that enable system-wide ASLR without also setting bottom-up ASLR will fail to properly randomize executables that do not opt in to ASLR.”
|
There are isolated problems with current patches, but they are well-known and documented on this site. |
-
Issue if system-wide mandatory ASLR is enabled in EMET or Win. Def. Explo. Guard
- This topic has 38 replies, 11 voices, and was last updated 7 years, 6 months ago.
Viewing 16 reply threadsAuthor-
-
Catalin Cimpanu has written about the ASLR vulnerability & a regedit workaround until it is patched properly by MS, on bleepingcomputer.com.
-
-
For more info and a ready made fix and or applying the fix manually try here:
https://winaero.com/blog/beware-incorrectly-implements-aslr-windows-fix-available/
I havent tried it yet preferring to do a little more reading before throwing random stuff in the REG but if you do same old backup rules apply inc REG backup in case of well, unforseen “side effects;”1 user thanked author for this post.
-
-
-
-
Most people don’t need to do anything with regards to this issue because you’re probably not using system-wide mandatory ASLR because, although it improves security, doing so can cause programs to malfunction, or even failure to boot the operating system. As Bob99 noted in a message to me, system-wide mandatory ASLR is a setting that’s not even available in EMET by default.
1 user thanked author for this post.
-
Furthermore, doing the workaround turns on system-wide mandatory ASLR, which I believe is not on by default for any Windows operating system.
1 user thanked author for this post.
-
Which means in layman terms, doing the registry setting is probably a very bad idea for most people, as it will enable something that has a high risk of breaking old software without providing any real world benefits to them.
The registry setting doesn’t fix a vulnerability, it activates a very strict ASLR policy that has never been enabled by default on Windows, even in a less stricter way. People need to understand this. It is not a vulnerability.
I don’t enable mandatory ASLR on any Windows I won’t completely control. It is way too dangerous on a PC where people can install old software.
The best response to all this is do nothing and ignore this scary advisory. And I am not one of the least paranoid here, so if I tell you that, draw your own conclusions. Anyway, if it is deemed a bug and Microsoft fix it later, it will be activated at some point if you activated Mandatory ASLR in Fall’s Creator’s Update’s Windows Defender Exploit Guard. But still, I do not advise anybody to turn on Mandatory ASLR. I explain why below. Just use new 64 bits programs for things that can process files downloaded from the Internet and please be in the habit of patching Windows when Woody clears the defcon warning. You can still rip your CDs with your old software and play your old offline games without risk. Those who play Steam games, be also advised that I read before that the Steam anti cheat technology would sometimes detect real-time protections provided by EMET on some games as attempt to cheat and could create all kind of issues for you. You have been warned.
-
-
-
-
Ok, I know this subject a bit. I advise people to not use the registry setting. This is not a good idea for most people. The thing is, a lot of old programs that are forced to use ASLR can break and the normal user will forget that it is because of mandatory ASLR. For example, your program might crash or work fine but can’t update. Really, ASLR should probably be used mostly on Internet facing applications like browser, not the programs you use to rip CDs or print stickers and happy birthday cards. It is there to protect from a buffer overflow attack when opening a bad file from the Internet like a bad mp3, a bad picture, etc. by randomizing the allocation of memory and thus helps prevents attacks that try to target a specific area in memory or rely on predictability of allocation to infect. Please note only 64 bits programs protections are not as easily bypassed, 32bits programs don’t have a large enough address space.
My advice is the following: don’t run old Internet facing apps or apps that can open files you get from the Internet. New programs should be compiled to use ASLR as opt-in so they are not affected by this issue. If you are stubborn like me and insist on running mandatory ASLR, then find the registry trick to enable it in EMET if you are not on Win10 CU2 and then you will have to sometimes disable it just to run that old little program you use, but then any legacy program that doesn’t use ASLR normally properly will be forced to either supports it or crash. Just remember that then.
Please note that ASLR is disabled by default, not even mandatory ASLR, on most Windows version unless you use EMET, so this ´vulnerability’ might not even apply to you anyway if you never cared before, although I would argue you should care if you care about security.
I have said it here before I didn’t believe MS would put exactly EMET into 10 and have the same protections out of the box, as they would break too many software. From what I understand about this whole thing after a quick read, it is not a vulnerability, it is by design to prevent issues and it is probably for the best for most people. If you don’t use ASLR anyway, it is not even relevant to you. The only thing they said was that if you use mandaory ASLR instead of opt-in (a setting only available if you add a registry key to EMET), then on 7 it works (or crash the old program) while on 10 the program won’t really use ASLR properly but at least won’t crash. I prefer a crash, but most user would not even think enabling ASLR caused the weird issue they experience with some old software, so that is why Microsoft did it that way. However, I think in 7, at least it was clear you had to enable it using a registry setting and then it would really be enabled while in 10 they let you think it is but it is not, which is to me just a symptom of the whole new MS attitude of treating customers in a condescending manner.
So, for most people, just forget about this.
3 users thanked author for this post.
-
Oh, and one last thing. To exploit a buffer overflow, the tainted picture or mp3 or other file must targets a specific program or library, as they exploit a vulnerability in a particular piece of bad code, not like a virus that would add itself to any running executable. So, your risk of catching a malware in a picture that is targeting your old happy birthday card printing software is pretty low. However, if it uses a Windows library that is vulnerable to decode the image, it might be a different story, but then you do your Windows update, right, so they should be fixed when found by Microsoft. A buffer overflow targets unpatched systems or 0-days vulnerabilities that are still unknown to the vendor or not patched yet.
1 user thanked author for this post.
-
-
No, Noel, I think you misunderstood. I will use uppercase not because I am mad, but to highlight the important points while trying to explain this complex subject.
It just means that if you want to use the bragged-by-Microsoft-as-a-feature-of-the-most-secure-Windows-ever-each-version-since-Vista-by-marketing-but-disabled-by-default-to-not-anger-people-by-breaking-their-software ASLR protection for ALL programs including those who didn’t opt-in (thus the term MANDATORY ASLR), you need to use either EMET on Windows version 7 to CU or the “replacement” of EMET which is Windows Defender Exploit Guard baked in FCU, to enable the setting.
Then, you would think the setting does what it has to do, which is to force the ASLR protection on all programs including those who weren’t compiled properly for it and who didn’t opt-in.
But unfortunately, unless you are on Windows 7, you are fooled because by design activating Mandatory ASLR on 8 and up either by EMET or Windows Defender Exploit Guard doesn’t activate another part required for it to work properly, which is bottom-up ASLR. So all the programs that would not opt-in to ASLR are not protected by ASLR properly when you activate the mandatory ASLR, just like they weren’t before you even knew of the existence of this tool. It is not like using a security tool (both made by MS by the way and in the case of EMET a great tool (I didn’t use the other one yet, as I am on AU) lessens your security.
It is just that using the EMET tool on Win 7 makes you “maybe” more secure in very specific scenarios (using old Internet facing programs that are targeted directly by a specific bad file), risking most often to only crash said old app just running it under mandatory ASLR because it hasn’t been compiled with that in mind, vs continuing to use Windows in its default security mode.
On the PCs I manage, I enable system-wide mandatory ASLR, because nobody is allowed to use any old program anyway and everything is locked up, so if someone were to crash an old program I didn’t approve, well too bad, my friend.
Most people won’t benefit in a practical way from touching all that and just risk having issues. Yes, after carefully reading the article posted, maybe it is a “bug” in the sense that MS tells you they do one thing but in reality they don’t do something required to make it work properly when you enable mandatory ASLR on 8 and up, but they defend themselves saying it is by design, so you could wonder why offering the option in the first place, then. But my conclusion stand. Unless you really need mandatory ASLR or have no risk of running into issue by enabling it and you are well aware of that, just forget about all this. Microsoft should probably not even offer this option in the GUI, but restrict it to GP to reduce the risk of a normal user trying legitimately to be more secure enable a setting with dubious real world benefits for a high risk of issues that he likely won’t trace back to this setting when they appear months later if he happens to download an old program.
And remember, 32 bits programs are not much more secure using ASLR, as it is too small an address space to properly prevent issues, so even if your old 32 bit program is mandatorily ASLR enabled, well, if it is targeted by a fancy malware by an author who is after those printing birthday cards and downloading cute pictures on a website where he replaced the images by tainted versions, well there is a good chance this very evil person will know how to bypass the protections when the program is 32 bits.
4 users thanked author for this post.
-
Priceless!!!
1 user thanked author for this post.
-
1 user thanked author for this post.
-
Thanks for the clarification, Alex.
I’m all about prevention, rather than what to do to limit what malware can do once it’s in the system, so the “mitigation of infection” side of security is less familiar to me.
I prefer not to assume malware will get in, but (because nothing is certain) insulate my systems from failure (security failure or otherwise) through backup. Under that condition, the balance of the downsides vs. upsides of techniques such as ASLR, internal access limitation, UAC, etc. tips decidedly to the negative.
Think of extremes… We could optimize things so that nothing works, and so nothing bad could happen – or minimize the chance that nothing bad will be tried and maximize our computing resources for what we need them for.
-Noel
1 user thanked author for this post.
-
-
An anecdote that illustrates the indirect nature of how ASLR can cause problems:
Recently we investigated a strange problem. Our software, which loads as a DLL and uses OpenGL, would work fine on the first run but see a crash in the display driver on the second run.
Turns out that when our DLL is loaded, the typical pair of OpenGL library DLLs is also loaded – the opengl32.dll module shipped with the OS and the hardware-specific OpenGL DLL implementation module from the display driver. This is what we expect.
Our graphics worked properly on the first run.
When our software completes, our DLL is unload, and the opengl32.dll library unloads also – but for some reason (beyond our control) this particular display driver-specific implementation library does NOT unload.
The SECOND time we are run, the opengl32.dll library loads again, as expected. However, sometimes (but not always) it loads at a different address. This is ASLR in action.
Trouble is, the display driver implementation library, which for some reason didn’t unload, remembered the addresses of the entry points in the operating system generic opengl32.dll module. It didn’t re-initialize properly and ultimately tried to call the old addresses, where opengl32.dll was last time – even though opengl32.dll is now loaded at a new location. You can guess how well that worked.
In summary…
Because a driver library module has an error where it is not programmed properly to handle ASLR, when opengl32.dll initially loads or loads a second time at the same location, everything works. When it loads a second time at a randomized location, the application crashes.
Either opengl32.dll should not unload (keeping it from doing so is an effective workaround) or BOTH the libraries should unload and fully re-establish their linkages on the second run.
What’s interesting is that the apparent ASLR shortcoming documented in this thread (where it does not change the load address of opengl32.dll every time) averts the crash.
-Noel
1 user thanked author for this post.
-
-
-
-
-
For those with Windows 7 and thinking about setting up mandatory, system-wide ASLR via EMET, here’s something to think about, directly from Microsoft:
“In our tests we encountered issues in a common use scenario where having ASLR set to “Always On” would cause a system to blue screen during boot. This occurred because the address space for certain third party video drivers was being randomized. These drivers had not been built to support this randomization and subsequently crashed, causing the whole system to crash as well.”
The preceding quote is directly from the User’s Guide for EMET version 5.52. If you ask me, it’s not worth BSOD’ing a system in the name of security because that amounts to a DoS condition (unable to use the computer)!
-
-
… But in reality, just updating the drivers before activating mandatory ASLR would have prevented the issue… But then, keep your drivers updated anyway and remove the vulnerabilities.
AMEN!! The single best thing one can do to avoid security issues once you’ve learned of one existing for a particular piece of hardware. However, as they say, “If it ain’t broke, don’t fix it”. So, if there’s no security vulnerability to avoid, don’t go installing the latest device driver simply because there’s a newer one available unless it adds needed functionality or fixes a malfunction.
And, unless you know for certain that your device drivers and applications are 64 bit AND made to support ASLR (as @AlexEiffel does), don’t bother enabling mandatory, system-wide ASLR within Windows 7 by using EMET. Just leave ASLR set to “Application Opt In”.
AlexEiffel, please correct me if I’m wrong with what I’ve said above.
2 users thanked author for this post.
-
I agree in general with what you said but I would try to clarify a bit about EMET. If you only have 64 bits drivers and apps that have been compiled to support ASLR, then enabling MANDATORY system-wide ASLR is not required as they will already all benefit from system-wide opt-in ASLR enabled via the GUI, there is no need to use MANDATORY, as they will all be opted-in, thus benefiting from enabled ASLR even if it is not MANDATORY. However, if you are on Windows 8+ and enable MANDATORY system-wide ASLR using only EMET or the GUI, not the registry trick published lately, then it won’t change anything because you don’t run any app that will be affected by this change, unless you end up installing an old app that wouldn’t have opted in later, and the problem of this app crashing will remain. So there would be no benefit of enabling system-wide ASLR on Windows 8+ through the registry trick. Enable mandatory in the GUI if you want, but if MS ends up “fixing” the issue later, you will have the same consequence as having done the registry trick, which is not a good idea for most people.
So really, for most people, I don’t see the need to activate this, unless they purposefully want to crash apps not compiled with ASLR opt-in, like me, because they are very mean to their users who just wants to use old insecure software when being told in the first place they are not allowed to run unapproved code. And I run it for myself because I prefer to know and crash an incompatible app and then decide what I want to do with it. But I wouldn’t run that on a gaming machine because of the high risk of issues. And I put up with having to disable and reenable mandatory ASLR periodically to use a few old apps I really need occasionally.
Remember people, we are not talking here about a SMB vulnerability type, which could have a very high risk of abuse because of how easy it can be to spread without much user interaction. We are talking about an optional added security feature nobody uses almost that is not protecting as much as it should if enabled and that could maybe prevents some very specific attacks on specific old software incompatible with those protections. That makes a lot of IFs, knowing that in the first place it is much easier to just infect people not running ASLR (most) with a buffer overflow in a very popular current software.
Don’t get me wrong, ASLR is a wonderful idea, because in theory, with 64 bits apps that supports it, it can make exploitation of a newly discovered vulnerability in a software very difficult, so it becomes some kind of 0-day protection, a proactive security measure that can prevent issues without needing some people to notice it and produce a signature like an antivirus before protecting you.
So, yes, enable system-wide ASLR to benefit from it with new apps, but don’t enable MANDATORY system-wide ASLR, this is my recommendation for most people. And forget about the issue reported here because it just means MANDATORY system-wide ASLR doesn’t protect you much more than having MANDATORY ASLR protection disabled like it is by default anyway.
What they mean when they talk about the issue, from what I understand, seems similar to the reason 32 bits apps aren’t well protected by ASLR anyway. They talk about a lack of entropy for those apps who would not be protected because they didn’t opt-in to ASLR but you stubbornly want to force protection anyway. What is entropy? In the context of passwords, it measures how unpredictable the password is. So having a higher number of possible characters in your password or a longer password augments entropy. Low entropy means too easy to guess. In general though, entropy seems to be some measure of randomness. So, I am not sure what they mean exactly in this case, but it might be that MANDATORY ASLR on old apps on Windows 8+ is just not that random, or not random at all. In the case of 32 bits apps, well before this latest thing was discovered, researchers found that 32 bits didn’t offer a large enough set of possible addresses, so a good hacker could maybe try different areas of memory and end up being lucky and infect the computer, or something like this. So it didn’t mean ASLR protection wasn’t adding anything to an old 32 bit program, but simply that a smarter malware that would expect ASLR (which since it is not active by default is not expected on most systems), could more easily circumvent the protection, which is not the case on 64 bits apps. So, back to the current “bug”, if they mean they have not as much entropy because of bottom-up ASLR not being active on the not opted-in apps, maybe you are still a bit more secure anyway. If they mean no entropy as in no randomness at all, then it means the protection doesn’t randomize anything, so it would not add any protection when enabled or it would be trivial to circumvent. One could say after reading this, well if I am a bit more protected using mandatory ASLR on those Internet facing 32 bits apps using the registry trick the CERT gave that also have the side-effect of enabling MANDATORY system-wide ASLR while making it work for real, they might be right, but I would respond is it really worth the risk of causing instability in your system, as my printing birthday cards example tried to show how maybe unlikely you are to be targeted with those apps. Now if you run an old not updated browser, then you are asking for trouble. Run a modern 64 bits browser, patched that will automatically take advantage of ASLR enabled (but not mandatory), enable ASLR opt-in system-wide, and you are set.
For the drivers: the difficulty with updating the driver only when it fixes a vulnerability is how not that easy it is to follow the patches and check if it is needed or not to upgrade, so a lot of people just prefer to not update unless they have an issue, which is not ideal, but maybe good enough for most in practice, as the added security risk of not patching isn’t as problematic as the risk of issues with some of the drivers and their bloated software added with them. The way I see it, Microsoft should push drivers when there are security issues to fix so that way, most people would be covered for the important patches. Drivers should also be minimal and not contain lots of services and other software that are often unneeded anyway. But there is a whole other set of issues having Microsoft force-feed you patches and issues with collaboration from manufacturers that really would like you to install their bloat, so back to the same business problems that affects us all with all businesses wanting to sell you more even when you don’t need or want it. Free open-source a solution? Well, they would have to be more focused on user needs than what they find interesting to code.
1 user thanked author for this post.
-
-
-
-
What Microsoft should do is enable this system wide, but allow you to “opt out” for each individual program. In this way, programs which will be broken by address randomization would be exempted from it.
In all honesty, however, Microsoft has been bragging about the benefits of address randomization for a very long time, and so software vendors have known for a very long time that they should make sure that their software would not be broken by this.
Address randomization is a very good, secure way of running programs. It makes your programs a moving target, not a stationary target, and therefore less vulnerable to attacks.
Group "L" (Linux Mint)
with Windows 10 running in a remote session on my file server1 user thanked author for this post.
-
From Where Have All The Exploit Kits Gone? (March 2017) (my bolding): ‘“As much as I’d like to say it’s one thing that we did, it wasn’t,” said Peleus Uhley, lead security strategist within Adobe’s Secure Software Engineering Team. He said work with Microsoft and Google has paid off especially when it comes to mitigating against memory-corruption bugs, a popular target of vulnerabilities exploited by exploit kits. Uhley said Control Flow Guard, a memory corruption security technology baked into Windows 10, has been an effective tool at mitigating against use-after-free attacks, which became a favorite crimeware exploit once ASLR and DEP put a damper in buffer overflow attacks.’
1 user thanked author for this post.
-
Uhley said Control Flow Guard, a memory corruption security technology baked into Windows 10…
For what it’s worth, authors can build Control Flow Guard into applications destined to be run on older operating systems too, as long as they’re building their Win32 applications with the latest Visual Studio and SDK…
I need to do some measurements to see how it affects performance.
-Noel
-
-
“For most people, this behavior is a non-issue.”
http://www.zdnet.com/article/microsoft-says-aslr-behavior-in-windows-10-is-a-feature-not-a-bug/
3 users thanked author for this post.
-
This is a good article. It explains clearly what I not so well tried to explain and more.
Of course, I still don’t buy that “it is a feature, not a bug response from Microsoft”. I believe it is by design, but I call that fake advertising, like adding a switch to turn on a light that doesn’t work and then pretend you provide a switch to turn on the light. Don’t put a switch to enable Mandatory ASLR if it doesn’t work for real and then pretend it is by design when someone finds out the lie.
So, according to Ed Bott, you can use per-application settings with WDEG . Good, I didn’t see it when I quickly glanced at it. So, in theory, you could activate the real ASLR for some obscure old app you absolutely need, that is at risk of being targeted, that uses data from outside non trusted sources that could target it and that doesn’t crash when you activate it. Hmmm. I have yet to find out someone who really needs this. The thing is, if you use such a program, unless it is a very specialized program for which there is no newer replacement, the problem is you are probably putting yourself more at risk for no good reason in the first place. As I said earlier for most people and what Ed is saying is just forget about all of this.
I run mandatory ASLR to crash those old apps that are not supposed to run anyway on my network, kind of a nice side-effect. And because I prefer the deny all approach to one where you need to manually add protections or black list any new app. I just find it more sound as a security principle to follow. Less risk of forgetting something. But I don’t kid myself thinking I significantly reduced the security risk my users have. It is just easy for me to set the toggle and forget it and I don’t have reasons not to do it. Most people have reasons not to do it, because they generally gain nothing from it in practice in terms of security and they might, if they ever use old apps, run into issues in exchange for a theoretical added protection to a likely non existent threat.
So, Microsoft, why don’t you just remove the MANDATORY ASLR toggle switch and put that in the GP where it will use bottom-up ASLR instead of faking a security feature in the GUI? Anyone who understands this well enough will be able to find the GP and set things adequately. Now, while pretending it is by design, you are just giving a fake set of nuclear codes to the user who is supposed to be the boss of his computer but that you clearly don’t trust he can be, this is ridiculous.
1 user thanked author for this post.
-
‘Of course, I still don’t buy that “it is a feature, not a bug response from Microsoft”.’
I don’t buy it either. The giveaway is that Microsoft’s blog post gives a workaround.
‘Most people have reasons not to do it, because they generally gain nothing from it in practice in terms of security […]’
In my view, ASLR+DEP are better than in your view. Example: From Vulnerability Note VU#421280: Microsoft Office Equation Editor stack buffer overflow: “Exploitation of the vulnerable Equation Editor can be prevented by applying exploit mitigations to the eqnedt32.exe executable. In particular, enabling ASLR for should be sufficient to block the code re-use attack that is outlined in the Embedi documentation.”
1 user thanked author for this post.
-
-
“But then, why would Microsoft not recompile this component to use ASLR? Probably they should also patch when they find the buffer overflow too.”
Microsoft did patch it in November. I don’t use system-wide mandatory ASLR, but I plan to add eqnedt32.exe to EMET’s protection.
See also: How to fix a program without the source code? Patch the binary directly.
1 user thanked author for this post.
-
I thought it was probably fixed. My answer was rather rhetorical to say the risk is limited in time once the vulnerability is public.
Adding ASLR to eqnedt32.exe after the fact will bring ASLR protection for newer vulnerabilities on this now known vulnerable component, but if we wait for vulnerabilities to be disclosed before adding the protection to old components, it is not that much better than relying on no mandatory ASLR and patches, for the first not yet found vulnerability.
Your solution is best for reducing risk on a known program that could have more issues and that doesn’t seem to break while force fed ASLR, so I think it is a good thing to do. I can afford mandatory ASLR for my users and the link you posted about this vulnerability in Office gave me a good reason to do it in my specific case. Just like Noel prefers his black list approach with his dns filters and no disruption on productivity unless explicitly required, I generally prefer the white list one, especially in this case, when possible, at a potential cost in productivity (which amounts to practically nothing in this case for my users).
I find it amusing that your point brings a dark side to Ed Bott’s perspective that it doesn’t make a difference when you only use software that is not older than 6-7 years. This removes a bit of the shine of Microsoft products when their latest products contain components so old that they make you vulnerable while giving you a false sense of security. I can’t blame Ed though, as this issue is complex and I wouldn’t have thought Microsoft would still have old code not recompiled in Office if it wasn’t for your post. Thanks again.
1 user thanked author for this post.
-
-
-
-
-
ROP is Dying and Your Exploit Mitigations are on Life Support has some good general info, although it also contains vendor-specific info: “The offensive community has known something for a long time that I would like to share with you. ROP is dying and ROP exploit mitigations aren’t as effective as you might think.”
1 user thanked author for this post.
-
-
I took that blog post as indicating that the “cat and mouse” game between exploit mitigations and exploit writers continues.
1 user thanked author for this post.
-
-
Viewing 16 reply threads
Plus Membership
Donations from Plus members keep this site going. You can identify the people who support AskWoody by the Plus badge on their avatars.
AskWoody Plus members not only get access to all of the contents of this site -- including Susan Bradley's frequently updated Patch Watch listing -- they also receive weekly AskWoody Plus Newsletters (formerly Windows Secrets Newsletter) and AskWoody Plus Alerts, emails when there are important breaking developments.
Get Plus!
Recent Topics
-
Windows hosting exposes additional bugs
by 4 hours, 10 minutes ago
-
No more rounded corners??
by 6 hours, 34 minutes ago
-
Android 15 and IPV6
by 5 hours, 15 minutes ago
-
KB5058405 might fail to install with recovery error 0xc0000098 in ACPI.sys
by 16 hours, 31 minutes ago
-
T-Mobile’s T-Life App has a “Screen Recording Tool” Turned on
by 19 hours, 12 minutes ago
-
Windows 11 Insider Preview Build 26100.4202 (24H2) released to Release Preview
by 13 hours, 47 minutes ago
-
Windows Update orchestration platform to update all software
by 1 day, 2 hours ago
-
May preview updates
by 13 hours, 55 minutes ago
-
Microsoft releases KB5061977 Windows 11 24H2, Server 2025 emergency out of band
by 5 hours, 30 minutes ago
-
Just got this pop-up page while browsing
by 18 hours, 43 minutes ago
-
KB5058379 / KB 5061768 Failures
by 15 hours, 47 minutes ago
-
Windows 10 23H2 Good to Update to ?
by 21 minutes ago
-
At last – installation of 24H2
by 1 day, 18 hours ago
-
MS-DEFCON 4: As good as it gets
by 5 hours, 6 minutes ago
-
RyTuneX optimize Windows 10/11 tool
by 2 days, 6 hours ago
-
Can I just update from Win11 22H2 to 23H2?
by 4 hours, 41 minutes ago
-
Limited account permission error related to Windows Update
by 2 days, 19 hours ago
-
Another test post
by 2 days, 19 hours ago
-
Connect to someone else computer
by 2 days, 14 hours ago
-
Limit on User names?
by 2 days, 17 hours ago
-
Choose the right apps for traveling
by 2 days, 7 hours ago
-
BitLocker rears its head
by 1 day, 15 hours ago
-
Who are you? (2025 edition)
by 1 day, 14 hours ago
-
AskWoody at the computer museum, round two
by 2 days, 9 hours ago
-
A smarter, simpler Firefox address bar
by 3 days, 6 hours ago
-
Woody
by 3 days, 15 hours ago
-
24H2 has suppressed my favoured spider
by 1 day, 14 hours ago
-
GeForce RTX 5060 in certain motherboards could experience blank screens
by 4 days, 5 hours ago
-
MS Office 365 Home on MAC
by 3 days, 23 hours ago
-
Google’s Veo3 video generator. Before you ask: yes, everything is AI here
by 4 days, 19 hours ago
Remembering Woody
