Bugzilla

(In reply to Daniel Veditz [:dveditz] from comment #16)
> It doesn't look like the Unicode folks considered it a "security issue"

To be fair, the reports to Unicode (including the one I filed before seeing this Bugzilla entry) weren't framed as security reports.

> Lots of the other historical changes to UTS#46 over the years resulted in different output.

I believe this case is unusual in its direction compared to previous changes (that either have caused previously intentionally matching output to intentionally become distinct or that have turned previously erroneous input into non-erroneous input into non-erroneous input).

> The problem is if an application assumes an ASCII-only domain (such as an `Origin:` header) doesn't need to be run through the process.

On the contrary, Hono has this issue, because it runs the Origin header through UTS 46 processing.

> A strong PRO for giving this a CVE is that it will feed into dependency-checking security tools and make many more people aware of the issue than just issuing an advisory/warning without a CVE.

Yeah. I think this should have a RustSec entry, since those feed into tooling.

> And then we see the same problem in the "Live URL Viewer" built on a completely different library.

Is it OK to add Domenic Denicola, who has done the most recent work on the `tr46` npm module, to the CC list of this bug?

Also, would it be OK for me to communicate to Deno developers that a RustSec entry about `idna` can be expected, and the most convincing avenue to exploit so far depends on Deno currently pinning an out-of-date version of `url`, so it would be good if they'd update the deps before a RustSec entry shows up?

> Chromium, on the other hand, seems to set  `IgnoreInvalidPunycode` set to `true` (based on behavior, haven't checked their code).

AFAICT, Chromium's behavior isn't explainable by the flags. Instead, Chromium has a preprocessing layer before passing input to the ICU4C UTS 46 implementation. I believe that Safari and Firefox are evidence that such a layer isn't need for Web compat. The layer in Chromium has the effect of adding non-conformance, and I would prefer Chromium to get rid of that layer in order to achieve interop and spec compliance.

> This is the kind of thing that might be best coordinated by CERT, if we think the consequences of this bug are severe enough to warrant that. Are they?

I think from what has been described so far it depends on whether TLDs and CAs have checks against names that do not conform with STD3 when viewed on the pre-IDNA ASCII level. (The names involved here would fail pre-IDNA STD3 validation due to the trailing hyphen.)

I don't have the time to find out if there exist TLDs that would allow registering `xn--example-` or CAs that would issue a certificate to such a name.

I don't want to exaggerate this issue without end-to-end proof of seriousness, but it does not seem particularly improbable that there's exist a TLD that didn't validate against a trailing hyphen and a CA that issued for names that exist in DNS. (We've previously seen GitHub, Glitch, and YouTube mint subdomain DNS entries that are prohibited by the IETF's hyphen rules but that are covered by wildcard certificates.)

>  If a particular browser isn't following those specs quite right then report that to the specific vendor. Adding Web Platform Tests (https://wpt.fyi) for edge cases will help make sure people don't miss that point in the future. In this case the biggest issue appeared to be in the Unicode UTS#46 spec.

WPT imports the UTS 46 test suite from the Unicode Consortium, so in this case WPT hasn't been effective at getting the Chromium devs to remove the code that adds non-conforming behaviors on top of ICU4C: https://wpt.fyi/results/url/IdnaTestV2.window.html?label=master&label=experimental&aligned&q=%2Furl%2FIdnaTestV2.window.html

(In reply to Daniel Veditz [:dveditz] from comment #16)
> It doesn't look like the Unicode folks considered it a "security issue"

To be fair, the reports to Unicode (including the one I filed before seeing this Bugzilla entry) weren't framed as security reports.

> Lots of the other historical changes to UTS#46 over the years resulted in different output.

I believe this case is unusual in its direction compared to previous changes (that either have caused previously intentionally matching output to intentionally become distinct or that have turned previously erroneous input into non-erroneous input).

> The problem is if an application assumes an ASCII-only domain (such as an `Origin:` header) doesn't need to be run through the process.

On the contrary, Hono has this issue, because it runs the Origin header through UTS 46 processing.

> A strong PRO for giving this a CVE is that it will feed into dependency-checking security tools and make many more people aware of the issue than just issuing an advisory/warning without a CVE.

Yeah. I think this should have a RustSec entry, since those feed into tooling.

> And then we see the same problem in the "Live URL Viewer" built on a completely different library.

Is it OK to add Domenic Denicola, who has done the most recent work on the `tr46` npm module, to the CC list of this bug?

Also, would it be OK for me to communicate to Deno developers that a RustSec entry about `idna` can be expected, and the most convincing avenue to exploit so far depends on Deno currently pinning an out-of-date version of `url`, so it would be good if they'd update the deps before a RustSec entry shows up?

> Chromium, on the other hand, seems to set  `IgnoreInvalidPunycode` set to `true` (based on behavior, haven't checked their code).

AFAICT, Chromium's behavior isn't explainable by the flags. Instead, Chromium has a preprocessing layer before passing input to the ICU4C UTS 46 implementation. I believe that Safari and Firefox are evidence that such a layer isn't need for Web compat. The layer in Chromium has the effect of adding non-conformance, and I would prefer Chromium to get rid of that layer in order to achieve interop and spec compliance.

> This is the kind of thing that might be best coordinated by CERT, if we think the consequences of this bug are severe enough to warrant that. Are they?

I think from what has been described so far it depends on whether TLDs and CAs have checks against names that do not conform with STD3 when viewed on the pre-IDNA ASCII level. (The names involved here would fail pre-IDNA STD3 validation due to the trailing hyphen.)

I don't have the time to find out if there exist TLDs that would allow registering `xn--example-` or CAs that would issue a certificate to such a name.

I don't want to exaggerate this issue without end-to-end proof of seriousness, but it does not seem particularly improbable that there's exist a TLD that didn't validate against a trailing hyphen and a CA that issued for names that exist in DNS. (We've previously seen GitHub, Glitch, and YouTube mint subdomain DNS entries that are prohibited by the IETF's hyphen rules but that are covered by wildcard certificates.)

>  If a particular browser isn't following those specs quite right then report that to the specific vendor. Adding Web Platform Tests (https://wpt.fyi) for edge cases will help make sure people don't miss that point in the future. In this case the biggest issue appeared to be in the Unicode UTS#46 spec.

WPT imports the UTS 46 test suite from the Unicode Consortium, so in this case WPT hasn't been effective at getting the Chromium devs to remove the code that adds non-conforming behaviors on top of ICU4C: https://wpt.fyi/results/url/IdnaTestV2.window.html?label=master&label=experimental&aligned&q=%2Furl%2FIdnaTestV2.window.html