I mean, this is clever and all, but what am I missing? Isn't this just an IE bug? That you can access cookie files as IFRAME targets? Is there some part of the IE architecture that depends on that functionality, or is Microsoft just going to patch that?
Because pretty much all the browsers, on a better-than-quarterly basis, fall victim to attacks that allow arbitrary web pages to upload code into their processes and run it.
Just not sure this needed the "attack class" name.
Agreed. This is a one-off bug and certainly not something warranting its own term, since we're unlikely to ever see something quite like this again. Definitely a clever attack, though.
> Because pretty much all the browsers, on a better-than-quarterly basis, fall victim to attacks that allow arbitrary web pages to upload code into their processes and run it.
> Just not sure this needed the "attack class" name.
You are being too generous.
By default, all web browsers ALLOW execution of ALL code encountered
since all browsers ship with javascript enabled. Similarly, allowing
hidden and/or transparent elements ENABLES clickjacking by default.
In other words, the fundamental design is flawed, and it remains flawed
because of vested interests. Most argue the risks are worth the rewards,
and anyone who disagrees is promptly told that their tin foil hat is on
so tight that it's cutting off their circulation.
Seriously, do you really want to be the person who advocates removing all javascript and hidden/transparent elements?
We both know what would happen to said person.
EDIT: Getting down-voted for just stating the underlying problem on HN doesn't bode well for HN as a community.
> By default, all web browsers ALLOW execution of ALL code encountered since all browsers ship with javascript enabled. Similarly, allowing hidden and/or transparent elements ENABLES clickjacking by default.
Woah, woah, woah. There's such a huge difference between "they can run Javascript and maybe consume some CPU time" and "they can run native code and completely own my machine" that I don't even know where to begin. If you could do "eip = shellcode.ptr;" in Javascript, maybe this would be a logical argument, but really there's just a massive, massive difference here.
Please name any javascipt "sandbox" that has a perfect security track record.
That's the real point.
Sure, javascript can be useful and even beneficial, but the key is making a decision on whether the risks are worth the rewards. The same is true for ANY code you decide to run.
You're trolling, whether you mean to be or not. You can't name an anything with a perfect security track record. And this time, you're trolling in service of a stupid argument: that we can have either an insecure Internet-as-we-know-it, or no Internet-as-we-know-it at all. Well, no shit.
tptacek, you built a false dichotomy, and then you pretended I said it
so you could have a straw man to knock down. We can laugh about it over
a beer the next time you visit the valley.
When a friend tells me I'm trolling, even unintentionally trolling, and
even if it was expressed through a fallacious argument, it's time to
stop and rethink. Something is definitely wrong.
I seriously thought about just dropping this, not responding and letting
this thread die of natural causes. But I would be setting a bad example
by doing nothing, or taking it privately to email. $DIETY knows HN needs
more good examples of responding properly under pressure on contentious
issues, and with some luck and effort, I'll hopefully write one.
It seems tptacek meant "Web-as-we-know-it" but I really do get his
point; people are now accustomed to executing code from any source via
web browsers and javascript. It undeniably is the status quo. Me and my
outdated, curmudgeonly views have never agreed with the idea of
executing code from any source. I am undoubtedly a minority.
The problem is, why is it such a terrible sin to question if the risks
are worth the rewards, voice flaws in the design, and try to look for
better alternatives? --In other words, why is everyone forced to accept
the "as-we-know-it" part without question?
Wanting to improve the as-we-know-it is vastly different from wanting to
abandon everything. I'm always in favor of trying to improve the status
quo. I know for certain the same is true for tptacek and although I
don't know him, I'd bet the same is true for daeken.
It's safe to say all of us "violently agree" that there is no such thing
as perfectly secure code, and it makes no difference if the code is only
handling data or if it is attempting to execute other code in a
sandboxed virtual machine such as javascript.
Javascript has unimaginably huge investment and momentum behind it. The
overwhelmingly vast majority of people have a vested interest in
javascript, either as a company or developer, but also as just a user.
It won't be abandoned overnight. Similar is true for other problematic
aspects of the web including CSS and frames. In short, there is a damn
good reason why unpopular views are very unpopular --Billions (if not
more) of investment would be lost if these things were abandoned.
With all of that said, browser exploits are painfully common. If you
reread tptacek original comment:
> Because pretty much all the browsers, on a better-than-quarterly
basis, fall victim to attacks that allow arbitrary web pages to upload
code into their processes and run it. Just not sure this needed the
"attack class" name.
you can see browser exploits happens regularly enough to cause
significant damages, but even mentioning the underlying problems results
in, "You're trolling... Internet-as-we-know-it... no shit." and
similar. It doesn't need to be that way, but around here, it almost
always happens. The very idea of finding something better than the
status quo of javascript and endless browser exploits is far too
intimidating and unreasonable for most people. If you make your living
from javascript or you're just a casual user, it is terrifying to think
what would happen if it suddenly stopped working at 3pm tomorrow. When
an idea contrary to the status quo is voiced, many people succumb to the
irrational thinking of a sudden change and the associated irrational
fears. But...
The reasonable man adapts himself to the world. The unreasonable
man persists in trying to adapt the world to himself. Therefore,
all progress depends on the unreasonable man.
-- George Bernard Shaw
Being unreasonable is never a license to troll; the efforts and
investments of others have value and should be respected, but making
improvements should remain open for discussion. Maybe I am
unreasonable, but I do have good reason for it; our status quo is
repeatedly broken. Taking offense to reality will simply prevent you
from improving the situation, and worse, shouting-down others for
venturing where you fear to tread may prevent them from improving the
status quo for you.
If you can't talk about a problem, then you have a bigger problem.
The problem is that you said they would execute 'ALL' code, which is not only terribly misleading but technically incorrect. It's a false statement that has no place in a proper discussion.
Also I think it's unreasonable to expect a browser without javascript to be significantly safer. Look at all the code-execution exploits in image decoders.
Insistently trying to relitigate all of Javascript on HN in response to an IE news story is trolling. The first such comment was just annoying, but when you pushed the point with someone who clearly wasn't interested in your orthogonal argument, it crossed the line.
You can make the very same argument for images -- remember the libjpeg and libtiff vulns a couple years ago? You can make the same argument for CSS -- remember the type confusion in Webkit a couple months ago? I'm sorry, but you are completely off base here. That is why you're being downvoted.
Just about all nontrivial code that accepts input, whether or not that input is "code," has a tainted security track record. There is no point because you're not addressing the issue. Running code in the browser certainly creates its own class of security issues no matter how safe the execution environment is, but the fact that browsers do very complex things with a huge variety of inputs means that there are tons of vectors for manipulation. This is much closer to what your trying to talk about, but is pretty meaningless to discuss in the broad sense.
Novel approach, but I'm curious how many networks let 445 smb over tcp out? Enterprise networks sure shouldn't, my office doesn't, my house doesn't though admittedly most people won't be configured this way. But don't big carriers like comcast also filter common microsoft ports like this and 139 because of worm and exploit activity?
Yeah, only the username. Still, that seems like a pretty hard thing to blind guess at in most attack scenarios if you can't get it through the cifs connect. My reading is that you couldn't brute force it, you'd have one chance to set up the iframe with the cookie file in it which needs the username, or at least just one chance per clickjacked drag action that the user executes for you.
If it's a targeted attack I suppose you have a better shot, are most home windows user names set to the user's full name like "John Doe"?
> My reading is that you couldn't brute force it, you'd have one chance to set up the iframe with the cookie file in it which needs the username, or at least just one chance per clickjacked drag action that the user executes for you.
But if you made some sort of Javascript "game" (which used drag and drop) and required the users to register their name first, then you should have a fairly high chance of guessing their username without CIFS.
That's my thinking; it seems like it'd be most relevant in a targeted attack. Presumably there aren't so many patterns of usernames that you'd run out of chances to get one.
It's clever! I don't want to take anything away from it, except that I think it's been written up somewhat breathlessly.
Grossman probably has a good point that most applications aren't even superficially protected against clickjacking, and so this isn't going to be a common attack any time soon.
I seem to recall at least one XP box that I've set up that came with a preconfigured account; if e.g. Dell does/did this, there may be a lot of such accounts out there...
Can someone describe the white hat credo with respect to 0 day exploits?
Did he give Microsoft a head's up about these and a chance to respond before going public? Or does he just give a conference talk and post it to his blog, potentially providing the information allowing thousands of browsers to get compromised (assuming they weren't already) before privately letting Microsoft get a chance to patch it?
If this attack involves "simply sniffing TCP 445" why not just MITM the whole session?
The state of security is becoming an over-hyped sideshow of late where the most trivial attacks, which would work maybe 1% of the time in the wild, are getting mass exposure.
I have a 0day in RHEL 5, you simply need to log onto the machine as root and run this script...
"If this attack involves "simply sniffing TCP 445" why not just MITM the whole session?"
Because it doesn't. The attack involves using a bug in IE (an iframe will render cookie data from the local computer) with clickjacking to steal cookie information. Sniffing on port 445 is only mentioned in the context of figuring out the username of your target (by causing the target to connect to your SMB server, running on port 445).
I'd suggest you go back and re-read the whole page before making sweeping generalizations.
Because pretty much all the browsers, on a better-than-quarterly basis, fall victim to attacks that allow arbitrary web pages to upload code into their processes and run it.
Just not sure this needed the "attack class" name.