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.

Comments

Not a major bug

[Anonymous Coward]

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.

Re:Not a major bug

[arth1]

Correct. Determinable address space is not a security problem in itself - it requires other security problems to be exploitable. And figuring out what the address space is in real-time is not that hard either; it just makes it harder. It's automated security through obscurity.

In some cases, it is preferable to make it sligtly easier for intruders who are already inside the system, in order to reap the benefits. Programs like "rebase" for Windows and "prelink" for Linux can preload a known address table into executables ahead of time, making them start faster and use less memory, because reallocation does not have to occur at load time.
Especially in an embedded world, that can make a boatload of difference.
Some look for silver bullets and want to impose ASLR (no, not the cameras) and https everywhere, whether needed or not, without considering the price of doing so. TANSTAAFL, and no silver bullets. They all come at a price, and sometimes the price is not right.

Fix the other security problems, and ASLR gives no added value, only drawbacks. But on a badly maintained system running software of dubious security value, sure, it can be a good addition. But make no mistake - it doesn't plug any holes, it just makes existing holes harder to exploit. At a cost.

Re:Not a major bug

[Bengie]

A good implementation of ASLR can add upwards of 40bits of entropy. An average, the application would need to suffer through 549,755,813,888 segfaults before finding the correct address. If you find a process spawning 1,000,000 copies of itself per second, you may want to kill it.

Re:Not a major bug

[arth1]

Except that brute force is not the typical attack vector - attacking other processes that already interface is.

Re:Not a major bug

[Bengie]

I assume that's why they also have stack gap entropy, which is also about 40bits. It's still going to be messy. At least for HardenedBSD, they'd randomized pretty much everything with between 30 and 40bits of entropy. If you make an attack that assumes any addresses at all, it will need to bruteforce the entropy.

Re:Not a major bug

[david_thornley]

A well-maintained system running high-quality software can be pwned also. It's just harder. Another defense measure that doesn't cost too much can be handy.

Re:Not a major bug

[arth1]

A well-maintained system running high-quality software can be pwned also. It's just harder. Another defense measure that doesn't cost too much can be handy.

True. And for most, SLA doesn't cost too much. But for some, it does, which means it, like HTTPS, or background AV scanning, should not be forced down people's throats.

Benefit, cost, detriments and risks all should be weighed, and nothing treated as a "must" or "must not", or considered a bug if not implemented. In some cases, the correct choice is to not implement something.

Re:Not a major bug

[TheRaven64]

A good implementation of ASLR can add upwards of 40bits of entropy

Given that most existing 64-bit hardware provides a 48-bit virtual address space, which gives the upper bound. Most things that you care about are at least 4-byte aligned, so that eats two, giving you at most 46. The top half of the address space is usually reserved for the OS, giving 45 bits. If you are not randomising within a page (which you can't for memory-mapped code), then that eats another 10 bits, leaving 35 (for performance, you often lose a few more because you're trying to align things for superpages). The offset of PLT entries is pretty predictable, which is what makes BROP attacks work, so you only need to find something the size of the library allocation to find them, which drops you down to far less. I'm interested in where you've found a 'good implementation of ASLR' that has the properties that you describe.

Re:Not a major bug

[david_thornley]

Certainly. I was pointing out that having an up-to-date well-maintained system isn't a perfect defense, so, depending on the circumstances, additional security measures are a good idea. I don't know much about ASLR implementation, but it doesn't look expensive to me.

Re:Not a major bug

[arth1]

Certainly. I was pointing out that having an up-to-date well-maintained system isn't a perfect defense, so, depending on the circumstances, additional security measures are a good idea. I don't know much about ASLR implementation, but it doesn't look expensive to me.

It is basically incompatible with "prelink", where all binaries on a system are updated with an ELF section containing all the relocation tables for libraries using predefined load addresses. This can save up to 40% startup time for some executables, as well as memory, as an external relocation table doesn't have to be built on startup. Especially on embedded systems which run and exit external programs on-demand, it can be expensive to have to abandon prelinking.

Also on build systems - if you call cc1 and cpp tens of thousands of times, it can be a real time saver. Sure, the disk cache caches the executables, but it still needs to build a relocation table every time they are called again unless the executables and libraries have been prelinked.

The downside is that you can read all the addresses from the binary, which makes it easier for a hacker with extended privileges.

And for file checksums to be effective, the programs doing file checking have to be "prelink aware" and do the checksum on an unprelinked copy. Most are prelink aware these days, so in practice that is not an issue, except for homebrew software.

So yeah, there are always trade-offs. And grey-hats might not always be in the best position to say whether an engineering team's decision not to implement specific hardening is bad. There can be other hardening or special circumstances making it an unnecessary complication or it might even slow down a system to the point that it becomes more susceptible to Denial of Service attacks.
I've seen that happen with thoughtless implementation of HTTPS for everything whether needed or not, which was the craze a couple of years ago. It not only caused increased load on servers that didn't serve anything not public, but also defeated proxy caching, and bandwidth usage spiked overnight. And I think ASLR can have similar detrimental effects for systems that don't need ASLR.

My what a headline

[chispito]

Let me guess: the bug was somebody set up them the bomb?

Re: My what a headline

[Anonymous Coward]

Affected users are advised to make their time and take off every ZIG.

Re: My what a headline

[jfdavis668]

For great justice

Re: My what a headline

[Anonymous Coward]

WHAT YOU SAY?

Re:My what a headline

[SeaFox]

I was going to guess there was this one weird trick to solve it that PC repair technicians don't want us to know!

Re:My what a headline

[Anonymous Coward]

Let me guess: the bug was somebody set up them the bomb?

All your editor are belong to us!

Re:My what a headline

[jfdavis668]

Nice. 'Course, there's an emacs command to do that.

Shouldn't this be done at the OS level?

[Anonymous Coward]

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.

Re:Shouldn't this be done at the OS level?

[sexconker]

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/...

Re:Shouldn't this be done at the OS level?

[cfalcon]

Sigh. Mod parent up pls, this is helpful.

Re:Shouldn't this be done at the OS level?

[Aaden42]

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.

Re:Shouldn't this be done at the OS level?

[Anonymous Coward]

Yet you have to wonder why this is not packaged, and why you have to set up each executable separately.

Re:Shouldn't this be done at the OS level?

[Altus]

It could break crappy legacy software that businesses are running from the late 90s and setting up exceptions was considered too much work. This is Microsoft after all. Letting legacy software hold them back is pretty much what they do.

Re:Shouldn't this be done at the OS level?

[KGIII]

Probably because, if they did, you'd complain that it is bloatware and not configurable enough? Just a guess.

Re:Shouldn't this be done at the OS level?

[bloodhawk]

because such settings do and WILL break a lot of stuff. EMET is something that needs to be carefully configured on a case by case basis, it is a great thing to configure and run if you have the skills to do so. Many of the items in it are being integrated into various parts of the OS and applications where they can be easily automatically configured.

Re:Shouldn't this be done at the OS level?

[angel'o'sphere]

It's a naive way of writing code, but there's lots of it out there. Force ASLR on, and it crashes pretty spectacularly.

That is nonsense. ASLR is a function of the loader/linker of dynamic linked libraries. It has nothing to do with compiling the code for it.

The same executable, if loadable at all, will be in fixed lay out on an OS with ASLR disabled and on a random layout if it is enabled, and the executable does not notice any difference.

Re:Shouldn't this be done at the OS level?

[Anonymous Coward]

Just be careful with the software, drivers and installers which like to spawn randomly named processes and crashing if the DEP is set to opt-out or always-on, and fuck the kernel space if you set system level SEHOP to at least opt-out. EMET changes the system level behaviour of the DEP, which will cause trouble as long as those certain software and hardware vendors like to do funny things. Blessed be Realtek whose drivers work with all mitigations enabled!

Re:Shouldn't this be done at the OS level?

[Sir Foxx]

Too bad it's incompatible with MalwareByte's Anti-Exploit.

Re:Anti-virus

[Anonymous Coward]

You can't fix stupid, but you can somewhat delay the inevitable.

Next thing to be exploited

[ThatsNotPudding]

...a basic requirement these days for software programmers to use ASLR (Address Space Layout Randomization)...

Want to place your bets that most / all ASLR systems are predictably NOT random in their randomization?

Re:Next thing to be exploited

[Zero__Kelvin]

Which is besides the point. They are basically saying: All that is required to exploit this "weakness" is to already have compromised the system to the degree that you can write to another processes code space! It is another nothing to see here, move along" article, where the person writing it doesn't understand how computers work.

Re:Next thing to be exploited

[Aaden42]

Given the (very low) complexity that's possible in bootstrap level shell code before you've found usable libraries, it doesn't take a tremendous amount of randomness to make it intractable to exploit something in an ASLR environment. You might have a handful of usable executable bytes to use. You can't call ANY library code until you find it in memory. Shell code needs to be super simple until it manages to find enough library code to do usable things and possibly load a second stage for itself from somewhere.

Re:Next thing to be exploited

[edtice1559]

It doesn't matter if it's predictable or not as long as it varies from run to run. The most common exploit that ASLR prevents is a stack-smashing buffer-overrun. You send in some data that you manage to get written to the stack. But you can't know a priori what the values will be when sending your data unless you already have some other knowledge of the system. So it's unlikely that you can exploit the buffer overflow. Without ASLR it's easy to know the addresses of system functions and to craft some data that will exploit a stack-smashing vulnerability. If the algorithm were absolutely terrible (always put function X at address YYYY on odd days) there may be some way to try to exploit. But even a week random generator is good enough in this case. The reason that a weak random generator doesn't work for cryptography is that I can analyze the message "offline" and try as many iterations as I want. When attacking a running system with a stack smashing attack, it's either going to crash or be exploited on each attempt so I won't get very many tries.

Re:Next thing to be exploited

[angel'o'sphere]

All that is required to exploit this "weakness" is to already have compromised the system to the degree that you can write to another processes code space!
Was wondering the same ... the summary makes no sense at all.

Re:Next thing to be exploited

[cbhacking]

Not *another* process. AV software consumes a ton of untrusted input - that's literally its entire purpose - and sometimes it has security flaws itself. If there's a security bug in AV filters (which isn't actually that uncommon) and ASLR is on, the malicious input can crash your AV software (which may, or may not, bring down your system and require a reboot). If ASLR is off, even for a single binary in the process' address space, though, the malicious input can completely take over your machine.

Re:Next thing to be exploited

[Zero__Kelvin]

How is that any different. Again, this isn't a vulnerability. It doesn't let you in. A vulnerability lets you in, it doesn't let you do things after you get in. That's called a computer program. You need a vulnerability to make use of this. I also need a vulnerability to make use of a shell; that doesn't mean shells are vulnerabilities.

Re:Next thing to be exploited

[Anonymous Coward]

All that is required to exploit this "weakness" is to already have compromised the system to the degree that you can write to another processes code space!

Actually without ASLR that part is not necessary. Every bit of code you need is already there at locations you know. What you need is a way to overwrite specific data to take control of the process ( for example function pointers, return addresses on the stack ) and inject your code using this. For example you might use a buffer overflow to overwrite a function pointer with the known address of LoadLibraryA and set its first argument to "EvilCode.jpeg.dll". Note that none of this touches the "code space" (generally write protected unless explicitly marked as write/execute by the process) until the process itself acts oninformation stored in "data space" ( not write protected, not marked executable ).

With ASLR a buffer overflow trying to write the location of LoadLibraryA into a function pointer or elsewhere would fail for the simple reason that the address of LoadLibraryA and any other function that could be executed will be unknown. If you are one of those people writing perfect code all the time ASLR wont protect you, if your code has bugs from time to time it may greatly reduce the security risks and I will openly laugh at anyone claiming that programs near the complexity of AV programs are perfect or in any way bugfree.

Re:Next thing to be exploited

[Zero__Kelvin]

Yeah. You still aren't getting it. It isn't a frigging vulnerability. It makes it more likely that one could find and exploit a vulnerability, but it isn't one in and of itself." That's the frigging point.

Re:Next thing to be exploited

[Bert64]

ASLR doesn't prevent exploitation, it just makes it more difficult.

Re:Next thing to be exploited

[DarkOx]

Not always the case. There are for example lots of server applications the create a thread to handle each client. Its not uncommon to be able to overwrite memory on the thread without stepping on the parent process. In many cases the parent process will handle a thread terminating unexpectedly just fine.

If its a thread pool situation you might have issues consuming the pool where a borked thread is not returned to the pool of workers resulting in a DOS but in other situations you really might be able to take as many runs at it as you like.

I am not saying this situation is common but I have seen it happen. So for server platforms where we probably care most it *is* important ASLR be well randomized if its going to provide a strong protective mechanism.

In the end though the size of the shell code you can insert without overwriting something that results in a immediate crash is probably the driver. If you have room to store some patterns you can use to search memory and locate the gadgets you need you can defeat ASLR.

Re:Next thing to be exploited

[Bengie]

Security in layer. Passwords and private keys don't prevent exploitation, they just make it harder. You can always break a password or key, they're just more difficult.

Re:Next thing to be exploited

[Zero__Kelvin]

That's correct. Now answer this question. Are passwords vulnerabilities? I mean, if I know the password and can enter it at the correct prompt I can access the system, You know what a bigger vulnerability is? Can you believe the passwords aren't randomized! If someone knows the password, and has the authority to enter it, they can access the system! Can you believe this vulnerability!

Basic feature not working

[Anonymous Coward]

Refunds!

Re:Anti-virus

[hort_wort]

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.

Isn't this the responsibility of the OS?

[Anonymous Coward]

If I'm software, I depend on the OS to grant me memory, I don't care where.

Re:Isn't this the responsibility of the OS?

[sexconker]

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.

Re:Isn't this the responsibility of the OS?

[arth1]

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.

Re:Isn't this the responsibility of the OS?

[Anonymous Coward]

And this is why we're all cows.

Re:Isn't this the responsibility of the OS?

[mikael]

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.

Re:Isn't this the responsibility of the OS?

[barbariccow]

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?

Re:Isn't this the responsibility of the OS?

[Anonymous Coward]

I've never gotten a satisfying explanation of why process X is allowed to overwrite memory belonging to process Y

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.

, thus causing Y to do BADSHIT when it jumps to that location.

Admittedly, the rationale for applications overwriting a CODE segment in the memory of another process seem to be pretty thin.

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.

SysV shared memory already works this way.

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.

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.

Re:Isn't this the responsibility of the OS?

[Anonymous Coward]

This comes to mind:
https://xkcd.com/908/

Re:Isn't this the responsibility of the OS?

[Anne Thwacks]

And we have known this since 1970!

Re:Isn't this the responsibility of the OS?

[cbhacking]

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...

Re:Isn't this the responsibility of the OS?

[sexconker]

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

Re:Isn't this the responsibility of the OS?

[sexconker]

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.

Re:Isn't this the responsibility of the OS?

[sjames]

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).

Re:Isn't this the responsibility of the OS?

[arth1]

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.

Re:Isn't this the responsibility of the OS?

[sjames]

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.

Re:Isn't this the responsibility of the OS?

[Bengie]

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.

Re:Isn't this the responsibility of the OS?

[arth1]

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.

Layman's terms?

[JoeyRox]

Looks like engineer terms to me, which is fine since most of us here are engineers.

Re:Anti-virus

[phishybongwaters]

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.

Question for the programmers

[thegarbz]

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?

Re:Question for the programmers

[slapout]

I was under the impression that it was just a compiler flag you had to add. But I've never used it and could be wrong.

Re:Question for the programmers

[Anonymous Coward]

It is a compiler flag, but at the same time you need to write your program so it doesn't stumble over itself when enabled.
This means don't use (or be vary careful with) pointer math. Some applications also truncate pointers, or assume higher bits aren't used (and reuse them for their own purpose). Both of those of course are not valid or safe techniques today, but code 20-30 years ago used it. Luckily most of those issues would have been discovered if said application was ported to 64-bit.
Most applications written today can be designed with it in mind, it's mostly legacy products that will have trouble enabling (or even using at all) ASLR.

Re:Question for the programmers

[Zero__Kelvin]

I was going to explain it to you, then I realized ...

Re:Question for the programmers

[arth1]

Compiling position-independent code (-fpic) should be the standard these days, except for specific purposes like bootloaders or hardware controllers.

Once that is done, there really is no need to randomize the load location if the system is otherwise secure. You can, if you see a reason to, but it only buys you some obscurity on an already compromised system, and it comes at a cost. But it's become bandwagon these days, to the point that it's called a "bug" if you don't do it.

Re:Question for the programmers

[thegarbz]

That partially helps, but effectively it says you only need to link to a correct library for it to just work? So back to my question is this something they have gone out of their way to disable or was there a good reason for it?

Re:Question for the programmers

[bloodhawk]

more likely they were just lazy or reliant on legacy code that didn't have the compiler flag set or that had some position dependent code. Lazy and not bothering to test it is the most likely scenario.

Re:Question for the programmers

[angel'o'sphere]

