Hacker Bypasses Windows 7/8 Address Space Layout Randomization

hypnosec writes "Microsoft upped its security ante with Address Space Layout Randomization (ASLR) in Windows 7 and Windows 8, but it seems this mechanism to prevent hackers from jumping to a known memory location can be bypassed. A hacker has released a brilliant, yet simple trick to circumvent this protection. KingCope, a hacker who released several exploits targeting MySQL in December, has detailed a mechanism through which the ASLR of Windows 7, Windows 8 and probably other operating systems can be bypassed to load a DLL file with malicious instructions to a known address space."

Comments

Step One

[Anonymous Coward]

Click on link in article...

the only thing Microsoft and others can do is...

[logicassasin]

... delay the inevitable.

Every new security feature they can dream up can and will be bypassed with enough time.All they can do is build it hard enough that it takes more time to crack.

Re:the only thing Microsoft and others can do is..

[bigstrat2003]

I'm sure they're aware of that, as is anyone with a shred of knowledge about computer security (or hell, security in general). What is your point?

OMG that is childishly simple

[Anonymous Coward]

Fill up memory, then free some until enough is free to load the DLL.

Re:OMG that is childishly simple

[gnasher719]

Fill up memory, then free some until enough is free to load the DLL.

Which works fine with a 32 bit operating system. With 64 bit, filling up memory looks like a hard job to me.

Re:OMG that is childishly simple

[BitZtream]

VirtualAlloc's without requiring a backing store work just fine for consuming enough of the 64 bit virtual backing store that it doesn't matter.

Asking for space but telling the OS you don't need it right NOW will get you an address space with no memory used until you cause a page fault by accessing it causing a page of real memory to actually be attached to it. Until that point, its just an entry in the page table, to which its easy to fill up, your computer does it every boot.

Obvious?

[Todd Knarr]

And this exploit wasn't obvious from the start? When the heap and dynamically-loaded code share the same address space, this vulnerability always exists. We knew this 30 years ago. It took someone this long to apply it?

Re:Obvious?

[icebike]

True, but that just shows how often demands for memory can happen in a modern multi-core machine.
Microsoft didn't implement ASLR until 2007 (Vista).

With so much multitasking going on under the processors of that time and today, it would suggest that any attempt to saturate memory would inconvience many tasks, many of whom would have allocation requests pending, probably for smaller chunks than your rogue task would require. These would stack up while your were saturating memory, and be serviced upon first, as soon as you released your block. There is no way you can do a system call tor free-memory AND follow it with DLL load command without yielding some time slots on the processors and memory allocation routines. The busier the machine the more likely this is to fail because allocation requests are always in flight.

Re:Obvious?

[Todd Knarr]

Processes would be irrelevant, since each one has it's own address space (the exploit works on the process level, not down on physical memory). And with NOP slides and other tricks, you don't need to pin down the location to the byte. Allocate one large block that'll be forced into the end of memory (start too large and work down until it succeeds, it'll have been allocated at the end of the heap because that's the only place that has a single contiguous block big enough open), allocate smaller blocks until the allocation fails (you've now filled up the heap), then resize your big block down enough to open up a hole for the DLL (it'll be loaded immediately after your big block since that's where the hole was opened up). The only real trick is chopping up the low portion of the heap and leaving enough small blocks there that most normal allocation will be happening below your big block while the only hole big enough for the DLL is above the big block, and it's not like that's all that challenging a programming problem.

And the amusing thing is that the x86 architecture allows you to make this sort of exploit physically impossible (at least without cracking ring 0 first). Separate code, heap and stack and place the heap and stack in non-executable segments, and any attempt to try this kind of thing just results in the kernel getting a memory access exception and terminating the offending process.

TLDR

[YodasEvilTwin]

Fill memory until only enough space is left for loading whatever it is you're trying to load. Obviously the location is predictable since there's only one spot for it.

Re:TLDR

[asmkm22]

This appears to be a 32-bit exploit, at least as tested.

Re:TLDR

[Anonymous Coward]

Not only that but the point of ASLR is to randomly locate system DLLs, not some evil hacker code. This does nothing to break the intended use of ASLR.

Re:TLDR

[The MAZZTer]

It is very uncommon to see 64-bit web browsers, as most plugins only come in 32-bit flavors. So running a 64-bit Windows won't matter for 99.99% of users. Only IE offers a 64-bit version, at least theirs is the easiest to find and use. Firefox might offer one I think? But it won't be the default download. Chrome does not yet offer one for Windows.

Re:TLDR

[PPH]

This has the added benefit of stopping a single script from using up all of your memory.

Its as if a million JavaScript developers cried out in terror and were suddenly silenced when we stopped them from using all our system's resources.

Re:TLDR

[Shoten]

This appears to be a 32-bit exploit, at least as tested.

That depends on what you mean by "32-bit exploit." He's doing it as 32-bit code because then you have a LOT less memory to fill up. Even better, you have a predictable amount of memory to fill. It affects operating systems which are 64-bit; he's not doing it in a way that makes those OS versions safe, but for his own convenience of exploitation. There's another added benefit as well...not only is it easier to fill up the RAM of a 32-bit memory space, but in a 64-bit environment you won't be as likely to slog the machine down overall while you do so.

Re:TLDR

[qbast]

That's the problem with security - it is easy to overlook one stupid trick.

Re:TLDR

[gnasher719]

There's another added benefit as well...not only is it easier to fill up the RAM of a 32-bit memory space, but in a 64-bit environment you won't be as likely to slog the machine down overall while you do so.

Quite the opposite. With 64 bit, the logical address space is many orders of magnitude bigger than available RAM. So you end up thrashing your virtual memory quite soon. However, the logical address space is still orders of magnitude bigger than your swapspace (4 TB if we are generous), so it's quite impossible to fill the 64 bit address space.

Re:TLDR

[sexconker]

It's not as hard as it sounds. Create a malicious web page that does something to fill memory (create a lot of javascript objects or something). At that time, put an active-X module on the page. This will probably trigger the loading of the Active-X dll, since it's unlikely that the user will have encountered an active-X page since they last launched internet explorer. (if they have, then this exploit might not work).

Then you are ready to launch some exploit code into the active-X DLL, and you know the address you need to smash the stack for fun and profit.

I don't understand how he knows the addresses. Virtual memory and ASLR result in the a process knowing the following:

Data X is at Location A
Data Y is at Location B
Data Z is at Location C

A,B,C are randomized offsets.
If you fill everything up, you still only have a list of random offsets. You could then kill off some objects and then HOPE that the next thing you load (a target DLL for example) fits into the freed-up space AND the OS drops it in the same physical space and presents the same virtual offset to the process. On a 32-bit system the OS MAY reliably stuff shit into the expected offset IF the whole thing doesn't go tits up when you cross the heap/stack line AND no other process dares ask for a byte of memory during your attempts. But on a 64-bit system you're shit out of luck because you'll never fill up the memory.

Regardless, the fix is trivial - when memory is that scarce, juggle shit around a bit when you allocate new crap.

Re:TLDR

[BZ]

Actually, the address space is in fact key. The goal is to load a known DLL at a known address in the process address space, not a known address in physical RAM, because process address space is what you can see in the code that you will then try to run that will try to call into the DLL.

So in a 64-bit process, this technique is pretty hard to pull off, since it does in fact rely on address space exhaustion.

Cool hack

[sl4shd0rk]

So basically use javascript to allocate all available memory. Once you get the allocation exception, begin freeing small chunks. After each free, try loading an Active X DLL (target DLL exploit). As soon as you have freed enough blocks, the DLL will load into the space you freed. Essentially bypassing any ASLR -- there is nowhere to randomize too except the freed memory.

Re:Cool hack

[asmkm22]

This doesn't seem to be a fundamental problem with ASLR, at least. Things could be patched to prevent something from filling up memory like that, I assume.

Re:Cool hack

[fisted]

Be sure to tell me when you found that infinite-memory patch.

Re:the only thing Microsoft and others can do is..

[icebike]

True, but you have to consider that ASLR was never intended as an unbreakable security feature. It was always just an impediment to an easy exploit of jumping to a fixed address. There are common tricks published for getting around ASLR to some degree.

Re:Will not work on 64 bit

[Carnildo]

The address Space of 64 bit processes is vast compared to available memory. The process will run out of memory before the address Space could be filled.

Every 64-bit OS I know of uses delayed allocation: when a program asks the OS for memory, the OS assigns a chunk of address space, but doesn't assign memory (physical, virtual, or otherwise) until the program actually tries to use it. It's quite possible for a program to exhaust the available address space without actually using very much memory.

Re:Who would've guessed?

[benjymouse]

Just another in a long list of Microsoft/Windows security fails. Big shocker.

So would you rather use an OS with much, much weaker ASLR, like Linux where large parts of the OS and libraries are just loaded at predictable locations without any memory squeezing in the first place?

BTW, this technique will not Work on 64 bit processes. On OSes with weak ASLR and predictable locations for certain modules, moving to 64bits does not help on iota.

Re:OSX invulnerable

[CODiNE]

You sure about that?

Mac OS X

Wikipedia ASLR
Apple introduced randomization of some library offsets in Mac OS X v10.5 (released October 2007).[16] Their implementation does not provide complete protection against attacks which ASLR is designed to defeat.[17][18][19][20]Mac OS X Lion 10.7 has improved ASLR implementation for all applications. Apple explains that "address space layout randomization (ASLR) has been improved for all applications. It is now available for 32-bit apps (as are heap memory protections), making 64-bit and 32-bit applications more resistant to attack."[21] Since OS X Mountain Lion 10.8 the kernel as well as kexts and zones are randomly relocated during system boot.[22]

Re:Point of ASLR

[benjymouse]

The point with ASLR is for the good process to not be infiltrated by a bad one. I dont see the problem of loading a dll in a known memory location, unless you apply that to a dll of the good application, without it detecting that.

But when you arrive at that point of being able to do that, what's circumventing ASLR good for?

You are correct that ASLR it a *mitigation*; not a failsafe protection in itself. Nor is this weakness and exploitable vulnerability *in itself*. An attacker still needs an actual exploitable memory corruption bug. But when one is found, the technique referred to as ROP can be used to bypass DEP/NX protections to gain foothold. The answer to ROP (where the attacker uses fragments of executable code loaded in known locations) is ASLR. This technique squeezes memory to take the "randomization" away from ASLR.

Re:Will not work on 64 bit

[Jahava]

The address Space of 64 bit processes is vast compared to available memory. The process will run out of memory before the address Space could be filled.

Unfortunately many browsers still run 32bit even on 64bit systems because of plugin compatibility. Time to move to 64 bit browser processes.

Note also that this attack is only feasible against browsers. Like other ASLR bypasses it will not Work against e.g. Outlook or Word where the attacker has very limited ability to control memory allocation.

It's worth mentioning that the critical component here is using client-executed trusted/sandboxed code (in this case, JavaScript) to exhaust the memory space. The code must be able to allocate memory, and it must be able to identify the virtual address of the memory that it allocated, else when it begins opening a hole for ASLR determinism, the shellcode won't know where to target.

Any client-side language that can allocate arbitrary memory and identify the allocated address should be able to be used in this capacity. JavaScript is identified in the PoC, but I wouldn't be surprised at all if VBA can do the job in Office (e.g., Word/Excel/Outlook/etc.), and if other trusted/sandboxed codes could do the job in other languages (Java, C#, etc.).

An obvious defeat is to either have application-enforced restrictions on embedded language allocations (e.g., I can allocate up to 10G of memory, but my embedded script can only allocate 1G) to guarantee the presence of some random areas. Another option would be to allocate dynamically-loaded library memory in a different restriction context than standard process memory so that their respective allocations don't draw from the same pool.

Address randomization - security through obscurity

[Animats]

Address space randomization is a form of security through obscurity. It's also an admission that your system security really sucks. The concept is that the code is full of exploitable buffer overflows, but address space randomization will make it harder for exploits to patch the right target area. So low-level exploits tend to crash the system, or at least just mess it up, rather than getting their code executed.

There are now "address spraying" attacks which counter address space randomization, so this is already an obsolete defensive measure.

Re:Other browsers and operating systems?

[benjymouse]

Is it possible to "rewrite the instruction pointer of the processor to a known heap address
where the shellcode resides quite deterministic" on, say, Firefox on Gnu/Linux [given that flash and java are disabled in the browser]?

This is an ASLR bypass technique, not an actual exploitable vulnerability by itself. The attacker still needs an exploitable memory corruotion vulnerability to start the attack. ASLR+DEP is designed to make it much harder for an attack to gain foothold in the face of such an attack.

An exploitable memory corruption bug could for instance be a buffer overflow or use-after-free bug in a jpeg or gif library. Such a bug allows a small window of opportunity for an attacker. However, with DEP he will have a hard time injecting actual executable code into the attacked process. Instead he will use a programming technique termed ROP (return oriented programming) where he will trampoline to code carefully chosen code fragments residing at known locations.

Think of a buffer overflow bug which allows the attacker to overwrite the return address of the vulnerable function. Instead of returning to the point where thebfunction was called, the instruction pointer will return to whatever the stack was overwritten with through the buffer overflow. The attacker *still* has not gained full control. But if he can overwrite with an address pointing to a piece of code which does all or part of what he needs he can use that. If it only does part of what he needs but ends with a RET, he can make sure that the stack above the original return address points to the Next piece of usable code.

This technique will Work in any process and on any operating system where the attacker is allowed relatively free access to allocate memory. Think browsers where JavaScript can be used to allocate/squeeze memory.

So yes, this is in no way Windows specific. It is interesting because at this point the Windows ASLR is pretty much state of the art. Only recently has OS X achieved randomization of the "dyld" - the OS libraries. Even a single library being loaded in a predictable location may be enough for the agtacker to squeeze through. Linux ASLR is weaker (not as random) and many Linux libraries are still loaded at perfectly predictable locations.

Re:the only thing Microsoft and others can do is..

[Anonymous Coward]

Every new security feature they can dream up can and will be bypassed with enough time.All they can do is build it hard enough that it takes more time to crack

I'm sure they're aware of that, as is anyone with a shred of knowledge about computer security (or hell, security in general). What is your point?

Legend has it that Finnish field marshal Mannerheim was interviewed by a journalist after the Winter war. The journalist asked him if he had at any time doubted that the Finns would eventually be defeated by the Soviets. Apparently the old man sent the journalist a sharp look and then replied that just because the odds are against you it does not mean you have to make life easy for your attacker. Dunno fi that is true but if I was in computer security, that's what my outlook would be... come up with nasty defences, whey they are breached you ambush the bastards and then come up with a new line of even nastier defences.

It's already patched, and caught

[cheapredwine]

From TFA: The PoC makes use of the following vulnerability and therefore for testing the PoC the patch must not be installed. MS12-063 Microsoft Internet Explorer execCommand Use-After-Free Vulnerability This vulnerability is identified as CVE-2012-4969. So it's already preventable. (Yes, yes, patching is a bitch, doesn't happen, etc etc.) And also, it's already detected: Please note that Windows Defender detects the Win8 PoC as being an exploit and blocks execution. Yes, it's an interesting PoC, but it's not exactly taking my breath away overall.

Re:the only thing Microsoft and others can do is..

[fahrbot-bot]

So are only safe if we run an OS on an isolated partition which has nothing but a web browser and the other partitions are automatically unmounted while the web browser OS is working?

Actually, we are only safe while the system is powered off, disconnected from all cabling and still in the box it came in. Trust me. After dealing with security weenies and various system lock-down methodologies for many, many years, a truly "secure" system (to their satisfaction, anyway) is unusable and you might as well not even bother to unpack it.

Re:Will not work on 64 bit

[benjymouse]

VirtualAlloc with MEM_RESERVE will commit address space without reserving backing store.

Right. Can you show me how to do that from JavaScript in a browser?

Because that is what this is about. JavaScript *does not* have any function or low level binding to *reserve* memory space. It only has the ability to actually *allocate* memory (MEM_COMMIT). And that will exhaust the commit limit *long* before the address space is exhausted to the point where a library load address is predictable.

Point still stands. The technique described in the article *will not* work against 64 bit processes.

Re:ASLR? More like ASLnotsoR.

[phantomfive]

That won't work, if your address is only slightly off, then you can start your exploit code with a bunch of NOPs and then jump right in the middle of it. Then you don't need to know the exact address.

Also, returning slightly less memory than requested is a good way to get people to stop using your OS, when basically every software starts crashing.

Re:the only thing Microsoft and others can do is..

[rubycodez]

didn't work for the japanese, because no possibility of resupply, reinforcement, or retreat. Defeat thus assured. About 21,844 killed, 216 survivors taken prisoner. A horrible bloodbath and yes 6800 american soldiers killed, but it didn't "work"

Re:the only thing Microsoft and others can do is..

[Luckyo]

Japanese on Iwo Jima was "desperate defense with no hope of victory".

Finnish was "pre-planned defense in order to make enemy bleed so hard, that even Stalin would decide that gains aren't worth the cost".
It succeeded twice with quite possibly the single most insane-looking numbers in history. It was crazy enough to warrant wikipedia page screenshot becoming an internet meme:
http://www.google.com/imgres?imgurl=http://data.whicdn.com/images/18990146/finland-be-afraid-be-very-afraid_thumb.jpg&imgrefurl=http://weheartit.com/tag/soviet%2520russia&h=200&w=240&sz=11&tbnid=e8G9SZNgTBMY-M:&tbnh=87&tbnw=104&zoom=1&usg=__Tk2w1zc2NxuOzEu4OclPzzBZzVc=&sa=X&ei=RjoDUfekBYbKtAaMuYCwCQ&ved=0CCEQ9QEwAw

This success was repeated in 1944 where Finns faced the single biggest offensive in the entire WW2 war European theatre. Soviets focused 20 artillery pieces per every kilometer of the front line. They could literally dig people out of trenches with this much artillery. In the end, finns held out and even pushed back in spite of being completely outnumbered and outgunned. Stalin remembered the lesson from Winter War and signed a peace treaty with Finland allowing it to stay independent again. It ended up going in history as the only country mentioned in Molotov-Ribbentrop that didn't get conquered by either Germany or USSR.

The main difference between these strategies is that Japanese viewed their empire as something holy and to be defended to the death, to the point where survivors should commit suicide if they failed. Finns viewed their country as something of theirs, and to be defended for as long as it remains defensible with as little losses as possible. Key difference was that finnish commanders valued lives of their soldiers very highly for the times. Japanese commanders treated their soldiers as completely disposable pawns. Difference could be explained by the fact that Japan is one of the most populated regions on the planet, while Finland is one of the least populated ones.

It's the advantage of not being a huge country with long and proud history. You learn that to stand between the giants and survive, you need to show humility to the giants in most things, but also show that when needed, you can sting them so painfully, that any potential attempts of capture will not be worth it. And most of all you learn that when you're losing, minimize your losses so you can fight another day.

Simple indeed

[Impy the Impiuos Imp]

> A hacker has releasedÂa brilliant, yet simple trick to
> circumvent this protection

Beating up the guy after he logs in?

Re:the only thing Microsoft and others can do is..

[Nimey]

It was still better than the previous Japanese strategy of meeting us at the beaches and then banzai charges. Kuribayashi did quite well with the hand he was dealt.

Re:the only thing Microsoft and others can do is..

[metrix007]

Unnecessary. Absolutely no advantage over just keeping updated and running as non-admin.It's the type of thing people who don't understand security do and then get MITMed without even noticing.

Re:the only thing Microsoft and others can do is..

