1

I'm reading a report on HackerOne https://hackerone.com/reports/52042. An input filter was bypassed by sending %E5%98%8A that was then parsed as 0x0A character (new line).

The %E5%98%8A sequence corresponds to U+560A Unicode code point.

I read about UTF-8 overlong encodings but it doesn't seem to be the case here.

So I wonder how does this work. Isn't U+560A valid code point?

Improve this question
3
  • 5
    I think you've missed an important part of the description: "...as the the page will try to convert them back to the original Unicode form and extract the last byte." . Thus, the problem is that the specific web application will just treat U+560A as 0A, maybe while blindly casting every character down to ASCII.
    – Steffen Ullrich
    Jan 30, 2019 at 20:22
  • @SteffenUllrich I'm not sure but I think it must be something special about U+560A. The author of report didn't say that any codepoint of type U+xx0A would do.
    – Alex Velickiy
    Jan 31, 2019 at 13:53
  • You cannot conclude from the absense of the explicit information that others U+xx0A would also do it that the 56 in U+560A is somehow special. The author of the report also didn't explicitly say that other code points of type U+xx0A would not work.
    – Steffen Ullrich
    Jan 31, 2019 at 14:17

1 Answer 1

Reset to default
1

On that report it seems that they were taking the url parameter reported_tweet_id and copying it into a HTTP header (likely inside a Location, as part of a redirect) after a faulty transformation.

As Steffen Ullrich noted, they somehow took the unicode character and left only the last byte, which allowed filedescriptor to bypass the check for a \x0a.

At the end of the report, the reporter asked for the root cause, which twitter declined to share, so we are left wondering. It's quite strange, since on the one hand, they properly decoded the unicode character (to utf-16, perhaps), while on the other, they completely lost the higher 16 bits. Maybe a faulty unicode library that after a unicode conversion, blindly assumed the result would be iso-8859-1 and copied just the lower byte. Note that they were injected into HTTP headers, which don't support utf-8 (or unicode, any non-ASCII character should be urlencoded there), which is what allowed the CRLF injection on this bug of extra HTTP headers and html body.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .