CSS Is Now So Overpowered It Can Deanonymize Facebook Users (bleepingcomputer.com)

An anonymous reader writes: Some of the recent additions to the Cascading Style Sheets (CSS) web standard are so powerful that a security researcher has abused them to deanonymize visitors to a demo site and reveal their Facebook usernames, avatars, and if they liked a particular web page of Facebook. Information leaked via this attack could aid some advertisers linking IP addresses or advertising profiles to real-life persons, posing a serious threat to a user's online privacy. The leak isn't specific to Facebook but affects all sites which allow their content to be embedded on other web pages via iframes.

The actual vulnerability resides in the browser implementation of a CSS feature named "mix-blend-mode," added in 2016 in the CSS3 web standard. Security researchers have proven that by overlaying multiple layers of 1x1px-sized DIV layers on top of iframes, each layer with a different blend mode, they could determine what's displayed inside it and recover the data, to which parent websites cannot regularly access. This attack works in Chrome and Firefox, but has been fixed in recent versions.

Comments

umm no

[Anonymous Coward]

Umm Facebook is soo overpowered that they have soo much information COUPLED with poor coding that permits leaking this infomation...

If it was already fixed...

[Anonymous Coward]

What's the big deal? CSS isn't the problem, browser's shoddy implementations is/was.

Only last sentence is relevant

[93 Escort Wagon]

”This attack works in Chrome and Firefox, but has been fixed in recent versions.”

In other words, this is a clever exploit of a bug - not a fundamental issue with CSS. The rest is FUD.

Re:Only last sentence is relevant

[Anonymous Coward]

This is hardly the first time CSS has been used as an attack vector. You used to be able to tell the websites a visitor visited by listing a bunch of links, and then checking if they matched visited link CSS.

Re:Only last sentence is relevant

[Actually, I do RTFA]

No, this is an exploit of a fundamental issue with CSS. By breaking with the standards, Chrome and FireFox are avoiding the issue.

It's similar to how no browser fully implements the JS spec. Because it has some (very edge case) stupid behavior. But that's okay, because the unimplemented parts will never come up anyhow.

Re:Only last sentence is relevant

[Peter P Peters]

”This attack works in Chrome and Firefox, but has been fixed in recent versions.”

In other words, this is a clever exploit of a bug - not a fundamental issue with CSS. The rest is FUD.

'This attack works in Chrome and Firefox, but has been fixed in recent versions' really means 'this attack no longer works in Chrome or Firefox'. But to sell clicks you need to FUD it up as much as you can.

Re:Only last sentence is relevant

[HarrySquatter]

So you think everyone is always running the latest versions of all software? Are you naive or just intentionally dense?

Re:Only last sentence is relevant

[Narcocide]

That one might actually still work...

Re: Only last sentence is relevant

[Actually, I do RTFA]

On the contrary, timing attacks are a problem in the specification. "Do X as fast as possible" is the default. "Do X in constant time" is an exception. It's a fundamental flaw in the spec.

Ultimately, specifications need to anticipate attacks and include mitigations.

Re:Only last sentence is relevant

[Peter P Peters]

So you think everyone is always running the latest versions of all software? Are you naive or just intentionally dense?

Cool story...

CSS so overpowerd it changes headline color

[Anonymous Coward]

and if I don't use Facebook?

oh it's fixed too?

clickbait!

We need to freeze the Web Specifications.

[xack]

No more adding features to HTML5/CSS/JS. They are only being used for things like tracking, spying, malware and crypto mining.

Re:We need to freeze the Web Specifications.

[Actually, I do RTFA]

No more adding features to HTML5/CSS[3]> /JS

You mean, let's go back to HTML4/CSS2/[No JS, because why]. If people want GoogleDocs let it be a fucking native plugin.

Re:We need to freeze the Web Specifications.

[K. S. Kyosuke]

Also, embedding a scripted programming language in a different document format is an abomination.

I agree, it should have been Lisp all the way down.

Re:We need to freeze the Web Specifications.

[Sarten-X]

If people want GoogleDocs let it be a fucking native plugin.

Oh yes... because having Flash everywhere worked so well for us all.

Re:We need to freeze the Web Specifications.

[Sarten-X]

CSS and JS are pretty much just patches added on top of HTML because HTML isn't a suitable document format to describe web pages the way page creators want them to be.

HTML, CSS, and JS all do completely different things, if used correctly.

HTML should describe the content of the page. It should be the words spoken by a screen reader, or the information a search engine should index. In essence, it is just the meaningful information, in its most-native structure, and nothing more.

CSS is the presentation of that information. There should be CSS definitions for how that screen reader should pronounce particular words or emphasize particular phrases. There should be CSS definitions for how the page appears at all different display sizes, or if it's being printed to a static medium, or even being sent to Braille output hardware.

Scripts should describe the page's behavior. Beyond the built-in behaviors of the browser (which IMHO should themselves be defined in built-in scripts, just like the browsers have built-in default CSS), scripts are responsible for building interaction between elements of the page and back-end server.

If the document format was better suited for what it is used for...

...then accessibility and dynamic presentation would be horribly broken, as it was back in the bad old days before CSS.

JS should be the outer layer and generate/modify the document in those cases JS is needed.

...which means that everything that wants to access the informational content of a web page would need an embedded script engine, and enough watchdogs and security to mitigate the risks inherent in executing remotely-generated code on your system. This is a huge problem for browsers already, but making a script be a mandatory layer would mean using the Web is far more expensive for caching proxies and embedded devices.

Re:We need to freeze the Web Specifications.

[Actually, I do RTFA]

because having Flash everywhere worked so well for us all.

Yes it fucking did. Flash/HTML4/CSS2 was strictly superior tech stack to HTML5/CSS3/JS. It handled cross-domain security better. It handled browser isolation better. It was a better programming language. It had fewer super-tracking features.

I will give you that Flash pushed people towards XML and JS pushed people towards JSON.

Re:We need to freeze the Web Specifications.

[tlhIngan]

Yes it fucking did. Flash/HTML4/CSS2 was strictly superior tech stack to HTML5/CSS3/JS. It handled cross-domain security better. It handled browser isolation better. It was a better programming language. It had fewer super-tracking features.

It may be technically better, but the implementation was clearly worse.

Because there were constant security issues, basically weekly. Update, update and update, and Adobe was completely inept at it, because even "installing fresh" still installed old vulnerable versions. Eventually, they gave up simply due to cost reasons.

And super tracking used flash extensively - the "super cookie" exploit where a website could set an non-removable cookie used flash. You could delete every cookie on your system but miss one and they would re-appear. And the way to manage Flash cookies was extremely lame. There was no need to do super tracking because flash ensured your cookies stayed with you. Or better yet, even violating the cookie policies of the browser.

I'd say things are better off now, simply because we're not relying on a single company to update their plugin. Heck, Adobe was genuinely slow enough that 0-days will be up, forcing the security release, and timelines were often at least a week away. for a fix. (And remember, Adobe has no incentive to fix Flash player issues, since it was something it had to give away).

Re:We need to freeze the Web Specifications.

[Actually, I do RTFA]

Adobe has no incentive to fix Flash player issues, since it was something it had to give away

Flash Player was given away. Flash (the developer software) was highly profitable software. Econ 102 says you give away things that make more people buy your highly profitable goods.

d say things are better off now, simply because we're not relying on a single company to update their plugin.

Adobe opened up Flash Player precisely because they didn't make money off it/didn't want to maintain it. IIRC, there was even a GNU implementation. I know Mozilla had an inhouse one. Yeah, it had issues, but I'm not so sure that it was that much worse than the general tech of the day. Fortunately, all software seems to be more secure now. (Even Windows!)

And super tracking used flash extensively

The supercookie used everything, pretty much by definition.

I grant that Flash ignored the cookie policy of the browser. But it had things like "don't allow cookies from third party domains" before it was a glimmer in the browser's eye (do all browsers even have that yet?) I found their settings easier (among other things, turning off all cookies broke practically no sites.) But you are right that even superior settings, if different from what people expect, can be pretty bad.

Crying wolf

[Anonymous Coward]

This attack works in Chrome and Firefox, but has been fixed in recent versions.

So then it _can't_ be used to deanonymize Facebook users.

Why is this a problem then?

Re:Crying wolf

[HarrySquatter]

Because lots of people run old versions of software?

Re: Lazy Coding not CSS

[Anonymous Coward]

Congratulations on having no grasp at all of the security implications in the premise of this article.

Re:The problem here isn't with CSS3

[Anonymous Coward]

The headline should read Facebook security is so underpowered that CSS can deanonymize users.

I'm no fan of Facebook, but that's definitely not what the headline should read.

The attack works by using the blend effects to read the pixels rendered within an iframe. It's not reading the DOM of the iframe at all.

Are you suggesting that Facebook and other websites should have come up with a way to make it impossible to read the pixels on a webpage? .... ohhhhh, you're a DRM developer, aren'tcha? :)

Re:Iframes should just be banned.

[jellomizer]

At least apply the same rules that most browsers to in AJAX calls prevent calling a site that is on a different server. Yes it sucks for developers but if you make the serverside passthru you now have some control of the security.

Unfortunately good security doesn’t mean the easiest way to code it

uh no?

[pezpunk]

this is moronic. if Facebook is leaking private data to the client browser, this is NOT a CSS problem. what an insipid and misleading headline.

Re:uh no?

[Hognoxious]

if Facebook is leaking private data to the client browser

Would it make a difference? They're leaking it everywhere else.

Re: uh no?

[oobayly]

That's only true if you were to lazy to read how the attack actually works.

Re:uMatrix

[grub]

I use uMatrix and the "CSS Exfil Protection" add-on for Firefox. There are some sites I use that need CSS to be even remotely useable. Check it out, it has a test page.

Re:Iframes should just be banned.

[Narcocide]

Interestingly enough, the W3C did try to remove iframes and frames both from the spec. Pressure from advertisers over this and some other sanity-induced changes caused the industry to split with the W3C though and make their own "HTML5" standard, which the W3C then only later ratified in order to remain relevant.

Good thing I clear my data

[quonset]

And don't use Facebook.

Every day I clear my data. Everything is wiped clean and I start fresh. Yes, advertisers could deduce about me with each daily trek through the Net wilderness, but I also have uMatrix which blocks other forms of advertising and intrusive behavior so they have to work for it.

Regardless, since I don't see whatever it is they're peddling, it's no big deal. It costs them money so I'm happy.

Re: Iframes should just be banned.

[reanjr]

Lots of web apps nowadays don't even pass through anything but a static server. Requring third party APIs to pass through a server in many cases undermines the way the web is designed to work.

Blue?

[fisted]

So why is this story blue?

Re:Blue?

[hcs_$reboot]

CSS powerfulness.

Re:Blue?

[mentil]

Probably related to it being posted by 'FirehoseFavorites' which I presume is a bot that autoposts highly-rated Firehose entries if the editors don't post (or queue) anything for long enough. Although this was followed by 2 queued stories so who knows.

Re:Blue?

[93 Escort Wagon]

“Firehose Favorites” are blue. This is only the second or third one I’ve seen since Whipslash talked about it quite a while ago.

Re:Blue?

[fisted]

S-so CSS can be used to color elements of a web page? I never knew.

Re:Blue?

[whipslash]

Yes just live testing a feature that 93 Escort Wagon remembers from a while back. Autoposting extremely popular firehose items to the front page. Won't happen unless it's extremely popular.

Facebook is the root of all evil.

[shm]

Just delete your account already and flush its cookies.

I know it doesn't really delete any as Zuck is confirmed liar, but at least don't give him any excuse to have your data.

Hopefully the EU GDRP is the first step to wipe this obscenity off the face of the earth.

Password keylogger via CSS

[Dynedain]

You think this is bad, try a password keylogger implemented purely as CSS (no javascript):

https://css-tricks.com/css-key...

The real vulnerability in both this and the article example is allowing 3rd party code injection. If you can't trust the source of the code, the language being used doesn't really matter. There will be ways to abuse it.

What about non-Chrome/Firefox?

[Titanek]

Are browsers like Opera and Edge still vulnerable then? I can't seem to find anything on that.

Attacks like these aren't new

[Qbertino]

Rendering blur effects on fonts and measuring the time to render to guess letters, checking for expected remote case to expose surfing history ... The stuff web hackers can do is pretty amazing. If you're in web development and are looking for a reason to switch to sheep farming just visit a web hacker conference. You'll come home crying.

fear the clock

[epine]

I've commented to a mathematical friend more than once that computer science is mathematics, plus the assumption that time exists. (This also explains why I'm LISP-boner impotent. LISP is computer science, ++delay, minus the assumption that time exists; the user sees time, while the programmer doesn't—what's not to like?—but I still don't get the happy hardness.)

Moral of the story: fear the clock.

Do not fear napkin Turing-complete, CSS Turing-complete, nor LISP Turing-complete. (Turing-complete happens by accident at least once out of every nine innings of billiard-table HO-gauge NAND-gate pick-up-sticks.)

Perhaps what we need is a degraded system timer.

Ideally, the local mean would wander somewhat slowly on a fractalish time scale, only minimally convex around the extremes so as to stay within a +/- 30 second deviance specification for 99.8% of all samples. Ideally, the estimate of the mean would converge considerably more slowly than sqrt(N). But I don't know my thick-tailed distributions well enough to say what that would look like as an actual thing. You also don't want the difference between step changes to be small, on average; and you don't want the locations of the step changes to occur on precise, minute boundaries, either (duh!) In fact, I think sloppy-clock would return an ascending integer sequence, but the wall-time duration of each distinct integer interval (of minute-ish duration) would be unpredictable, as described.

My math is feeble enough that I can't even prove that my sloppy-clock as roughly stipulated even exists in practice, but let's assume it does.

Then you need to implement a security ring where the best clock available is sloppy-clock—and stuff all foreign scripts in there. Yes, plugging time leaks from the outside world in a sophisticated API is hard. True mathematicians need not apply (i.e. LISP won't help you in this endeavour, not even a little bit).

By avoiding capacitors (condensors) von Neumann's IAS computer could be frozen and single-stepped, or run at any frequency you desired, until the internal bit signals themselves became unstable. (Some of these early designs were actually asynchronous and self-timed.) Effectively uncoupled from the real world, such a machine has no ability to introspect the duration of its own operations—unless you screw up, and give it an actual wall clock or cycle-clock or global operation-count API (the second case is only possible with synchronous designs).

Uncoupled computing (Internet 404) is not popular under the modern CSS paradigm, so you do probably have to at least make a concession for sloppy-clock (which dingbat users can upgrade to precise-clock if it bothers them that their ESPN scoreboard page refreshes aren't entirely concurrent with the real world; it would also suck for implementing chess clocks; but not, strangely, for anticipating when a soccer game will officially end).

Anyways, this whole proposal is a massive research project.

I'm merely pointing out that computer science is merely mathematics—right up until time begins.

Von Neumann's early IAS computer didn't even have (internal) time. (That's because they had more than enough problems to deal with, already, without scoring an own goal.) Interestingly, Turing specified hardware random number generation from the get go, on purely formal reasoning about the space of available computation. Turns out, precisely measurable operational elapsed-time is ultimately more insidious (under promiscuous interconnection) than nondeterminacy. (A promiscuous web page being any web page bearing more than one cookie, or related code artifact.)

Maybe time does not fly like an arrow as described in its early scouting reports—but it certainly does leak (across code-execution trust domains) like a bat out of hell.

Re:fear the clock

[epine]

My "own goal" comment was actually a bit of a joke (ha! made you think) because elsewhere I state that time oracles were far less of a hazard back in the day of Internet 404.

But you could already have your programming team for the hydrogen bomb's neutron Monte Carlo simulation partitioning into less classified programmers who write the I/O portion (generally punched cards on stdin and stdout, in some cases every card representing a separate neutron) from the highly classified mathematicians coding the actual neutron model.

So imagine you've got Klaus Fuchs on your I/O team, and he wants to write I/O code to leak secrets about the neutron algorithm, which he stegs into some output stream he's actually allowed to see (this is probably a severe security oversight, already, but oh well).

If his I/O code has some access to a precision wall clock, which he can read as many times as he wants each time his I/O code runs, who knows what details might leak about the simulation algorithm itself, based on electrical artifacts it leaves behind. (I believe row hammer was already very much a thing concerning the Williams tube storage array.)

Really, the pernicious time problem stems from any partition of the trust domain roped into the same computational task (or shared processing environment).

Re:Blue headline?

[whipslash]

This story was autoposted from the Firehose without editor input due to reaching an extreme threshold of upvotes. New feature we are testing

This is not an attack...

[Evergreener]

THIS IS FACEBOOK!!!

Words matter.

[TheRealHocusLocus]

[TFA] security researcher has abused them

Hey wait. This is a tech site.
How about leveraged them, or even used them?

Imagine non-tech readers. It's a gimmick to trigger one of those "there oughta be a law" responses. THIS is how we get laws against the sale and possession of radio scanners that can tune in unprotected police communications. And instead of forcing police to upgrade their equipment, they get a bonus opportunity during traffic stops to pretend that their K9s 'signalled' the presence of an illegal scanner. Which in turn, encourages farmers to grow smaller potatoes.

Re: Iframes should just be banned.

[jellomizer]

The web was designed to be a choose your own adventure book.

Then people wanted better formatting options, and then they want to fill out information with forms, then these forms would like to have a client side to validate data. Then we wanted more advanced formatting options, and be able to change the HTML without refreshing a page.

The Web is now an Application Platform. Because of this, it needs security restrictions to make it work as such.