[BitZtream]

True, but you have to consider that ASLR was never intended as an unbreakable security feature. It was always just an impediment to an easy exploit of jumping to a fixed address. There are common tricks published for getting around ASLR to some degree.

Anyone who truly understands how computers work and specifically how ASLR does what it does should be fully aware that ASLR only stops absolutely stupid hacks. All important addresses can be looked up. They have to be looked up to be useful. If nothing can lookup an important address, nothing can really do anything to it, making it not real useful for computing in general, let alone hacking.

To get around ASLR all you have to do is consult ... the built in lookup table which is at ... A FIXED ADDRESS as it has to be able to be found for everything to work.

All ASLR does is means you need to spend a few extra clock cycles determining where you want to do your exploitation rather than hard coding it into the file.

Let me restate that ...

All ASLR does is means you have to use proper programming technics in your exploits rather than being lazy and hard coding your values.

The only security it provides is against a bug accidentally causing the same sort of crash twice in a few causes and preventing a few exceptionally lazy people from writing working exploits. Unfortunately, most of the people writing exploits are far from lazy, making ASLR effectively worthless and a good waste of a considerable chunk of processing time as now a metric fuckton of addresses have to be looked up rather than known in advance.

The 'common tricks' to 'get around ASLR' are 'write proper code'.

ASLR is not so easy to bypass

[r00t]

You're right that it boils down to just looking up the address, but see, this is a chicken-and-egg problem. You're wanting to determine addresses so you can run code, but you must run code in order to look up addresses!

You might as well say that it is easy to get a dinosaur and a dinosaur egg. To get the dinosaur, just wait for a dinosaur egg to hatch. To get the dinosaur egg, just wait for a dinosaur to lay one. Problem solved, right???

Re:the only thing Microsoft and others can do is..

[Luckyo]

The point is, that Iwo Jima was a battle they knew they lost, and they threw all of their soldiers under a proverbial bus. Those who survived mostly committed seppuku.

Microsoft is definitely not doing that. They're doing what GP said Mannerheim did, strategic retreats and attacks on vulnerabilities that show up. Sometimes they lose a battle, like they did in this case, but they keep on winning the war. I.e. the OS stays overall secure enough for most users even if some aspects of its security suffer defeats every once in a while.

ASLR lasted for years uncracked for example.

Re:the only thing Microsoft and others can do is..

[Anonymous Coward]

Anyone who truly understands how computers work and specifically how ASLR does what it does should be fully aware that ASLR only stops absolutely stupid hacks. All important addresses can be looked up. They have to be looked up to be useful. If nothing can lookup an important address, nothing can really do anything to it, making it not real useful for computing in general, let alone hacking.

To get around ASLR all you have to do is consult ... the built in lookup table which is at ... A FIXED ADDRESS as it has to be able to be found for everything to work.

No, the lookup table isn't at a fixed address. That is, in fact, the whole bloody point. The lookup table (technically the PLT, at least for ELF binaries) is at a fixed offset relative to the main binary, so if you can figure out where the main program is in memory you can find it very easily, but the point of ASLR is that it's non-trivial for the attacker to find the binary, and so they can't find the lookup table.

Now, admittedly, programs have to actually be compiled to use ASLR for this to work (older programs will randomise the locations of libraries but not of the program itself), and there are still plenty of Linux distributions where it's *still* turned off in the default compiler (Debian and Ubuntu, certainly, and possibly others), but when it's implemented properly the attacker can't easily find the lookup table.

Also, I think you're possibly underestimating the difficulty of using the lookup table once you've found it. It's not like the attacker can just call GetProcAddress() or dlsym() in the target program (because otherwise they'd have a far easier way of gaining control), and it's not like they (usually) have a way of reading arbitrary bits of the program address space. It's not much use knowing where the lookup table is if you can't actually read it.

Re:the only thing Microsoft and others can do is..

[hairyfeet]

