Comment Re:Key exploit mitigation in Internet Explorer (Score 1) 49
No more so than before.
The mitigations that this research affects weren't introduced until 2014 anyway.
No more so than before.
The mitigations that this research affects weren't introduced until 2014 anyway.
Actually the article confuses two unrelated security issues. Microsoft said they weren't planning to do anything about the counter-mitigation technique, which may allow an attacker to bypass ASLR in IE on 32-bit Windows. The cookie-stealing vulnerability will presumably be patched in due course.
It isn't actually a bug, but a limitation of the mitigation technique. There's isn't any simple way to fix it.
It isn't a vulnerability, it's a counter-mitigation technique. So 32-bit Windows isn't as effective at mitigating unknown vulnerabilities as 64-bit Windows; nothing new there.
No, those are two unrelated issues. There's an exploit against IE that allows an attacker to steal localhost cookies. This affects both 32-bit and 64-bit Windows, and will presumably be patched in due course. Then there's a new counter-mitigation technique, which only affects IE on 32-bit Windows, and which Microsoft apparently aren't planning to fix. That one might allow an attacker, in possession of an exploit that potentially allows code execution, to run code when the mitigation would otherwise have made it impossible - but it is only a counter-mitigation technique, not a vulnerability in and of itself.
I'm not sure IE7 even includes the mitigations that this technique defeats. If you run old software, you're more exposed to bugs - nothing new about that.
Those are two unrelated exploits. The advisory on the first exploit doesn't mention ASLR, the white paper on the counter-mitigation technique doesn't mention cookies.
These are two unrelated issues - a vulnerability which affects machines that have web servers running on localhost, and a counter-mitigation technique that affects IE running on 32-bit Windows. Those machines are probably affected by both issues, but the first will probably be patched in due course and the second isn't an exploit as such but a method of making other exploits more effective.
There are a number of mitigation techniques that either don't exist or aren't as effective on 32-bit Windows. I don't think this one is necessarily a game-changer.
The vulnerability described in the first link appears to be completely unrelated to the vulnerability discussed in the second link. One is a straightforward information exposure vulnerability, the other is a counter-mitigation technique that bypasses ASLR.
I've checked the detailed reports, too; neither "ASLR" nor "mitigation" appear in the first report, and neither "cookies" nor "localhost" appear in the second report. They're from different people and different organizations. Apart from the fact that they both affect IE, they've got nothing to do with one another.
"If I develop a product such a film that people are interested in seeing, then I have a right to charge a fee to let them see it."
(If I sell someone a hammer, I don't get to charge them on a per-nail basis for the rest of eternity!)
"That's how copyright benefits society"
"A machine that can make apples can be copyrighted, apples cannot."
"If someone needs a hole dug and you dig it for them,"
"If someone has a product that you want"
The problem is that you're trying to pretend that an abstract concept - a series of zeros and ones - must be treated as though it had a real, concrete existence, must be someone's "property". And that's simply not true. It is *convenient* for us to treat an abstract work of art as if it were concrete, and to assign a limited form of ownership to it on that basis - but it is not *mandatory*.
Nonsense. There's no ethical justification for copyright other than its benefit to society. You're not automatically entitled to government protection simply because without it your business model doesn't work.
If we one day develop a machine that can duplicate, say, apples, we're not going to demand that everybody pay the person who grew the original apple before they eat one of the duplicates. So why should we pay the person who recorded the song before we listen to a copy of it?
(It's more complicated than that, of course; artists have invested time and money into their work precisely because we promised them they would be paid for it, so it wouldn't be ethical to simply abolish copyright outright. We'd have to have some sort of grandfather clause and/or compensation. And its not likely to happen anyway, because the people that benefit most from corporate welfare schemes such as copyright have too much influence. But it's important to realize where copyright came from if we're going to resist even more encroachments on our personal rights.)
The ones who want to make money won't. So what?
Copyright exists for the benefit of society, not because artists have "a right to be paid". (They have a right to "demand to be paid", since that's just free speech, but society is entitled to say "sod off" in reply.)
We're rapidly approaching the point where "sod off" is the most sensible reply - copyright is increasingly working against society rather than for it. This incident is just another brick in the wall.
Not so. My main Windows server suffered serious problems when first deployed - not so long ago - which we eventually tracked down to the use of TRIM on the iSCSI drives.
Granted the issues were mainly DoS rather than data loss, it was still a serious problem.
Mystics always hope that science will some day overtake them. -- Booth Tarkington