Comments by "" (@mina86) on "PwnFunction" channel.

The length function was working correctly. The other function just blindly trusted the data.
16
@sirsneakybeaky , C and C++ are vulnerable as well since Windows has no reliable way to escape arguments. This wasn’t a language issue, this was (and still is) DOS/Windows issue.
9
@angeldude101 0x27 is not a continuation byte so "\xC0\x27" is not a valid sequence regardless. For example, "\xCF\x27" would also be an invalid sequence even though 0xCF is a valid start of a two-byte sequence. 0xC0 is never a valid byte in UTF-8.
5
@PeterZaitcev I don't get what your saying. In particular what you mean by UTF-8 escape character. The problem was they the escape function assumed the input is valid UTF-8. The function which returned length of a UTF-8 code unit based on the first byte worked correctly.
2
@TheHanutaXD Those are two different parts of the code. In fact, completely separate processes. It's not unreasonable to accept invalid UTF-8 if errors in decoding are replaced with replacement characters. (Though it's possible the parser didn't even do that and just treated input as unibyte encoding. Still, even in that situation things would probably just work and the engine would deal with the corrupted string somehow). If escaping code validated the input or treated it as using unibyte encoding things would probably work.
1
@, the Unicode standard version is not the issue. The parser correctly handles UTF-8 encoded Unicode string and it doesn’t care about Unicode characters other than the handful it needs to understand. Issue is that part of the code assumed a valid UTF-8 encoding of a Unicode string but that was never verified.
1
@smorebytes , no, PostrgeSQL fucked up. Regardless of whether they followed best practices or not, PostgreSQL’s escaping function should handle escaping apostrophes. Something in the path should verify that they got a valid string or the escaping function should ignore UTF-8 and treat the string as single-byte.
1