It is a matter of the OS, loading and linking DLLs or *.so's -- dynamic linked libraries -- at random places in memory. In principle you can still load them at increasing addresses as long as the order is random.

Re:Question for the programmers

[cbhacking]

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.

Editor! Editor!

[Anonymous Coward]

AVG, McAfee, Kaspersky Antiviruses Had All a Common Bug

Otay, Buckwheat!

Lack of ASLR is not a bug

[mrjb]

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.

Re:Lack of ASLR is not a bug

[cfalcon]

It's harder, but there's pretty constant zero days through browsers still. They usually put themselves on the porno sites so you can say "oh well you shouldn't go to the porno sites", which totally misses the point.

Re:Lack of ASLR is not a bug

[Anonymous Coward]

Religious web sites are more likely to be compromised than porn sites.

Re:Lack of ASLR is not a bug

[arth1]

Religious porn web sites, on the other hand, seem reasonably safe.

Re:Lack of ASLR is not a bug

[cfalcon]

I'm still not sure how they get that. It's certainly true that decentralized low security church websites can be owned and stay owned, but... how many people visit them? When a major adult ad network gets compromised, it serves the bad add a zillion billion times before someone catches it- even if they catch it later that same day.

the biggest problem was the vendor.

[nimbius]

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.

Re:the biggest problem was the vendor.

[dejitaru]

Best description of modern AV I've seen...

Re:the biggest problem was the vendor.

[CrashNBrn]

most traffic will grind to a glorious halt while its inspected, detected, and

Don't you mean, "Injected, Inspected, Detected, Infected, Neglected and Selected."
--- Arlo Guthrie.

Re:the biggest problem was the vendor.

[truck_soccer]

I have noticed that several new laptops with expired norton trials would effectively permanently enable airplane mode until a full/clean uninstall.

Re:the biggest problem was the vendor.

[Anonymous Coward]

The best security product around for several years now is found at adblockplus.org.

Re:the biggest problem was the vendor.

[Anonymous Coward]

You're lucky that your comment is far enough down the thread that APK didn't notice it. In fact, we're all lucky that APK didn't notice it.

And for the record, I think APK and Coren22 are two personalities of the same schizophrenic person.

Re:the biggest problem was the vendor.

[operagost]

All network access has been disabled for your protection until your antivirus is updated... $99 please.

Re:the biggest problem was the vendor.

[Anonymous Coward]

I like the built in Kaspersky banner blocker. It's uh... too bad about the rest.

Re:the biggest problem was the vendor.

[Anonymous Coward]

There needs to be a book called The Pains and Sufferings of A Digital Hunter-Gatherer, from which the parent should be a quote from.

Re:the biggest problem was the vendor.

[Kazoo the Clown]

You forgot to mention that fearmongering about threats sells more products. An unscrupulous AV maker could even release malware/worms/viruses into the wild simply to drive more people to buy AV products. How do we know they're not? Conflict of interest, anyone?

Re:the biggest problem was the vendor.

[Anonymous Coward]

Adblock latitude on PM does a better job BUT that isn't true these days. Noscript and adblocking etc etc don't stop a lot of threats any more as a lot of vectors of infection have changed their game due to them. We're at the point where a significant number have followed suit so even those lagging way behind are aware and plan for adblocking presence.

Better than nothing but not good enough alone andf these comments stop the white side being one step ahead or even behind! While malware devs are upping their game meanwhile the socalled tech savvy people are spouting stuff that is at least 10years out of date.

Re:Anti-virus

[Anonymous Coward]

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.

That was brought up at Kiwicon a year ago

[SumDog]

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.

Re:That was brought up at Kiwicon a year ago

[Tharkkun]

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.

Apparently that's been solved now which was the whole point of the article.

Re:Anti-virus

[Anonymous Coward]

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.

Re:Anti-virus

[Aaden42]

Honestly I'd think the truth would be better at keeping customers.

"You got pwn3d because you clicked the 'pwn me anyways' button when our software tried to save your butt."

versus

"The one time you actually got something legit, our software was too stupid to catch it because oh BTW, signature based malware does bugger all for zero-days or targeted attacks."

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.

Re:Anti-virus

[fredgiblet]

Yes, but you appear to not be an idiot. Most end-users are idiots.

Not much faith in security software

[Anonymous Coward]

