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!
It seems like this kind of thing should be done by the operating system and not anything the programmer needs to include or even worry about.
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.
Looks like engineer terms to me, which is fine since most of us here are engineers.
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.
ASLR is that something that needs to be coded into programs individually? Is it something that is made available as part of a certain framework (Java, C#)?
I actually thought it was a function of the OS managing running programs. Or do you need to specifically go out of your way to disable it and is this what happened here?
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.
There are people who, when the AV software warns them about a known risk, they click "ignore" or "allow" because installing "youtube downloader" to they can steal music from youtube is more important than a secure operating system. Then after getting pwned, they call someone like me to ask why their anti virus software doesn't work. I have to be a proper CSR and tell them that while their AV software might have stopped 10,000 infections, the one that got in was most likely an unknown or new virus and the definitions to protect against it haven't been created yet, obviously the correct thing to tell them would be something more like "the reason it didn't work is because you told it not to" but alas, the truth loses customers.
It should be.
I've never gotten a satisfying explanation of why process X is allowed to overwrite memory belonging to process Y, thus causing Y to do BADSHIT when it jumps to that location.
I've also never gotten a decent explanation as to why stack overflow is still a problem or why process X can heap spray the fuck out of memory and have that shit affect process Y.
The OS should be managing memory. Address locations should be randomized. Memory should be zeroed out upon allocation (or deallocation, or both). Memory not allocated to a process should not be accessible by that process. If the stack fills up your shit should stop, not overwrite the heap. Etc.
The OS should be handling this shit, and the OS should provide the tools for interprocess communication, debugging, etc., either via an API, a privileged process, or whatever. If I want to debug process Y and read its memory, then I should need to respond to a security prompt (UAC or whatever) to do so.
Shared memory should be virtually mapped such that process X and process Y see two different addresses, but the OS knows both map to the same real address. Writing to shared memory should be done only by the OS, as you're loading shared libraries or whateverthefuck. Alternatively, any time shared memory is written to, it should be forked and unshared so each process gets their own copy - one with the changes and one untouched. We've got plenty of memory now, lets use it.
You'd need to track who spawned whatever process tried to read/write that memory to determine what overall application "owns" that memory for instances where shared memory (with write access) is valid. This lets shit work without letting one process/application escalate its privilege level by fucking with shared memory a privileged process/application is using.
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.
Kaspersky is known to take marching orders from the FSB. I really wouldn't trust that software any more than I would the trust the "virus" it's meant to prevent.
Honestly I'd think the truth would be better at keeping customers.
versus
Software that's capable of saving me if only I hadn't disabled it is a bit more desirable than software that couldn't have saved me no matter what. The first one, I pay my money & I learn my lesson. The second one, what am I paying you again for anyways? Maybe I'll just keep my money.
Address locations should be randomized.
Why? If other processes cannot access the address space, what difference does that make? And if other processes can access the address space, you have a bigger problem that you need to fix first.
It's security through obscurity, and it hurts performance for minimal benefits. Anyone in a position to exploit it, is already in so deep that the system must be considered compromised.
Yes, but you appear to not be an idiot. Most end-users are idiots.
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
How ironic. If you look on Softpedia's Security news section you see that Malwarebytes also had a security bug fixed, just one day earlier: http://news.softpedia.com/news...
Complete fail of virtual memory. 0x800000 should be something different in process A and B, and an OOM when two processes would otherwise have to intersect their memory locations. Virtual memory can map to anywhere, so why is this even an issue?
fork(), exec(), System V shared memory, semaphores. Some scientific applications run much faster on large CC-NUMA machines than they do on clusters of distributed computers, and the processes need to coordinate and/or access memory from "adjacent" processes, typically at the boundaries. Think weather simulations where each process is allocated a grid square and what happens at the square boundaries.
Admittedly, the rationale for applications overwriting a CODE segment in the memory of another process seem to be pretty thin.
SysV shared memory already works this way.
Aaaaaand you've killed off the scientific CC-NUMA applications that rely on semaphores and changes to shared memory being seen by other processes. Whoops. Guess you're going to have to do weather forecasting and climatology by hand on paper, just like in the good old days.
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.
There will always be cases where another company will discover malware before the one you're currently using. 1 company has to always find it first and the others put out definitions to catch it after that.
Certainly true but it is possible to operate a computer safely without a resident, always scanning, AV application *with* Windows. I've done so and used infrequent scanning with MBAM (or others) and had nary a problem and that's not limiting myself to just certain sections of the web. It is being cautious, using least privileges, installing only from trusted sources, and observing network ingress and egress prodigiously - which can be automated, to some extent.
This of course is of no benefit to Mr. Stupid, as you say, but it is possible. I'd point out that I have absolutely no anti-malware installed on anything that I have with me but that'd be a bit misleading. Other than my phone, I have no Microsoft products with me. That doesn't really negate my point and my point doesn't negate your point. I just figured it'd make good additional information. I'd absolutely not recommend Mr. Stupid use Windows without an AV application running, updated, and set to scan everything.
As an aside: I'd always kept Linux installed on one partition or another but seldom spent much time using it. I finally realized that I wasn't learning anything new and that I was becoming a passive consumer. I nuked all of my Windows boxes that were in-use and haven't looked back. My MSDN subscription has even lapsed and I doubt that I will re-up it.
"So long and thanks for all the fish."
You could always go buy a gun and some bullets, load the gun, and fire it directly into the side of your skull, since that is likely to be the only thing you'd be any good at. - Your mom.
Unless there's something I am unaware of, you have a strange definition of "known." I believe unreliable sources have made some dubious claims but I don't recall anyone providing proof. A quick Google shows a debunked Bloomberg article and a few people who continue to cite it. I'd be curious to read any proof of such. Speculation isn't really proof.
"So long and thanks for all the fish."
The same glaring errors seem to indicate incompetence; a Government TLA is a likely source for such things.
Who writes good code at gunpoint? My shit would crash 98% of the time on purpose, lol.
I'm not going to last long under the New Gestapo; probably none of us are.
Truth isn't Truth - Guliani
And we have known this since 1970!
Sent from my ASR33 using ASCII
Unless your code assumes that a given function is always loaded at address 0x004006AE, or something stupid like that. Which older software sometimes does, so Microsoft had to make ASLR opt-in by default. Except some *new* software is still not opting in, despite it being the default on Microsoft's linker for the last 5 versions or so.
You can use Microsoft's free tool EMET to force a program to use ASLR, and some Windows programs are now always forced to act this way by default. ASLR applies to DLLs and other executable files, not just to the base EXE, so sometimes a third-party library can make your otherwise-safe process vulnerable. I'd like to say that we can apply such "force everything to be relocated randomly" rules to all software now, but if three major AV vendors hadn't turned on the option until now, maybe we aren't there yet.
Sigh...
There's no place I could be, since I've found Serenity...
So the answer is, I take it, that you have no proof and that you'll believe this without any proof at all. I think they call that "faith" in some spheres. So, it's good that you have faith.
"So long and thanks for all the fish."
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...
Performance is an issue, sure. It's an extremely minor one with the CPUs we have today, but for most cases I'd say the security benefits are worth the overhead.
Any existing software (that can't/won't be updated to go through the OS for shared memory) could:
A - be white listed by the user
B - be automatically handled by the OS if the OS knows the various threads/processes are part of an overall application or workflow and should have access to each other's shit
C - be allowed to do whatever as long as it doesn't fuck with shared memory of a higher-privileged process
Address randomization would still help against physical dumps or exploits at the OS level that would allow processes to peek at memory they shouldn't be able to.
Performance is very minimally impacted.
Hello,
Last month, anti-malware testing company AV-Test issued a report titled "Self-Protection for Antivirus Software" in which they looked at the use of ASLR and DEP in 32 different anti-malware programs. Of all these programs, only one had 100% of its files compiled with those protections.
Of course, anti-malware programs usually have their own anti-tamper mechanisms to ensure code and data integrity, but it seems like there's still some ways to go, and even it is still a good idea to make use of additional security functionality available through the compiler and operating system.
Regards,
Aryeh Goretsky
Dexter is a good dog.
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).
Performance is very minimally impacted.
That depends on the applications and systems they run on. In a Windows like setting with monolithic long-lived apps this is true, but in a traditional Unix setting with a myriad of small short-lived apps that call various libraries, the impact of not being able to use pre-built allocation tables can be quite severe, both in terms of startup time and memory usage.
We're talking up to 40% slowdown for some embedded and web applications with lots of callouts to externals, plus the increased memory usage. That's not minimally by any yardstick.
I think you have a few misconceptions there. No modern OS allows process X to overwrite process Y's memory unless it has a serious bug or it's a special purpose embedded OS (generally running on a tiny machine). Each process has it's own address space It may ask that the OS map free memory into it or it can ask for files (such as libraries) to be mapped into it. It can choose the address itself or it can leave the OS free to pick a location.
The porocess can either leave itself unprotected from stack opverflow (bad) or it can leave an unallocated guard space between the stack and the heap so that an overflow will cause a segfault.
Permissions on the library files should force mapping read-only so that other processes mapping of the same library cannot allow shennanigans. If that's not the case, it's a bug. Note that the OS can optionally make the mapping r/w while the file is ro BUT actually handle it as Copy On Write (yeah, yeah, cow) so that the sharing breaks when the process writes there (it gets it's own private copy).
Deliberately shared memory segments are a feature for IPC and the policy of what can write where is determined by the application. There are great advantages to making that mapping at the same logical address.
This wouldn't be a problem if the MMU did its job properly ..
So basically stop using WIndows XP and you won't be impacted
http://saveie6.com/
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!
Do people still uses windows?! WTF!! :D
Higuita
If you define work as stupid, then you've probably succeeded with that IT policy.
For the most part, by the time an AV vendor is able to add a check for a new vulnerability, it's too late, the damage has already been done. So then you end up carrying around thousands of checks for old viruses from then on, and you wonder why performance slowly grinds to a halt. Do everything risky in an expendable VM.
If your solution to multi-threading is spinning up more processes, or even threads, you're doing it wrong. The ideal case for a high throughput system is about 2-4 threads per core. Assuming a quad core cpu, about 16 threads. If you have a web server that is using more than 16 threads to serve hundreds of thousands of requests per second, you get your geek card revoked.
I run arch, but I do keep windows around for compatibility. I just run free Avast
I'm not sure how you got to that from what I wrote. I was talking about systems that spawn short-lived processes as opposed to constantly running them. Processes that might be called daily, not "hundreds of thousands of requests per second".
A high number of processes (or threads) doesn't come into it. A common concept in embedded systems is to avoid resources hanging around, because their usage seldom overlap - you spawn, run, free. Best case, free up the entire job. Worst case, dlclose or let it page out. Freeing up is better because it also leaves less room for resource leaks to stay around and bring a five nines system down.
When absolute throughput is what matters, the weighing is very different. But when relative throughput and not absolute throughput is what matters, you don't want to burden the system with something that makes loading/unloading more expesive than necessary.
prelinking != preloading. It helps you avoid preloading. On systems where every byte is at a premium, and you have to provide 4 GB worth of features in 128 MB, and expect it to have a shelf life of 10+ years, yes, these things matter, and you make different design choices.
You want a system that's responsive within the constraints, not one that OOMs, or one that requires doubling the production costs and increasing risks.
Depends. Are you a reasonable target for industrial espionage? You might want to consider not using Kaspersky. In my family, some but not all of the Windows boxes are on Kaspersky, so I figure if malware hits more than one computer it's likely to be detected even if one anti-virus doesn't catch it. (Except for the nice new ones, which I presume are tested against all major AV programs.)
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes