Slashdot Mirror
AVG, McAfee, Kaspersky Antiviruses All Had a Common Bug (softpedia.com)
An anonymous reader writes: Basic ASLR was not implemented in 3 major antivirus makers, allowing attackers to use the antivirus itself towards attacking Windows PCs. The bug, in layman terms, is: the antivirus would select the same memory address space every time it would run. If attackers found out the memory space's address, they could tell their malicious code to execute in the same space, at the same time, and have it execute with root privileges, which most antivirus have on Windows PCs. It's a basic requirement these days for software programmers to use ASLR (Address Space Layout Randomization) to prevent their code from executing in predictable locations. Affected products: AVG, McAfee, Kaspersky. All "quietly" issued fixes.
Want to place your bets that most / all ASLR systems are predictably NOT random in their randomization?
Lack of ASLR is not a bug. It's a lacking feature. Arguably, it's the compiler's responsibility to make it happen. Having said that, I find it real hard to get virus infections nowadays. There might be something to this "common sense" thing about not running any software from untrusted sources. That, and user/kernel space separation.
Visit http://ringbreak.dnd.utwente.nl/~mrjb/growingbettersoftware to download your free copy of the book
I get the feeling that you really don't understand how memory exploits work. You seem to be under a very large number of misconceptions, and to have come to all sorts of wrong conclusions based on them. I hope you haven't misled too many other people with your incorrect views on some of the very basics of how operating systems work. Hopefully the following constitutes a "satisfactory explanation" for you:
No, it's not. That hasn't been possible on any mainstream OS for many years (DOS/16-bit Windows, maybe old versions of Mac OS?). I mean, you can do it using debug APIs (on Windows, see things like WriteProcessMemory), but if your code has privileges to debug a high-privilege process it could also just do "BADSHIT" directly. A low-privileged process (which you already have code execution in, if you're talking about calling WriteProcessMemory) can't debug a high-privileged one.
What do you think the silver bullet is for stack overflows, then? Using counted functions is vulnerable to off-by-one errors (or other things that specify the wrong count), integer overflows when creating the buffer (malloc(itemcount * sizeof(Item)) will, for sufficiently large itemcount, produce a tiny buffer that will immediately overflow when written to), and many other risks. The closest thing we have is languages that manage their own buffer lengths and such, like Java, Python, JavaScript, and the (other) .NET languages... and those still have implementation errors that lead to memory corruption sometimes (I'm sure you've noticed that JavaScript engines, in particular, are not fully safe even though JS as a language is supposed to be safe). Managed languages are also still significantly slower than optimized C/C++ code, though the difference isn't nearly as bad as it used to be.
Or do you mean mitigating the overflows with DEP and ASLR? First of all, that's not a guaranteed fix; if the attacker can leak an address from the program to use as an offset baseline, or otherwise determine the ASLR mask, then that protection can be bypassed. Second, that assumes that there aren't any executables which insist on being loaded at known addresses... and as this story shows, we still have a ways to go to achieve that.
It can't, unless process Y is consuming output from process X and writing it into its own memory (for example, an antivirus filter scanning a file that a web browser downloaded and wrote to disk). See first point.
It is, as far as assigning memory to processes goes. Within a process' own address space, "managing memory" is literally 100% of what a computer program does (reading values, changing values, setting values, copying values, testing values, etc.). Well-behaved programs don't care what addresses the OS hands it, but not all programs as well-behaved in this way.
They are, for modern software... unless that software says it's incompatible with this behavior. Since a lot of old software *is* incompatible with this behavior - see above point - the OS defaults to trusting the software. In the case of the AV vendors mentioned in TFA, that's apparently a mistake, but it's not the fault of the OS for trusting the software you told it to install, it's the developer's fault for not making their software as safe as possible, and your fault for installing software that you can't trust to be safe.
Not *really* relevant here, but I'll add
There's no place I could be, since I've found Serenity...