First of all a public service announcement: To everyone that writes "M$" in 2013...This...Is...YOU! and this is what everyone sees and instantly dismisses when you write that lame ass M$ in 2013. You could write the most brilliant post in the history of Slashdot but a good 80%+ will NEVER read it because they see M$ and think "douchebag" and move on. So don't waste your time unless you want people posting your group photo as the very next post.

Second of all lets get something VERY clear for those that don't seem to understand how these things work, okay? ALL OPERATING SYSTEMS that would be what we consider "modern" are some of the most complex pieces of software EVER written, we are talking millions of LOC in the kernel alone and thousands of little sub-programs that ALL have to work in concert to give the user the illusion that its all one program that "just works". Is Linux even close to immune? Not only is that a big NO but to even suggest it is is a symptom of what is known as "magical thinking" such as "If you buy (product X) then you will magically be safe!". We in IT have seen magical thinking used to sell everything from OSes to firewalls to routers and reality will blow holes in that lie every single time.

So if Linux is vulnerable why don't we see Linux attacks in the news? We do only they are called "Android attacks" and in fact its predicted that later in the year Android will reach the one million infected mark which considering that Android isn't even a decade old is pretty impressive.

Look its actually VERY simple, and evidence has bore this out time and time again. Criminals ARE LAZY and want to do the least amount of work for the biggest bang so they want to go after the biggest targets to yield the most infections they possibly can. I mean writing a OS/2 virus today would probably be the most trivial thing in the world yet you don't see anybody doing it, why? Because the fact is even though eComstation still sells OS/2 there are too few using it to make it a juicy target. But the malware writers WILL go where the targets are, used to be it was always Windows, then Vista bombs and everyone in the press starts talking about how Mac adoption is climbing, what happens? Mac Guardian and Mac Defender. Android phones and tablets explode in usage, what happens? Thousands of Android malware released weekly.

So anybody who thinks their OS is gonna magically protect them from malware because "(product X) doesn't get bugs!" is merely deluding themselves with magical thinking. There are even articles that helpfully helpfully explain this and point out how switching platforms just for the sake of magical thinking (in the article OSX for Linux but you can insert any from and to in there and it still fits) just doesn't work. Be it Linux, Mac, or Windows you can find plenty of bugs, I could spend 5 minutes and cover this page in reports of bugs for all 3, I already listed the 2 biggest Mac bugs of recent memory, TFA is a Windows bug, and just off the top of my head there was the KDELook theme bug and the infected Quake 3 that was served up by most repos for a year and a half on Linux. NO OS is safe, NO OS is immune, and if you are gonna claim security by obscurity is actual security you might as well run Win95 or BeOS because hey, there aren't any bugs circulating targeting those OSes either.

Re:the only thing Microsoft and others can do is..

[hairyfeet]

To quote Mel Brooks "Bullshit bullshit aaaaannnnd bullshit". if you want a shortened way? Use MSFT, it even lets you be snarky as its the stock ticker and you can claim its because "they only care about the stock price instead of putting out a good product" so you can be just as douchey and stupid as you want and people will still understand WTF you are posting.

But the "M$" bullshit is not only from fucking DOS which hasn't even been a product for 20 damned years but it was fucking retarded even THEN. Its just as fucking retarded as writing "Lunix" and deserves to get fucking smacked down for being stupid. And read the guys post dude, i'm assuming you didn't or you wouldn't be trying to apologize for him because it was a classic FOSSie douchebag rant, no different than the douchebag Mac users that insinuate if you aren't using Macs you're either too stupid or too poor, or the Win 8 douchebags that insinuate anybody that doesn't want a cellphone for an OS is too stupid to work it.

But this is SUPPOSED to be a site FOR geeks and BY geeks and I'm pretty sure that in an article on Windows if somebody types MS everyone isn't gonna go "Why is he talking about Mississippi having a vulnerability?" but of course it was NOT about having a short way to type Microsoft, it was another coward that couldn't wait to wave his little dick and brag about his magical OS that he doesn't even understand. Magical thinking has no place on a site about tech and frankly that kind of horseshit needs to be nipped in the bud whenever possible.