Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

'Rosetta Flash' Attack Leverages JSONP Callbacks To Steal Credentials

Soulskill posted about three weeks ago | from the clever-exploits dept.

Security 68

New submitter newfurniturey writes: A new Flash and JSONP attack combination has been revealed to the public today. It has been dubbed the "Rosetta Flash" attack. JSONP callback functions normally return a JSON blob wrapped in a user-specified callback function, which the browser will then execute as JavaScript. Nothing out of the ordinary here. However, the new attack has leveraged a method of crafting a Flash file to contain a restricted character set that's usable within JSONP callbacks (i.e. in a URL). By combining the two, the attack demonstrates it's possible to use a JSONP URL with the contents of the crafted Flash file as the callback function. When set as the data of a standard HTML object tag, the SWF file executes on the targeted site, bypassing all Same-Origin policies in place. Services such as Google, YouTube, Twitter, Tumblr and eBay were found vulnerable to this attack. Several of these services fixed the vulnerability with a patch prior to the public release, and Tumblr patched within hours of the release.

cancel ×

68 comments

Well which ones haven't patched yet, eh? (0)

Anonymous Coward | about three weeks ago | (#47412247)

"Several of these services fixed the vulnerability with a patch prior to the public release, and Tumblr patched within hours of the release." Who hasn't?

haven't we learned from the last 25 exploits? (4, Insightful)

Anonymous Coward | about three weeks ago | (#47412257)

Keep javascript and flash disabled.

That is all. Letting random web sites run scripts on your computer has never been a good idea.

Enable it for your bank if you want. Otherwise, keep it disabled, and you'll be a lot happier (it keeps crapsites from foisting their crap on you), more secure from various exploits, and will maintain more of your privacy from all the data harvesters that depend on javascript.

Re:haven't we learned from the last 25 exploits? (0, Troll)

Anonymous Coward | about three weeks ago | (#47412291)

Some of us would like the internet to be ... well ... useful.

Re:haven't we learned from the last 25 exploits? (1, Insightful)

Anonymous Coward | about three weeks ago | (#47412423)

Some of us would like the internet to be ... well ... useful.

It was plenty useful before Javascript was even invented. With a few rare exceptions, Javascript has not improved the web. It's made back buttons break, foisted 275 KB pages to do what 4K of HTML would do just fine, made videos break where a direct link would work, given us flashing crap, shit popping up, security vulnerabilities, disabled cut and paste which works again as soon as you disable javascript, and so forth and so on.

If you want the web to be useful, you should be pushing for only the most minimal use of Javascript.

Oh... unless you're one of the marketing types that hijacked the web that engineers built for you, who now want to data-mine everybody and serve "targeted ads" and build online profiles of what everybody does. In that case, your opinion makes perfect sense.

Re: haven't we learned from the last 25 exploits? (0)

Anonymous Coward | about three weeks ago | (#47413003)

Looks like July 8th's Word-of-the-day offering is, "foisted...". " Foisted "

foist
foist/Submit
verb
past tense: foisted; past participle: foisted
impose an unwelcome or unnecessary person or thing on.
"don't let anyone foist inferior goods on you"
synonyms: impose on, force on, thrust on, offload on, unload on, dump on, palm off on; More
introduce someone or something surreptitiously or unwarrantably into.
"he attempted to foist a new delegate into the conference"

"Foisted."

Re: haven't we learned from the last 25 exploits? (0)

Anonymous Coward | about three weeks ago | (#47413839)

Strawman much? :)

Re: haven't we learned from the last 25 exploits? (1)

Type44Q (1233630) | about three weeks ago | (#47413857)

I'm going to go out on a limb here and guess that you're one of the aforementioned douchebag marketing types (paraphrasing mine)...

Re: haven't we learned from the last 25 exploits? (0)

Anonymous Coward | about three weeks ago | (#47413009)

Someone doesn't know shit about the web here...

Re: haven't we learned from the last 25 exploits? (1, Insightful)

0123456 (636235) | about three weeks ago | (#47413185)

Someone doesn't know shit about the web here...

The introduction of Javascript was when the Internet began to turn to crap. Many of us pointed out at the time just what a security nightmare it would be.

Re: haven't we learned from the last 25 exploits? (0)

Anonymous Coward | about three weeks ago | (#47414233)

I know, right?

"News flash: security hole found in two biggest security risks on the Web. Film at 11."

Re:haven't we learned from the last 25 exploits? (1)

marcello_dl (667940) | about three weeks ago | (#47413517)

This. Badly used Javascript, like html frame elements, also break the stateful nature of webpages, and this means breaking the concept of hypertext itself.
If sites were designed with optional javascript and ajax, they would work as well and referring to web content would be much easier. The semantic web was already there.

Of course big sites don't offer you the content as easily. Get logged in, get profiled, don't get out.

Re:haven't we learned from the last 25 exploits? (1)

Arker (91948) | about three weeks ago | (#47414205)

"If you want the web to be useful, you should be pushing for only the most minimal use of Javascript."

When this crap first started getting pushed, a lot of us saw the potential problems coming and objected. We were assured it was only to be used to 'spice up' webpages, not to replace them.

Such assurances are obviously shit. If it's allowed to use it, then the lowest common denominator of self-proclaimed 'designers' can, will, and must overuse it. This overuse expands steadily and predictably until and unless there is effective pushback. Today we have reached the point where the typical corporate 'website' (and I use scare quotes because these things are NOT websites, at all) consists of hundreds of executable files, fetched from dozens of different servers, all of which the browser is expected to suck in and execute without so much as giving you a warning.

And contrary to the hilarious suggestion I see at the top of many many webpages today ("Enable Javascript for a better user experience") this does not bring with it any substantial improvements for the user. Quite the contrary, it results in a worse immediate experience (no, I didnt want a dozen popups, autoplaying video presentations, and a huge advertisement that floats over the text so I cannot see it!) and also in the longer term (like a week later when you discover that some random ad server sent your browser a rootkit and it happily executed it, oops!.)

But the point is history has proven this is a bad code drives out good situation. If it's allowed, it will take over, just like a weed.

Turn off javascript. See the web as it really is. And support the web that still exists, before it's too late.

Re:haven't we learned from the last 25 exploits? (1)

tlhIngan (30335) | about three weeks ago | (#47415631)

You know, there used to be a time where there were excellent webmasters that could do both HTML and Javascript great. Where you went to a website and without JS, it degraded gracefully.

Apple's website was like that, maybe about 8 years ago or so. Other than being a bit ugly in parts, it worked extremely well without JavaScript. (turning it on made it prettier and things worked a lot better, though). In fact, I only noticed it when I noticed it rendered differently on two different Firefoxes - on one, I had NoScript set to allow apple.com, on the other, I didn't.

It was a thing of beauty.

Of course, these days, it's gone to requiring javascript, though you may see old remnants of the time when it worked just fine without.

Re:haven't we learned from the last 25 exploits? (5, Insightful)

Arker (91948) | about three weeks ago | (#47412367)

Excellent advice.

Expect to be flamed into oblivion by all the 'web devs' that cant be bothered to learn how HTML works and rely on this crap instead, though.

The web - the real web, the HTML web, appears to be shrinking at the moment. New content is often hidden behind some kind of opaque app crap for no apparent reason and with no actual webpage for fallback (thanks google!) and old content occasionally gets removed as well. Each time this happens, it makes it even harder and less likely to revive the healthy web we once built with such love and care.

And naturally the people that are making a profit on this crap will just keep right on cranking it out as long as that is true.

The real victims here are future generations, who should inherit that world-wide web, but are set to inherit something entirely different - and inferior in every way (when judged from the users perspective - from the perspective of big Advertising of course the story will be different, but we built this web for humans, not for marketing.)

Re:haven't we learned from the last 25 exploits? (0)

Anonymous Coward | about three weeks ago | (#47412727)

Each time this happens, it makes it even harder and less likely to revive the healthy web we once built with such love and care.

With such care that you used microsoft and netscape -specific extensions that you didnt wrap for portability and forced so many users into maintaining IE6 (thankfully netscape didnt get enough penetration in the corporate market for its foibles to cause the problems IE6's did).

Re: haven't we learned from the last 25 exploits? (0)

Anonymous Coward | about three weeks ago | (#47413013)

But we built this CITY on Rock and Roll. I think we can agree there at least. Amirite?

Re: haven't we learned from the last 25 exploits? (1)

dgatwood (11270) | about three weeks ago | (#47415081)

Amirite... a bluish purple crystal that turns pink in the presence of sarcasm. First described in a Kenny Loggins song:

Amirite. Donut buddy worry 'bout me.

Re:haven't we learned from the last 25 exploits? (0)

Anonymous Coward | about three weeks ago | (#47413213)

Said by someone who sounds like they understand very little about web development. Or perhaps by someone who once did web development but hasn't done any meaningful commercial work in the past 10 years. Or maybe just nostalgic for the good ol' days, where picking up frontend dev took a month instead of years spent learning the diverse set of technologies.

Why is it that every single time there is a story on slashdot related to an exploit, people come out of the woodworks with "use NoScript, disable javascript, danger danger danger!"? There is no "html only" anymore - the web stack is now by definition html, css and javascript. The days of creating fully functional sites with html only and sprinkling a little javascript to enhance the experience is over - javascript is now an integral, *core component* of frontend development.

What I find to be curious: amongst every senior colleague I have worked with in the industry - those of us who understand the stack very well and are aware of potential attack vectors - not one of these people uses NoScript or disables javascript. The very idea of disabling a core component (or manually whitelisting every single website) is not even something that crosses the mind.

Javascript is not going anywhere. The day it becomes deprecated, it will only be due to having been replaced by an improved substitute or because the web as we know it today will have evolved beyond simple scripting. If anyone want to continue to build html-only web pages... good luck with that - you might get away with that for your little personal homepage, but let's see you compete in any commercial market with a site 15 years out of date.

Re:haven't we learned from the last 25 exploits? (1)

dgatwood (11270) | about three weeks ago | (#47415511)

Nobody minds CSS much, so long as you don't allow embedding JavaScript URLs in it (which, unfortunately, browsers do).

The problem is not JavaScript, per se, so much as the fact that it is massively overused, breaking links, breaking back buttons, etc. Your documentation viewing experience does not demand a web app. It might benefit from some intelligent links that do special stuff if JS is enabled, but if you cannot make your site work with JS disabled, you're abusing JavaScript.

There are exceptions, mind you—sites where the core functionality is unavoidably tied to JavaScript (e.g. Google Docs). And I can even accept JavaScript for other content on that site that isn't tied to JavaScript, because after all, you can't avoid JS on such a site. The farther you get away from that scenario, the more annoying it is. And even on those sites, I expect the developers to have taken the time to ensure a good user experience—effort that, sadly, most web developers don't put in.

And yes, I've developed some pretty complex sites that use lots of JS code, but I've always made sure that at least the basic stuff doesn't require it, to the maximum extent practical.

Re:haven't we learned from the last 25 exploits? (1)

holostarr (2709675) | about three weeks ago | (#47416153)

How does one embed "JavaScript URLs" in CSS? Also you seem to have no idea about where the web is headed or have heard about responsive design and SPA. Long gone are the days where JavaScript is a small piece of a site's functionality, we are now moving towards a more dynamic and responsive web where you don't have fetch the entire contents of a page just so you can see which of your form inputs the server rejected.

Re:haven't we learned from the last 25 exploits? (1)

dgatwood (11270) | about three weeks ago | (#47420303)

How does one embed "JavaScript URLs" in CSS?

Very easily [stackoverflow.com] , and because so few people know it is possible, it's a rather nasty vector for cross-site scripting attacks.

Also you seem to have no idea about where the web is headed or have heard about responsive design and SPA.

I'm well aware of responsive design. I think it's an abomination, because all it does is make it take two page loads to view your site instead of one, by ensuring that I have to first load your broken mobile site, then click the "full version" link. Every single freaking time I end up on a "responsive" mobile version of a website, I find myself locked out of features that I regularly use, and end up having to switch to the full desktop version of the site.

If you need much more than a couple lines of JavaScript and a custom stylesheet to support mobile devices, it invariably means that your site is badly designed (too complex) to begin with, and as soon as you release the mobile version of your site, you're almost certainly going to make me hate your guts and curse your name.

And SPA is even worse. If your site loads significantly faster as a web app, there's something wrong with your site. 99% of the time, most of the resources should be shared across pages, and only the text of the page should be changing. There's usually not an appreciable difference between the "load the full page" case and the "load the body of the page" case from a performance perspective unless something is very, very wrong. There are exceptions, such as storefronts that use precisely the same page layout for every page, but these are exceptions, not the rule, and even then, the extra savings in initial page load time just result in a customer sitting there wondering why there's no data on the page, and thinking your site is broken. The real problem is that every web engineer thinks their site is the exception to this rule, but most of those engineers are wrong.

More to the point, if I'm accessing your site often enough to care about performance, I'm going to download your native app instead of using your mobile site, because it will always be much, much more functional, with fewer limitations, more features, and better performance. If I'm going to your website, it's either because I don't care about performance or, more commonly, it is because your native app is missing features that are only on the full version of your site. Giving me a mobile version won't help with the second case, and the first case is largely unimportant for everybody but the site designers who are trying desperately to shave off a few bytes from their data bill.

BTW, it's possible to do a manifested web app (giving you all the advantages of heavy-duty caching of shared content) without using JavaScript for all your navigation. You just specify the base path of the content directory as an external URL (I forget the details) in the web app manifest. This approach is much, much more user-friendly than a SPA in my experience.

Re:haven't we learned from the last 25 exploits? (1)

dveditz (11090) | about three weeks ago | (#47416337)

No modern browser allows javascript URLs in CSS. None. Completely non-standard and dangerous. Old IE and Netscape? Yeah, they were dumb back then, but that was over a decade ago.

Re:haven't we learned from the last 25 exploits? (0)

Anonymous Coward | about three weeks ago | (#47413361)

Yeah, i miss Geocities too bro.

Re:haven't we learned from the last 25 exploits? (1)

f00zy (783212) | about three weeks ago | (#47417011)

While I understand some the sentiment expressed here, a lot of this nonsense. An HTML-only web is great for relatively static content, but not so great for anything much beyond that. Is it so difficult to grok why you might want content to change on the client? I don't think so. Is JavaScript used for nefarious purposes? Yes, all the time. Is there bad UX because of JavaScript? No doubt. It is, however, a useful tool in the hands of skilled designers and developers. I'm usually the one telling people to get off the lawn, but in this case, meh whatever.

Re:haven't we learned from the last 25 exploits? (0)

Anonymous Coward | about three weeks ago | (#47419061)

Sorry, while my old web-site was very small by today's standards the static HTML pages were created from a database that a program I wrote would read thru and then build up the site as needed.

At the time I would just run the program at the end of the day, but that was a 7MHz Amiga, today if I were to do the same on my 3.4Ghz I7 I could rebuild any changed pages in least than 5 seconds and keep doing that 24 hours a day.

With the garbage that needs to be downloaded to support JS pages I am willing to bet that a static HTML version will out perform the JS version as long as the server creates well tune HTML content.

Why are the browsers doing this grunt work? Good server coding should be able to create small and fast HTML on the fly.

Re:haven't we learned from the last 25 exploits? (0)

Arker (91948) | about three weeks ago | (#47420705)

"An HTML-only web is great for relatively static content, but not so great for anything much beyond that. "

This sounds like nonsense to me, but I will give you the benefit of the doubt and ask you for *concrete* examples of what you are talking about. I have yet to be cited a single good example here - very often what is being done would work just fine in HTML, with less overhead, but the 'designers' just do not understand HTML, or have any desire to learn it, so they do things this way instead.

Certainly javascript can produce a slicker appearance and make certain things a bit smoother - but to do so it sacrifices device-independence and browser agnosticism - critical advantages that underlie the success of the web and whose loss can only undermine it.

Now if you build a proper web page, and then *enhance* it with javascript sanely, preserving graceful fallbacks, that would be fine. You can have your slick interface without sacrificing the web. And I can choose to avoid your slick interface so as not to sacrifice my security.

The 'designers' that cant be bothered to do that, and the suits that keep them employed, are the reason we cant have nice things. In this case, javascript.

"Is it so difficult to grok why you might want content to change on the client?"

Not difficult to understand why it was desired.

The point is it's harmful and been proven harmful, and far too harmful for the small advantages it brings to outweigh that.

Re: haven't we learned from the last 25 exploits? (1)

f00zy (783212) | about three weeks ago | (#47422039)

"I have yet to be cited a single good example here - very often what is being done would work just fine in HTML, with less overhead, but the 'designers' just do not understand HTML, or have any desire to learn it, so they do things this way instead." Over the years, I've done a lot of work with games and simulations for training. Often times, these training simulations must coexist with existing talent management infrastructure. This means a JavaScript API for communicating performance data to the host platform. I will concede that this could be handled in other ways, but they would most certainly be clunkier, slower, and more prone to error. But what about the simulations themselves? In one example, we built an electrostatic puzzle game in which students had to charge robot parts using charge sharing, conduction, induction, and the triboelectric effect in order to obtain target values. Each manipulation (e.g., sharing charge by physically connecting two charged objects with a wire) produced a change in state that was manifest in the underlying data model and on screen appearance. We could not have produced this educational game with just HTML.

Re: haven't we learned from the last 25 exploits? (1)

Arker (91948) | about three weeks ago | (#47426261)

"Over the years, I've done a lot of work with games and simulations for training."

OK. That really doesnt have anything to do with the web, however. Sure, the web can be used to deliver the project - that doesnt mean it has to actually run inside the browser. There is a HUGE difference.

"We could not have produced this educational game with just HTML."

I get where you are coming from but I still think it's far off the mark. The web is not a game platform, that is not it's purpose, so 'we could not do games this way' is not a very telling criticism.

You can use better tools to make the games, and use the web merely to deliver the game. Where is the problem with that?

It would NOT be slower, clunkier, or more prone to error. It could be done using exactly the same technologies in virtually exactly the same way - the only difference would be very slightly less easy to get it started, and in return for that, your browser is no longer a malware vector.

Or, it could be done using technologies better suited for the purpose, in which case I would expect the results to be less clunky, faster, and more stable - but the development process would be more expensive as well.

I get why you would want to use RAD to lower costs, just not why you see the tiny convenience of running in the browser automatically as worth the cost of turning the web into a malware distribution network.

Re:haven't we learned from the last 25 exploits? (1)

mfh (56) | about three weeks ago | (#47412501)

Hear, here!

Re: haven't we learned from the last 25 exploits? (0)

Anonymous Coward | about three weeks ago | (#47412589)

Good advice ! My new plan is to turn off my PC pull the Ethernet then burn my hard drive. Maybe we can also go back to horse and buggy to many people getting killed in car accidents.

Just so you know: DE 7 BR 1 (-1)

Anonymous Coward | about three weeks ago | (#47412271)

And 5-0 after the first 29 min. Go home and cry, Brazil. Oh, wait, you are home, and spent Billions on facilities in the middle of nowhere.

say wha? (0)

Noah Haders (3621429) | about three weeks ago | (#47412285)

JSONP callback functions normally return a JSON blob wrapped in a user-specified callback function, which the browser will then execute as JavaScript. Nothing out of the ordinary here. However, the new attack has leveraged a method of crafting a Flash file to contain a restricted character set that's usable within JSONP callbacks (i.e. in a URL). By combining the two, the attack demonstrates it's possible to use a JSONP URL with the contents of the crafted Flash file as the callback function. When set as the data of a standard HTML object tag, the SWF file executes on the targeted site, bypassing all Same-Origin policies in place.

ummmm what? english please!

Re:say wha? (1, Insightful)

Anonymous Coward | about three weeks ago | (#47412345)

English translation: as usual, Flash is useless except as a vector for malware, viruses, trojans and keyloggers. Remove Flash from your system.

Re:say wha? (4, Insightful)

Arker (91948) | about three weeks ago | (#47412415)

"English translation: as usual, Flash is useless except as a vector for malware, viruses, trojans and keyloggers. Remove Flash from your system."

That's actually not quite true. Flash is a great way to develop simple games quickly and cheaply.

The problem isnt Flash itself (which is on the whole a fine product, used correctly) but the idea of using Flash as a substitute for a webpage, the installation of it as a browser plugin, and the auto-execution of it by the browser. None of that should be tolerated.

It's still possible to get a standalone flash interpreter and only feed it local, vetted files, which is really fine (or as close to fine as lots of other things you do every day, at least.)  But Adobe seems to be trying their best to discourage that and force everyone to use it as an auto-enabled browser component instead. The one way to use the program that causes major problems is also the one way they want you to use it.

Everyone who has been infected as a result of this should really get together and sue these arseholes, because money is the only language they understand.

Re:say wha? (1)

Mashiki (184564) | about three weeks ago | (#47413293)

As a point, WebM can't replace it fast enough.

Re:say wha? (0)

Anonymous Coward | about three weeks ago | (#47414403)

Evidently, it can't. Maybe someday.

Re:say wha? (0)

Anonymous Coward | about three weeks ago | (#47412355)

It can be summed up as, "JavaScript is utter shit."

Re:say wha? (0)

Anonymous Coward | about three weeks ago | (#47412633)

Says someone who can't code in JavaScript.

Re:say wha? (0)

Anonymous Coward | about three weeks ago | (#47412357)

News for Nerds

Re:say wha? (0)

Anonymous Coward | about three weeks ago | (#47412363)

ummmm what? english please!

Don't install Flash.

Re:say wha? (0)

Anonymous Coward | about three weeks ago | (#47412399)

.... and disable Javascript. That's just as important, if not more.

A harmful chaining of shitty browser hacks. (5, Insightful)

Anonymous Coward | about three weeks ago | (#47412379)

It's basically a case of one shitty, half-assed browser hack (JSONP) being used in a way that allows another shitty, half-assed browser hack (JavaScript) to abuse yet another shitty, half-assed browser hack (Flash) to violate a shitty, half-assed "security" feature (same-origin policies).

The browser is truly the shittiest platform we've ever had. It may be widespread, but good god, is it ever shitty in so many inherent ways. It's just one smear of shit layered upon another. It really is broken all the way down.

Re:A harmful chaining of shitty browser hacks. (1, Troll)

holostarr (2709675) | about three weeks ago | (#47412451)

Either come up with something better or shut up. The browser is far from perfect, but its continuously evolving and is the best platform currently in existence because of its widespread adoption, standards and ease of development compared to all other platforms. Even many desktop and mobile apps these days are wrapping the browser (or built on top of it) in one way or another (for example PhoneGap and nodejs) and use responsive design to assist with the development. Outside of few specialized areas where native client side applications are still necessary, technology is moving towards a new direction and the browser and platforms such as Chrome OS are a the centre of it so you better accept it.

Re: A harmful chaining of shitty browser hacks. (0)

Anonymous Coward | about three weeks ago | (#47412613)

Thank you !! I don't think the anti JavaScript / flash crowd have a clue about the history of the internet or vision about the future. I feel sad for them.

Re: A harmful chaining of shitty browser hacks. (-1)

Anonymous Coward | about three weeks ago | (#47415561)

Thank you !! I don't think the anti JavaScript / flash crowd have a clue about the history of the internet or vision about the future. I feel sad for them.

We have plenty of clue about both.

We know exactly what the history of running untrusted code on your machine is: the user gets pwned.

We also know what your vision of "the future web" is. We reject it because we believe security is more important than usability. We learned that lesson when our UNIX boxes were getting pwned with the Morris Worm and through umpteen holes in Sendmail, and when your Windows boxes were getting pwned with viruses that used the embedded programming capabilities of Word/Excel macros. We rejected your vision back when ActiveX was a thing.

Re: A harmful chaining of shitty browser hacks. (1)

holostarr (2709675) | about three weeks ago | (#47415971)

Who are "we"? If people like you represented majority, companies like Google would have already been out of business. In the real world, however, developers pick the right tool for the right job and browser technologies have their place. So go ahead and continue with your deluded reality and ignore the web, you will not be missed.

Re:A harmful chaining of shitty browser hacks. (0)

Anonymous Coward | about three weeks ago | (#47414405)

Sorry web "developers". The browser is on the way out. Everyone's going to apps on mobile devices. True, some apps may use JS in a wrapper but the browser is broken and people are tired of it.

Re:say wha? (4, Informative)

grcumb (781340) | about three weeks ago | (#47412419)

JSONP callback functions normally return a JSON blob wrapped in a user-specified callback function, which the browser will then execute as JavaScript. Nothing out of the ordinary here. However, the new attack has leveraged a method of crafting a Flash file to contain a restricted character set that's usable within JSONP callbacks (i.e. in a URL). By combining the two, the attack demonstrates it's possible to use a JSONP URL with the contents of the crafted Flash file as the callback function. When set as the data of a standard HTML object tag, the SWF file executes on the targeted site, bypassing all Same-Origin policies in place.

ummmm what? english please!

The code sneaks a Flash file disguised as a URL into some JSON data and cons the browser into treating it as JavaScript, but on the local machine it acts like an HTML <OBJECT>, and because the browser is executing the Flash code locally now (due to the masquerade), it can run with greater privileges than if it were from a remote site.

Or in layman's terms: Flash totally sucks the suckage, dude. Always did. Still does.

Re:say wha? (1)

NemoinSpace (1118137) | about three weeks ago | (#47412421)

He said, don't bring your laptop to hacker shows in Malaysia. But if you *do* manage to get it through airport securitI, and not have it stolen by baggage handlers *don't* click on flash. Because downloading pr0n in Malaysia is illegal. Just stay home and use NSA approved safe methods of browsing. Oh, and if your the type that carries sensitive information on your cell phone, well, die then.

I'll take a shot at it. (5, Informative)

cbhacking (979169) | about three weeks ago | (#47412651)

I don't know about English, but I can produce an explanation that is understandable by most people with at least some knowledge of how the web works, hopefully... It's not going to be short or simple, but I'll at least try for clear.

JSONP is a web service communication method. The idea is that a client (a web browser) sends a request to a given URL, and in that URL they include a "callback" parameter. The response from the server is a blob of JavaScript starting with the callback parameter (as a function name), and then containing additional data (as a JSON-defined object, usually). Examples:
A target URL that looks like this:
https://vulnerablesite.com/jsonp_service/some_endpoint?callback=jsonp.handle_some_endpoint
Produces a request like this (no body, and some headers omitted for brevity):
GET /jsonp_service/some_endpoint?callback=jsonp.handle_some_endpoint HTTP/1.1
Host: vulnerablesite.com
Cookie: VulnerableSiteSessionCookie=JoeBlowIdentificationValue ...

That produces a response like this (again, header details omitted):
HTTP/1.1 200 OK
Content-Type: application/javascript
Content-Length: 41
...

jsonp.handle_some_endpoint({"foo":"bar"})
The browser would then interpret that response as JavaScript, calling the named function.

Now, this looks risky but normally it's safe enough, because while an attacker could embed a <script src="https://vulnerablesite.com/jsonp_service/some_endpoint?callback=jsonp.handle_some_endpoint" /> script source tag that specifies an arbitrary callback name (which then gets executed as JS), there's nothing really dangerous they can do with that because the server will disallow most sensitive characters in JS (things like ( ) = ' " < >) from the callback name, so you can't actually embed arbitrary javascript in the response. Usually the attacker doesn't control the content of the parameter (the JSON blob) either, or at least can't make it be anything except JSON (which is normally pretty harmless). For example, the attacker could pass "alert" as the callback, in which case the victim gets a message box saying "[object Object]" or similar. Whoop-de-do.

OK, so the attacker can't do much just by invoking a script with an arbitrary callback name. However, Flashplayer can execute applets in a number of formats, including formats that are theoretically compressed. I say "theoretically" because there's actually nothing requiring the data to be "compressed" in any even vaguely efficient manner (which tends to produce dense blobs of seemingly-random binary values). Instead, it's possible to create a "compressed" file that only contains alphanumeric characters (and is therefore valid as a callback name), but when it is "expanded" it produces an arbitrary binary blob (such as a compiled Flash applet).

So, here's what the attacker does. They create a malicious Flash applet. They run it through the special compiler this guy came up with, which converts it into a "compressed" applet format containing only characters that are valid for a callback name. They place an HTML object tag on their own, attacker-controlled website. The object specifies the jsonp service on the vulnerable site as its data source (the way one might specify youtube's flash applet as a data source), and specifies the callback name to be the alphanumeric-format applet. The attacker also specifies that the type of the data is application/x-shockwave-flash.

When a user visits the attacker's site, their browser sees the object tag and tries to retrieve the specified data. The response they get back is *actually* a JSONP script, but the first part of it - the callback function name - is *also* a valid Flash applet. Because the object tag specifies that the data type is Flash, the browser obligingly loads Flashplayer and runs the malicious applet (it ignores the ({"foo":"bar"}) blob at the end).

Now, here's the really mean part. Up to now, you may be wondering why they bothered to go to so much effort. I mean, wouldn't it just be easier to load the Flash applet from the attacker's site, instead of tricking the vulnerable site into returning a JSONP response that starts with a Flash applet? The thing is, browsers have a Same-Origin Policy. This is one of the core security features of the web. In a nutshell, it goes like this: if site X makes a request from site Y, and X and Y are not the same origin (meaning they have different domains, or different port numbers), then site X can't see sensitive data (like cookies, or headers, or HTML content) from site Y.

Therefore, if the attacker hosted the malicious applet on their own site (X), it could send a request to the target site (Y) but X wouldn't be able to see any of the juicy details (like the session cookie for site Y of the user visiting site X). However, this attack makes it seem that the applet is actually hosted on site Y. Therefore, as far as Flashplayer is concerned, a request to site Y is made in the same origin as the applet, and the applet therefore gets all the details it wants. Once the applet has those details, it can make a second request "back" to site X, telling it all the secret details. That then allows the attacker to do things like impersonate the victim user on site Y.

Mitigations (4, Interesting)

cbhacking (979169) | about three weeks ago | (#47413273)

Sorry to self-reply, but I figured I should add some mitigations (for those who don't RTFA...)

First of all, as a user, one can of course disallow Flash by default (or remove it entirely). Mechanisms for doing this vary by browser, but all major browsers have at least one.
You can also update Flash. The latest version, released today (Tuesday the 8th), tightens up the validation of "compressed" applets in such a way that it should catch the output of this "Rosetta Flash" program.

For sitemasters / developers, there are a few options.

  • You can host your JSONP service on a different (sub)domain from your sensitive data. This is most effective if the JSONP responses are either static or if there's a CSRF token for accessing the user data.
  • You can add the string /**/ to the beginning of the JSONP response body, right before the callback identifier (this is what Google and GitHub are doing, for example). This will be ignored by the browser when it's treating JSONP as JavaScript (a 0-character comment) but will break the reflected-Flash-applet attack because the start of the response body no longer contains the magic number for any kind of Flash applet.
  • You can add a HTTP response header like Content-Disposition: attachment; filename=f.txt to the JSONP responses, which will prevent all reasonably recent versions of Flashplayer from executing it the applet.
  • You can add the HTTP response header X-Content-Type-Options: nosniff to all vulnerable responses (or just all of them), and then make sure that you specify the correct Content-Type header (it should be Content-Type: application/javascript although application/json, while technically incorrect, will probably work too). This header forces most browsers to pay attention to the server-provided content type, rather than letting the web page specify or guessing from the content itself.

Hope that helps!

Very clever (4, Interesting)

mc6809e (214243) | about three weeks ago | (#47412417)

Reminds me a little of some work done by Terje Mathisen, an expert assembly language programmer. Not exactly that same as the exploit, but probably interesting to a few slashdotters. I'll let him describe it:

"The most complicated code I have ever written is/was a piece of executable text, in order to be able to send binary data over very early text-only email systems:

"Minimum possible amount of self-modification (a single two-byte backwards branch), a first-level bootstrap that fits in two 64-byte lines including a Copyright notice and which survives the most common forms of reformatting, including replacing the CRLF line terminator by any zero, one or two byte sequence. This piece of code picks up the next few lines, combining pairs of characters into arbitrary byte values before flushing the prefetch cache by branching into the newly decoded second-level bootstrap. (Everything uses only the ~70 different ascii codes which are blessed by the MIME standard as never requiring encoding or escape sequences.)

"This second level consists of a _very_ compact BASE64 decode which takes the remainder of the input and re-generates the original binary which it can either execute in place or write to disk.

EICAR test virus (0)

Anonymous Coward | about three weeks ago | (#47415761)

The EICAR test virus does something similar. DOS executable with assembler instruction values only from the printable ASCII character set. Nowhere near as sophisticated as the above reference piece.
http://www.rexswain.com/eicar.html

JS (2, Insightful)

mfh (56) | about three weeks ago | (#47412473)

This doesn't surprise me. Few developers truly understand how many vectors JS opens up. Just KISS and let's move forward.

JS fanboys are ruining everything.

Re:JS (1)

Elminster Aumar (2668365) | about three weeks ago | (#47412653)

I'm just happy we have patriots like you to help maintain the wonderful geek culture we never get subjected to through biased perspectives and impulsive assumptions.

Re:JS (2)

mfh (56) | about three weeks ago | (#47412877)

JS is totally impulsive for a site designer. They just decide to add so many different bells and whistles that they don't have enough time to do penetration tests on any of it. They grab source code from ANYWHERE and tack it on their site. Nobody checks that stuff.

Run NoScript and there are tons of sites calling 10+ different JS blocks.

Moral hazard.

Re: JS (2)

corychristison (951993) | about three weeks ago | (#47413031)

I agree with you to an extent. The problem lies mostly in that users (developers) don't know what they are actually doing. They are typically young and have no real world experience. As you say, they 'tact peices of code together'.

The other

Re: JS (1)

corychristison (951993) | about three weeks ago | (#47413041)

(Bah. Touchscreens will be thr death of me)

The other issue is Javascript can do too much. I really only use a small subset of it in my own projects. Basically just simple DOM manipulation, and the odd calculation.

Re:JS (1)

holostarr (2709675) | about three weeks ago | (#47413249)

You are telling me when you build a client side native applications (lets say in c or c++) you look through every line of source code for each library you use? And not all of us web developers just "grab source code from ANYWHERE and tack it on", that is what sets apart good web developers from the bad ones; good developers do research on the libraries and frameworks they use and pick ones that are trusted, well maintained, and are industry standards. Furthermore, there really is not much of a difference between a web developer and a client side application developer, in fact many of us got our start developing client side applications, people need to come out of the mentality that client side developers are somehow more superior in skill to web developers -- today's web developers are not yesterday's web developers who just built simple web sites with static content, most web developers are building incredible applications which are as challenging as their client side counterparts, if not more.

Re:JS (0)

Anonymous Coward | about three weeks ago | (#47413559)

One thing is using a library...
the other is "oooh i would like a flashy button for the supper dupper page i'm scripting..." better ask google for one and copy paste... (this shit really happens)...

my 2 euros...

Also, screw the HTTP Protocol (0)

Anonymous Coward | about three weeks ago | (#47413223)

Gopher and UUCP are good enough for me! Really nobody should be using anything more than ASCII text files. I was about to suggest EBCDIC, but I then realized that we are living the year 2014.

And yet, mozilla won't let you disable javascript (0)

Anonymous Coward | about three weeks ago | (#47412519)

In Mozilla's stupidity, they decided to remove a very useful feature.

Sigh. I shouldn't have to run noscript.

Re:And yet, mozilla won't let you disable javascri (0)

Anonymous Coward | about three weeks ago | (#47412603)

What do you mean?

javascript.enabled. Set it to false, and voila, disabled javascript.

Surely noscript is handier for its while/blacklisting abilities, but disabling javascript is something you can do with no extensions, out of the box.

Re:And yet, mozilla won't let you disable javascri (0)

Anonymous Coward | about three weeks ago | (#47412647)

That's way too much effort for something that was really easy to do before. Mozilla introduced a bug into Firefox by removing the ability to easily disable JavaScript without having to fuck with its about:config values, even if they're too fucking stupid and/or ignorant to acknowledge this.

Re:And yet, mozilla won't let you disable javascri (0)

Anonymous Coward | about three weeks ago | (#47415669)

That's way too much effort for something that was really easy to do before. Mozilla introduced a bug into Firefox by removing the ability to easily disable JavaScript without having to fuck with its about:config values, even if they're too fucking stupid and/or ignorant to acknowledge this.

I use PrefBar to solve this problem. http://prefbar.tuxfamily.org/ [tuxfamily.org] . Single bar across top of browser to toggle Javashit, Flash, Cookies, proxies, referrer-ID, and moar.

PrefBar has lots of unanticipated uses. When Google Image Search changed its default behavior to "Javashit on, get infinite scrolling crap" and "Javashit off, click on thumbnail, go to the webpage that hosted the image (often the wrong page, or some long forum thread with a thousand posts in it)", you can tell it you're using Lynx. With Javashit disabled and a User-Agent of lynx, it reverts to two-pane view of a big frame that you can ignore, and a thumbnail, beneath which is the URL of the image you're actually looking for. You can pop that open in a new tab and have the desired image before the the irrelevant website even loads in the two-page tab.

And as long as I'm ranting here, I'll also chip in with a hearty fuck beta, fuck webdevs, and most of all, fuck Asa Dotzler and all his UX clones.

Re:And yet, mozilla won't let you disable javascri (1)

dveditz (11090) | about three weeks ago | (#47416295)

That misses the point of this vuln entirely which requires NO JavaScript whatsoever on the user's part. The site is written to use JavaScript and set up a JSONP service. This trick fools the JSONP service into returning a "callback name" that just so happens to be valid .swf data. The attacker then uses the URL that triggers that response in a context that expects flash (e.g. an or tag). As far as Flash is concerned the .swf came from that site so it's allowed to make any further requests to that site it wants. [I, too, am sad the UI for disabling JS is gone, but honestly for myself I've always used the Web Developer Toolbar when I wanted to disable JS because it's faster to get to that option.]

Not vulnerable (1)

viperidaenz (2515578) | about three weeks ago | (#47413355)

I don't have flash installed.
Threat mitigated.

Steve Jobs was right (1)

trevc (1471197) | about three weeks ago | (#47416383)

Steve Jobs was right when he said no Flash and took a lot of criticism for that.
Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...