- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 27 Jun 2018 16:48:29 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `Consider disallowing NULL code points in stylesheets`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Consider disallowing NULL code points in stylesheets<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/2757<br> <fantasai> Tab's position: https://github.com/w3c/csswg-drafts/issues/2757#issuecomment-396337601<br> <dael> florian: The issue is that having a null codepoint in the middle of stylesheet is not useful in general, but is a potential security risk. Could single something like a code extract. Therefore we should kill the stylesheet somehow. How and how much should be discussed. Poss reject entire stylesheet or a milder version<br> <dael> florian: Going further I'm not the right person, but that's high level.<br> <dael> hober: Current interop?<br> <dael> florian: I believe not. Current is that browsers discard, but how they recover doesn't seem interop.<br> <dael> florian: There are mentions of differences in the issue. HOw different I'm not sure<br> <dael> Rossen_: I ran through all of these locally. I was seeing interop between Edge Chrome and FF on all the test cases in the issue<br> <dael> Rossen_: Curious to hear from dbaron<br> <dael> dbaron: Sounds like emilio has but I haven't<br> <dael> bradk: Any idea how often this is in the wild as possibly a mistake?<br> <dael> Rossen_: Not sure we have such data<br> <dael> Rossen_: If you're asking how often people try and spoof browsers it's quite often and this is a potential attach vector, but this is more speculative.<br> <dael> florian: Question is how often do we have almost valid style sheets that were meant to be read.<br> <dael> Rossen_: Don't think we can disambiguate between<br> <dael> bradk: Concern is break working stylesheets<br> <dael> Rossen_: My understanding is you could have actual end user effects<br> <dael> bradk: Will this break websites?<br> <emilio> Err, present+<br> <dael> Rossen_: Potentially<br> <dael> plinss: Tooling injecting null bites is fairly low unless they'll already be present<br> <dael> florian: Current possible interop you Rossen_ observed is it reasonably safe or interop unsafe?<br> <Rossen_> http://jsbin.com/vozudorilu/edit?html,output<br> <dael> Rossen_: I won't make statements in terms of this as an attack vector. From interop, I just re-ran a variation on some test cases I observe differences here ^<br> <dael> Rossen_: In this case you join the null character. This invalidates in Chrome the entire selector. In FF and Edge we only invalidate the join part of the last selector and honor the first part.<br> <dael> Rossen_: Result is after joining selector with null Edge and FF get red and black default in Blink<br> <dael> florian: I get black in FF<br> <dael> Rossen_: Well...I don't know version.<br> <dael> florian: 61. Updated today<br> <dael> Rossen_: I'm on 60. Let me take the 61 update<br> <dael> emilio: [something about nightly]<br> <dael> Rossen_: So there is non-interop<br> <dael> Rossen_: FF 61 I still see red<br> <emilio> s/[Something about nightly]/Nightly shows red to me/<br> <dael> fremy: I see red in every browser<br> <dael> Rossen_: Instead of debating this test case. Let's go back to the behavior in issue.<br> <dael> florian: Safe proposal is if you see any null descard entire stylesheet<br> <dael> fantasai: 3 proposals<br> <dael> fremy: I don't see doing that. I don't see why a null bite is a security issue. I don't see why discard an entire stylesheet<br> <dael> florian: One nul bit not dangerious. no known use case but can be sign of attack<br> <dael> fremy: Any JS is sign of potential attack.<br> <dael> Rossen_: That's not only option. it's A option.<br> <dael> fantasai: Otehrs were terminate stylesheet at that point. 3rd was auto invalidate any construct with that null according to normal invalid rules<br> <fantasai> e.g. invalidate declaration, or style rule, or whatever construct we would normally invalidate<br> <dael> Rossen_: 3rd makes most sense. Finding the closest adjacent or encompasisng rule/select/whatever and discard that is most intuative.<br> <bradk> Option 3 seems most reasonable to me<br> <gsnedders> I agree with fremy, given we don't do the same in HTML.<br> <dael> Rossen_: 2nd is a variation of that and almost as bad as discard entire stylesheet<br> <dael> plinss: Another option is ignore null and pretend not there. Rossen_ you seem to favor terminate existing construct, but that's most dangerious for security because ti means you have to pass it through. If you ignore the null or terminate or discard you can do that at preparse and then you're safe.<br> <liam> +1 to plinss<br> <dael> fremy: Still dont' understand premise null bit is unsafe<br> <dael> florian: It may be a tell tale sign something else is being attempted. If someone is dumping content of memory you'll see null bits<br> <dael> plinss: Risk is you have some code that takes entire construct with the null in the middle and others that terminate the string and you're opening to security vulnerabilities.<br> <dael> Rossen_: Thinking a bit more I like the 4th option to ignore null codepoints during preparse and curate the stylesheet as if there were no code points.<br> <dael> florian: If you dump memory without nulls you can still export that to some server.<br> <fantasai> plinss, wouldn't handle Tab's concern in 1st paragraph of https://github.com/w3c/csswg-drafts/issues/927<br> <gsnedders> q+<br> <dael> gsnedders: As presedent html replaces null with +fffd and that's better then drop<br> <gsnedders> ack<br> <dael> plinss: [missed]<br> <gsnedders> Zakim: ack<br> <gsnedders> q-<br> <dael> florian: Then not dealing with security problem. If you keep null bites you can keep them on server.<br> <liam> s/bites/bytes/<br> <dael> fremy: I don't buy it. I think it's pointless. If you're able to dump memory you can literally do a JS script. The whole premise makes no sense. I see no reason to not use syntax. Browsers can impl css syntax and do what it says. I don't see why do something special because then you create edge cases.<br> <gsnedders> s/html replaces null with +fffd/html replaces null with +fffd in some cases/<br> <dael> fremy: I think premise of thread is not based on something real. I haven't seen anyone from security team say it's real. If no one from security says it's a problem we should fix I don't think we should make any change to algo. There's no strong indication of a problem. If we agree to make a change from security we need someone from security<br> <dael> florian: How do we handle this? If we say a browser has a known vulnerability on this how do they discuss it with us?<br> <dael> gsnedders: Member only<br> <dael> florian: Is that private enough?<br> <dael> liam: [missed]<br> <liam> [there's also a team-only list]<br> <dael> Rossen_: We can either postpone to F2F and discuss in person to see all the concerns and options. Or at least we can record the preference of the listed options as at least a proposed resoltuion<br> <dael> Rossen_: 1 drop entire ss 2 drop ss after null 3 drop encompassing selector around null 4 drop null during pre process<br> <dael> Rossen_: That's what's on the table. Only remaining question is do we want to resolve on any of those?<br> <dael> ??: Also option of no change<br> <dael> Rossen_: Yes<br> <dael> fantasai: I would say we've had a good discussion. List the options in the issue, request TAG review, give people time to think.<br> <dael> Rossen_: Exactly. That's why I wanted to repeat the options.<br> <dael> Rossen_: Doesn't sound like we'll resolve. Discussion worth capturing. Potentially with TAG assistance or at F2F we can resolve<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2757#issuecomment-400750621 using your GitHub account
Received on Wednesday, 27 June 2018 16:48:32 UTC