I do not really have much faith in security software. Neither does many security experts. Most say at best its a band aid trying to fix a open wound. Smarter end users would go much farther in preventing malware. The other issue I have with most Anti Virus solutions. Is the default quick scan which basically ignores a lot of potential hiding places just to make scans go faster. Really a dumb move, and just causes a scan to miss something over and over until it affects the system so bad you end up doing a full scan. Malware bytes is good only because your using it the way you should. You scan all files and folders to find the malware.

Re:Not much faith in security software

[Kazoo the Clown]

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.

Re:Anti-virus

[Anonymous Coward]

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...

Re:Anti-virus

[Tharkkun]

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.

Re:Anti-virus

[KGIII]

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.

Re:Had All a Common Bug

[Anonymous Coward]

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.

Re:Anti-virus

[KGIII]

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.

What do you want to be this was a requirement?

[Grog6]

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.

Re:Anti-virus

[Anonymous Coward]

You mean debunked by FSB. How we know is classified. Maybe Snowden will leak the details.

Re:Anti-virus

[KGIII]

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.

Re:Anti-virus

[Anonymous Coward]

AV checks a box off. I know many companies that demand McAfee [1] be run on even the Linux and AIX machines, not because they will catch some AIX virus, but for the legal eagle reason, of checking the box stating, "all computers on our internal subnets have AV software running on them."

In reality, the only AV program I've seen do anything is MalwareBytes, because it can block by IP address, which is useful for blocking places that spew 0 day malware. However, the best protection one can have is click to play functionality, AdBlock, and putting the web browser in a sandbox, VM, or even both (to minimize the chance of malware being able to get to the hypervisor.)

Because AV is more of something to make the lawyers happy, it is wise to just go with the cheapest... and Microsoft's SCOM/SCCM/SC* tools have the option for client-side AV, so that is probably the easiest route. For other operating systems, McAfee is the go to standard.

[1]: McAfee 8.7 for pre-RHEL 7 and downstreams, McAfee 8.8 for newer, due to the kernel change.

I guess ignorance isn't bliss after all?

[cbhacking]

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:

process X is allowed to overwrite memory belonging to process Y, thus causing Y to do BADSHIT when it jumps to that location

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.

why stack overflow is still a problem

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.

why process X can heap spray the fuck out of memory and have that shit affect process Y

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.

OS should be managing memory

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.

Address locations should be randomized

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.

Memory should be zeroed out upon allocation (or deallocation, or both)

Not *really* relevant here, but I'll add

Re:I guess ignorance isn't bliss after all?

[sjames]

Not *really* relevant here, but I'll address it anyhow. There's a performance cost to doing this. Normally it doesn't matter, because allocated memory immediately gets overwritten and deallocated memory can't be accessed at all anymore. Why waste the time clearing memory before handing it to the process (which will overwrite whatever you wrote there anyhow)? Some languages do this, but it's one of the reasons those languages are slower than C/C++ (though admittedly usually not a *major* reason).

Zeroing newly allocated memory is actually one of the few valid points. In a modern CPU, the cost to zero a page is quite small and makes sure no information leaks from one process to another. That must be handled by the OS since you can't use the honor system for other people's code. For example, an unprivileged (but authorized) user could write a program that does nothing but mmap and munmap anonymous pages. If the mmap-ed pages are not zeroed prior tyo mapping them in, the unprivileged program can scan it's legitimately granted pages for known structs, potential passwords (from I/O buffers) and other such information it is not authorized to have.

Re:I guess ignorance isn't bliss after all?

[david_thornley]

That's why Heartbleed was bad: the allocated memory wasn't zeroed before use. Using calloc() (which zeroes allocated memory) rather than malloc() which doesn't) would have made it much more difficult or impossible to exploit the basic flaw.

Re:I guess ignorance isn't bliss after all?

[cbhacking]

My bad, you are correct. The OS does actually clear memory when it is newly allocated to a program (or possibly when it is released; I'm not sure). That would, otherwise, be a huge security risk.

There's no need to clear memory each time memory is re-allocated *within* a program, though, except as a debugging technique (detecting the use of uninitialized memory), for which a distinctive pattern is usually used instead of simply zeroing the data. Memory managers usually handle many allocations smaller than full pages, so calling free() (or delete) doesn't always immediately return memory to the OS. That memory is usually re-allocated to a different buffer or object in short order, and zeroing it between those times (while still owned by the process) is wasteful.

Re:I guess ignorance isn't bliss after all?

[cbhacking]

Incorrect.

Heartbleed wasn't exposing memory from other processes, it was exposing memory from the address space of the vulnerable process. The data leaked in Heartbleed attacks was all data that the program had put into memory itself. For example, if you create a HTTP request to a login page, and populate it with credentials, and then try to send it over an HTTPS connection using OpenSSL for the TLS, that request (with its plain-text credentials) could be leaked out of memory by Heartbleed. Similarly, OpenSSL on the server needed to know the private key of the server in order to decrypt and sign messages, so that private key was stored in memory by OpenSSL itself and could be leaked in a Heartbleed attack.

Using calloc() wouldn't have made it harder to exploit the basic flaw (leaking memory from the process due to buffer overread) at all; at best, the 64k of leaked memory would have had more zeroed bytes in it. That might have been a *small* help, if those bytes had previously stored sensitive data that was then freed and re-allocated for a different use but hadn't yet had new data written into them. That's an extremely unlikely scenario, though. More likely, either the sensitive data would never have been freed, or the re-allocated data would have been overwritten, or the sensitive data would have been freed but kept in memory (remember, calloc() doesn't wipe until you call it to allocate the memory; if you want to zero bytes before freeing them you have to use a function to do that).

Now, part of the problem *was* due to the way OpenSSL (through absolutely no fault of the operating system) handles memory; rather than having the OS and runtime library do memory management, OpenSSL grabs (grabbed? Maybe they fixed this) a pile of memory from the OS, and then "allocates" and "frees" it using an internal memory manager. This meant that Heartbleed was virtually guaranteed to find 64k of contiguous memory, without the holes where the OS hadn't mapped any page into the program's address space. Such holes would have caused an access violation / segmentation fault when Heartbleed tried to read them, and crashed the program; bad for server uptime, but better than exposing a bunch of data that is sensitive enough you wanted to transmit it through an encrypted channel (or leaking the encryption key for the channel itself, etc.)

Re:I guess ignorance isn't bliss after all?

[sjames]

Agreed, uncleared memory from the heap can only tell the program what it already knew.

Re:I guess ignorance isn't bliss after all?

[david_thornley]

IIRC, Heartbleed was a matter of saying "If you're a server, send me back the word 'cat', 1000 characters", after which the server would malloc 1000 bytes, put "cat" and possibly a terminating null character in the first three or four, and send it back. The other 996 or 997 bytes would be whatever was left in that memory. Rinse and repeat until you've got all the stuff you need. I don't remember there being anything like normal buffer overread. Therefore, zeroing out the kilochar would have zeroed out everything the attacker got back.

Part of the problem was indeed the custom memory allocator, and it seems to me that, if they were going to write their own, adding a memset() to change a chunk of memory to all zeros on free() would have made a lot of sense. Unfortunately, OpenSSL prioritized raw speed over safety.

Use of ASLR and DEP in AV software still lacking..

[Aryeh Goretsky]

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

NSA

[Anonymous Coward]

The NSA / Tailored Access Operations use this "feature" every day.

IN SOVIET RUSSIA, ANTIVIRUS IS BUG

[Anonymous Coward]

Oh wait, no, that's everywhere.

What's antivirus for? I don't get infected!

[Anonymous Coward]

See subject: Modern threats = blocked via APK Hosts File Engine 9.0++ SR-4 32/64-bit http://start64.com/index.php?o...

---

FREE, not 'souled-out' to advertisers + adds speed, security & reliability. Does FAR more w/ FAR less more efficiently vs. redundant browser addons & local DNS servers @ home + fixes DNS' many security issues & it stops a LOT of tracking @ webpage + DNS levels via 1 file you NATIVELY have - firewalls do the rest (on less used IP address trackers vs. host-domain name type).

---

It obtains data vs. threats & for adblocking from 10 reputable security community sites!

---

SPEEDS YOU UP 2 ways (adblocks + local RAM cached favorite sites @ TOP of hosts for fastest resolution speed vs. remote DNS (aids reliability)) vs. other "so-called security 'solutions'" SLOWING YOU!

---

All that via something you natively have vs. "bolting on browser addons 'MOAR'" that's usermode slower & increases messagepassing, cpu + ram overheads!

---

MalwareBytes' hpHosts Admin (MalwareBytes employee who verified it's source as safe http://forum.hosts-file.net/vi... ) hosts & recommends it -> http://hosts-file.net/?s=Downl... & MalwareBytes = BEST antivirus per this VERY recent testing of them all http://www.av-test.org/en/news...

