Windows 8 and Later Fail To Properly Apply ASLR (bleepingcomputer.com)
An anonymous reader writes: Windows 8, Windows 8.1, and subsequent Windows 10 variations fail to properly apply ASLR, rendering this crucial Windows security feature useless. The bug appeared when Microsoft changed a registry value in Windows 8 and occurs only in certain ASLR configuration modes. Basically, if users have enabled system-wide ASLR protection turned on, a bug in ASLR's implementation on Windows 8 and later will not generate enough entropy (random data) to start application binaries in random memory locations. For ASLR to work properly, users must configure it to work in a system-wide bottom-up mode. An official patch from Microsoft is not available yet, but a registry hack can be applied to make sure ASLR starts in the correct mode.
The bug was discovered by CERT vulnerability analyst Will Dormann while investigating a 17-years-old bug in the Microsoft Office equation editor, to which Microsoft appears to have lost the source code and needed to patch it manually.
The bug was discovered by CERT vulnerability analyst Will Dormann while investigating a 17-years-old bug in the Microsoft Office equation editor, to which Microsoft appears to have lost the source code and needed to patch it manually.
WTF is 'ASLR?'
Sure would have been a problem if we upgraded!
Maybe because I'm doing some Windows (7) code development and debug right now, but I would have thought that not having random code locations would have been noticed by application developers as they debugged their code - especially when you're creating threads, looking at the address of the thread start *should* be different each time the application starts, but if it's the same all the time that's an indication that ASLR isn't working.
Shouldn't this be part of a verification process for a new kernel release? I'm not trying to knock Microsoft here as this is a somewhat esoteric bug, but I would think that the security implications would drive the requirement for verifying that the code resides in a different location on each startup.
Mimetics Inc. Twitter
iOS
You wouldn't notice it while debugging because the integrated debugger keeps track of where the code is running. The only way to see ASLR in action is to run the standalone binary without symbols, THEN aim the debugger at it. The function addresses *should* then be different for every run.
My Other Computer Is A Data General Nova III.
The Agile process would have fixed this sooner. Because unit tests, right? Right. Agile is magic. The must be using a waterfall model which is why the bug was undetected for 8 years.
As opposed to having disabled system-wide ASLR protection turned on, or enabled system-wide ASLR protection turned off...?
Were you not taught to write "Its height is six feet" or "It's six feet high" and not "Its height is six feet high" when you were in primary school?
At the bottom of the
That explains why they never add new features and just bolt on new UI layouts.
Yeah, what I gleaned from the article is they re-initialize the entropy pool for the address space randomizer in some predictable way. So the addresses might be different every time, but in a predictable manner.
My Other Computer Is A Data General Nova III.
"if users have enabled system-wide ASLR protection turned on"
Is it so fucking hard to read what was typed even one time before you click the submit button???
I was just telling my manager that rogue lone-wolf programming projects tend to end up with this exact scenario. I am SO copying this article for her.
The Kai's Semi-Updated Website Thingy
...like the NSA backdoor toolkit
Here's a better article about the Office patch: https://arstechnica.com/gadgets/2017/11/microsoft-patches-equation-editor-flaw-without-fixing-the-source-code/
From the article:
There's no indication that the source code was "lost". They may very well have never had it.
Am I glad that new computer upgraded my Windows to version TEN!