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.
ASLR is what you fall back on when all your primary defenses are shot - the equivalent of not closing the blinds rather than leaving a window open.
Let me guess: the bug was somebody set up them the bomb?
The Daddy casts sleep on the Baby. The Baby resists!
Want to place your bets that most / all ASLR systems are predictably NOT random in their randomization?
Do people really still run this shit?
Malwarebytes has caught a number of things for me, including blocking things like OpenCandy from installing alongside certain programs I like. I've seen far less gain from installing different AV programs to work with it. Mostly they just slow down or break certain programs. Meh.
Windows users can download EMET to do this.
It's from MS and it's free. It lets you force a bunch of shit (like ASLR), lets you set up certificate pinning for websites (trust only certain certs or block specific certs), etc.
https://technet.microsoft.com/...
ACtually yes corporations actually care about antivirus, Kaspersky is one of the heavy hitters in this regard, and now I have to go verify our half assed implementation is patched. And you can fix stupid with software by locking down and limiting the amount of stupid things mr stupid can do. The fantasy of "no viruses if you have no script and don't visit porn sites" is that, a fantasy that evaporated a long time ago. Those of us tasked with securing windows servers and clients (I'd laugh if it didn't make me die inside) have to deal with real stupid, not theoretical internet stupid.
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
the thing that made antivirus --and still makes it -- such a pain in the ass is the fact that PC vendors include some crippled demoware trial version that, once monthly, becomes self aware and marks the entire vendor bloatware suite as some kind of second coming of hitler. its also worth noting that once this version expires it floats atop the OS as a bloated corpse sucking resources and occassionally bitching about the cash it needs to continue its reign of bitchery. Its nearly impossible to remove it without 3 passwords and your firstborn, and if you ever accidentally install another antivirus alongside it well then buckle up for the ride because your PC is about to heat up like a hot pocket as shitware 2.2 brawls to the death with whatever 6 gigabyte flaming turd mcafee or norton have squeezed out this year.
and antivirus isnt just antivirus, heavens no. its full system shield defense chevron carbunkle 5.5 with the privacy protection cup suite. every bit of data going in or out will be funneled through this application and like some multi-lane closure on the 405 most traffic will grind to a glorious halt while its inspected, detected, and ultimately forgotten.
Good people go to bed earlier.
This issue was bought up at Kiwicon a year ago. Some pen-tester showed that a majority of anti-virus software doesn't use ASLR. Furthermore, he shows buffer-overflows and other memory errors in most of their scanners! You could infect most systems with the right malformed PDF or JPEG. It just needed to be scanned. The scanners themselves often run as the system user!
Virus scanners are pretty much worse than useless. They're an attack vector.
Code needs to be written to be ASLR-compatible. For "normal" code, that means just write the code, flip the compiler flag, and don't do anything stupid with function pointers. For code that's trying to be overly tricky (maybe trying to do simulated execution of viral code in a sandbox to determine actual behavior from encrypted polymorphic code), it's not inconceivable that the code might depend on certain libraries and functions being at well-known addresses or within fixed offsets of each other. The more assembler or low-low level C you interface with, the more likely you'll encounter something that can't execute properly if relocated.
It's a naive way of writing code, but there's lots of it out there. Force ASLR on, and it crashes pretty spectacularly.
You do get security enhanced Linux (SELinux). That added things like make files impossible to change (system owned executable files) even for root. But in order install something like the Nvdia device driver blob, you had to disable it, execute the .run file, and then reenable SELinux.
There are also "trusted" UNIX systems which log every file change, modification and permission code.
The idea of shared memory is that the shared memory segment appears as a linear block of memory to the original process that created. Then other processes can request read or read/write access to that memory. The intention is for use with device drivers which need to map a hardware address to the driver address space so it can read/write registers and buffers. Your network driver stores all the received and sent packets in a number of ring buffers. A graphics driver accesses the framebuffer and texture data in a similar way.
Your alternatives are to use TCP/IP sockets or OS managed pipes. Just send down the offset, number of bytes and a pointer to the data that you want to change.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
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...
Linker flag, technically, but yes. The compiler produces machine modules which are always at known addresses relative to other parts of the module (but not relative to the address space as a whole), or relative jumps and branches wouldn't work and that would break everything. The linker controls how each module finds the base addresses of other modules. When the OS loads the binary produced by the linker, it can place the modules into memory at addresses controlled by a random mask, and the modules query these (masked) addresses when they are trying to find the addresses of code or data in other modules. However, old OSes always loaded the modules at the same addresses relative to each other (allowing one module to call directly into another, without needing to look up the address of the other module) and therefore the OS doesn't randomize module locations unless the program supports doing so.
On Windows, in Microsoft's SDK, the linker flag to produce a binary that supports random memory layout is /DYNAMICBASE. It's been enabled by default in the last 5 or so versions of Visual Studio.
There's no place I could be, since I've found Serenity...
Not necessarily. Memory randomization is mostly a protection against stack smashing. A common tactic there is send a message over the net that overruns a buffer with random junk, some code, and a fake return address that overwrites the real one on the stack. It's not that hard *IF* the location of the stack is easy to predict. When the receive function returns, it ends up returning to the attacker's code. If that code can depend on the location of various things in the address space, it can then call those functions itself in order to fetch more attacker code to be run.
Yes, the randomization only helps after something has gone wrong already (the real service shouldn't allow a buffer overflow, naturally), but at that point, the attacker really only has a toe in the door. If you've randomized, the process will crash and (possibly) trigger an investigation. If not, the attacker captures the beachhead and uses it as a base to continue to attack from (possibly privilege escalation, possibly you 'just' become an unwitting bot).
As opposed to Microsoft who are known to take marching orders from the NSA?
Unless you actually live in Russia or one of the former soviet countries it's highly unlikely that the FSB cares what you do, so if someone's going to have the keys to spy on you better that it's someone who won't bother to do so.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!