&

It's safe proven by 57 antivirus programs recently in BOTH its 64-bit model https://www.virustotal.com/en/...

+

Its 32-bit model too https://www.virustotal.com/en/...

Its installer too -> http://f.virscan.org/APKHostsF...

---

* "The premise is quite simple: Take something designed by nature & reprogram it to make it work for the body rather than against it..." - Dr. Alice Krippen: "I am legend".

APK

P.S.=> By "yours truly" - "The Lord of Hosts" so-to-speak:

"The image this title brings to mind is of a mighty military commander, one who can at a mere word summon rank upon rank of protective power" from https://answers.yahoo.com/ques... & THE WORD = hosts!

(Accept NO substitutes!)

...apk

Basic ASLR was not implemented ..

[nickweller]

This wouldn't be a problem if the MMU did its job properly ..

Article is Incorrect about McAfee

[Anonymous Coward]

The article is incorrect about McAfee Enterprise 8.8 ASLR was patched several years ago in Patch 4 according to their web site and the are currently at Patch 6 plus several hotfixes. Patches are like Service Packs for Windows. -WS

Windows 7 already has it

[Billly Gates]

So basically stop using WIndows XP and you won't be impacted

Re:Anti-virus

[Bert64]

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.

Re:Anti-virus

[higuita]

Do people still uses windows?! WTF!! :D

Re: Anti-virus

[Anonymous Coward]

You should know then, that Malware Bytes specifically say they are not an Antivirus program.

Re:Anti-virus

[jrumney]

And you can fix stupid with software by locking down and limiting the amount of stupid things mr stupid can do.

If you define work as stupid, then you've probably succeeded with that IT policy.

AdBlock+ = inferior & 'souled-out' vs. hosts

[Anonymous Coward]

Can adblock+ do 16 things hosts do 4 speed, security & reliability:

1.) Protect vs. bad sites (past ads)
2.) Protect vs. fastflux botnets + stop C&C talk
3.) Protect vs. dynamic dns botnets + stop C&C talk
4.) Protect vs. DGA botnets + stop C&C talk
5.) Protect vs. downed DNS (4 reliability)
6.) Protect vs. DNS redirect poisoning
7.) Protect vs. trackers
8.) Protect vs. spam
9.) Protect vs. phish
10.) Protect vs. caps
11.) Get past dns blocks
12.) Keep off dns request logs
13.) Speed up surfing (adblock & hardcoded favs)
14.) Works on anything webbound multiplatform.
15.) EZ data control
16.) Block ads better vs. addons more efficiently

* ANSWER ="NO" on ab+ doing it as well or @ ALL + hosts = on devices natively.

APK

P.S.=> Ab+ does less vs. hosts less efficiently - hosts do MORE w/ less + Hosts start w/ IP stack before REDUNDANT inefficient addons BEGIN operation (as 1st resolver).

---

Ab+'s a 128-151mb memory hog http://cdn.ghacks.net/wp-conte... (hosts use 3-11mb w/ my program initially). Even FireFox 41 adblock eats 65++mb http://www.ghacks.net/2015/06/...

---

ClarityRay defeats it seeing addons via native browser methods!

---

Ab+'s bribed not to work by default http://www.businessinsider.com... & ABP bought out adblock http://www.theregister.co.uk/2...

---

Ab+ adds complexity in slower usermode (w/ more messagepassing overhead + context switch vs. hosts in kernelmode).

---

AdBlock's SLOWER: http://superuser.com/questions...

---

What's best?

APK Hosts File Engine 9.0++ SR-4 32/64-bit http://start64.com/index.php?o...

MalwareBytes' hpHosts Admin (MalwareBytes employee who verified its source is safe http://forum.hosts-file.net/vi... ) hosts & recommends it http://hosts-file.net/?s=Downl... & MalwareBytes = BEST antivirus http://www.av-test.org/en/news...

&

It's safe per 57 antivirus programs in BOTH its 64-bit model https://www.virustotal.com/en/...

+

a 32-bit model too https://www.virustotal.com/en/...

& Installer -> http://f.virscan.org/APKHostsF...

Re: Anti-virus

[jpenguin]

I run arch, but I do keep windows around for compatibility. I just run free Avast

Re:Anti-virus

[david_thornley]

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.)