I don't think this change was intended to block all malformed HTML. Mike?

I don't understand the exploit in POC1. Can you help me figure out what the risk is?

POC2 looks like it ought to be blocking the ping. If it's not, I agree that that's that's a bug in the mitigation.

Ah. Ping is special. :P It accepts a space-delimited series of URLs that are pinged in sequence. So, if you can inject on the same line as the interesting data, it will send the ping, followed by a number of same-origin pings. Hrm. Should be straightforward to work around, but the spec will end up being ugly. :(

hello,thanks for replay
for POC1
as you said in  issue 680970  
<img src='` eats the page until the next `'`
here comes the same problem:
<iframe name=' eats the page until the next `'` ,too.
if an attacker inject the next href=attacker.com
then the user data is stolen by attacker.
so it's maybe not a bug in this mitigation , but shows a similar problem that this mitigation could not solve

for POC2
the POC2 shows it could not block ping request
so it's a bug in this mitigation

or, in an word, there is need for an attacker to stolen the data in iframe src , he could simply use iframe name to eat them , and use a valid iframe src to send those data

Put a patch up at https://chromium-review.googlesource.com/c/chromium/src/+/672845 for POC2.

I agree that POC1 is a potential issue. But it's not one that the existing mitigation is meant to solve. I'll mark this as blocking the wrapper bug 680969 so we can come back to it once we feel like we have a handle on direct leakage.

Does any of the markup leak cross-domain or over the network? That'd be my first concern regarding severity.

This could also be part of a technique to induce DOM XSS, perhaps? But that would seem to party depend on the behavior of the web contents, and not just Chrome.

Calling it Severity-Low for the time being.

yes, but this issue is bypass a existing mitigation.
the problem itself do not need to peroform a XSS attack (this is not script to be eval),instead,it just need to insert an element.
like a CSP-Bypass I reported before  issue 747847 ,it was marked as medium. (CSP bypass need a XSS first)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/70feb2c848996e0d09ba19502fc0fe02f8754e5f

commit 70feb2c848996e0d09ba19502fc0fe02f8754e5f
Author: Mike West <mkwst@chromium.org>
Date: Wed Sep 20 09:41:16 2017

Block `ping` attributes containing `\n` and `<`.

We're blocking requests to URLs that containin both `\n` and `<`; given
`ping`'s space-delimited semantics, to apply the same mitigation we'll
need to scan the initial attribute value, rather than relying on each
URL found after splitting the attribute value on whitespace.

Bug:  766592 
Change-Id: Ibdd52ee63a37ef4e1998cf10dc860648cba929c5
Reviewed-on: https://chromium-review.googlesource.com/672845
Commit-Queue: Mike West <mkwst@chromium.org>
Reviewed-by: Eric Lawrence <elawrence@chromium.org>
Cr-Commit-Position: refs/heads/master@{#503095}
[add] https://crrev.com/70feb2c848996e0d09ba19502fc0fe02f8754e5f/third_party/WebKit/LayoutTests/http/tests/security/dangling-markup/a-ping-expected.txt
[add] https://crrev.com/70feb2c848996e0d09ba19502fc0fe02f8754e5f/third_party/WebKit/LayoutTests/http/tests/security/dangling-markup/a-ping.html
[modify] https://crrev.com/70feb2c848996e0d09ba19502fc0fe02f8754e5f/third_party/WebKit/Source/core/html/HTMLAnchorElement.cpp

Based on #10, it looks like this has been fixed.

I'm afraid the VRP panel declined to reward for this bug. Thanks for the report!

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot