Possible vulnerability?

[impert]

Hi all,
Not sure if this post should be here or in the cafe, but does anyone have a comment on this article (http://http://arstechnica.com/security/news/2010/05/multicore-cpus-move-attack-from-theoretical-to-practical.ars)?

The suggestion that Windows might be insecure will come as a huge shock, I'm sure, but what interested me was the following:

Matousec initially believed the technique they were using to exploit the security software was newly discovered. After publication, however, they became aware that the basic technique was documented as a way of attacking Unix way back in 1996
This obviously hasn't been a problem so far, but is it possible that this could affect Unix-like systems now that multi-core processors are common? Or did it get stamped on back in 1996?

[Dayofswords]

The suggestion that Windows might be insecure will come as a huge shock, I'm sure, but what interested me was the following:
you mean linux?

[Rasa1111]

The suggestion that Windows might be insecure will come as a huge shock

:lol: definitely not.
typo?

[OpSecShellshock]

Nothing to worry about. The main point of the research was getting around kernel hooks that are used by AV software to prevent illegitimate processes from accessing certain memory regions. If you have neither AV software nor illegitimate processes, there's no issue. There are other mitigating factors even on Windows. Local access is required prior to attempting to exploit the race condition (though most of the time I don't think that's much of a mitigation, all things considered--at least on Windows). The other thing is that AV engines are set up this way by design so that false positives don't lead to serious issues with legitimate processes--which in addition to breaking those processes would lead to troubleshooting suggestions that involve disabling the AV software, which in turn would be exploited by social engineers to drop even more malware.

And the plain fact is, most people's Windows machines are easy enough to thoroughly own without having to pull this trick off at all, so it's a lot of extra effort with little extra benefit. It seems to me that any malware that already has the capability of disabling or fooling the AV software (which already exists) or that loads as a service/loads prior to the Windows API (those are already out there too) doesn't need to do this. It's novel, but not worth the trouble for a malware developer.

[impert]

typo?

you mean linux?
Well, actually, no, I meant a little gentle irony. Next time I'll use a smiley to hammer it home. :)

Nothing to worry about. The main point of the research was getting around kernel hooks that are used by AV software to prevent illegitimate processes from accessing certain memory regions. If you have neither AV software nor illegitimate processes, there's no issue
Thank you, but I'm not exactly quaking in my boots, you know. I don't use Windows, and like most linux users I suppose, I don't use AV. I also have no use for the scaremongering practised by the so-called "independent" experts of the AV industry. My attention was caught by this phrase:

the basic technique was documented as a way of attacking Unix way back in 1996
My guess is that this was done in an IT faculty and probably any weakness was patched last century. But kernel hooks (http://en.wikipedia.org/wiki/Hooking) exist in linux, and maybe the situation has changed since 1996 with dual- and multi- core chips. Does anyone know?
I don't plan to lose any sleep over it.