1
0
mirror of https://github.com/postgres/postgres.git synced 2025-06-14 18:42:34 +03:00

Fix incautious handling of possibly-miscoded strings in client code.

An incorrectly-encoded multibyte character near the end of a string
could cause various processing loops to run past the string's
terminating NUL, with results ranging from no detectable issue to
a program crash, depending on what happens to be in the following
memory.

This isn't an issue in the server, because we take care to verify
the encoding of strings before doing any interesting processing
on them.  However, that lack of care leaked into client-side code
which shouldn't assume that anyone has validated the encoding of
its input.

Although this is certainly a bug worth fixing, the PG security team
elected not to regard it as a security issue, primarily because
any untrusted text should be sanitized by PQescapeLiteral or
the like before being incorporated into a SQL or psql command.
(If an app fails to do so, the same technique can be used to
cause SQL injection, with probably much more dire consequences
than a mere client-program crash.)  Those functions were already
made proof against this class of problem, cf CVE-2006-2313.

To fix, invent PQmblenBounded() which is like PQmblen() except it
won't return more than the number of bytes remaining in the string.
In HEAD we can make this a new libpq function, as PQmblen() is.
It seems imprudent to change libpq's API in stable branches though,
so in the back branches define PQmblenBounded as a macro in the files
that need it.  (Note that just changing PQmblen's behavior would not
be a good idea; notably, it would completely break the escaping
functions' defense against this exact problem.  So we just want a
version for those callers that don't have any better way of handling
this issue.)

Per private report from houjingyi.  Back-patch to all supported branches.
This commit is contained in:
Tom Lane
2021-06-07 14:15:25 -04:00
parent 68a6d8a870
commit 42f94f56bf
15 changed files with 68 additions and 33 deletions

View File

@ -740,7 +740,7 @@ json_lex_string(JsonLexContext *lex)
ch = (ch * 16) + (*s - 'A') + 10;
else
{
lex->token_terminator = s + pg_encoding_mblen(lex->input_encoding, s);
lex->token_terminator = s + pg_encoding_mblen_bounded(lex->input_encoding, s);
return JSON_UNICODE_ESCAPE_FORMAT;
}
}
@ -846,7 +846,7 @@ json_lex_string(JsonLexContext *lex)
default:
/* Not a valid string escape, so signal error. */
lex->token_start = s;
lex->token_terminator = s + pg_encoding_mblen(lex->input_encoding, s);
lex->token_terminator = s + pg_encoding_mblen_bounded(lex->input_encoding, s);
return JSON_ESCAPING_INVALID;
}
}
@ -860,7 +860,7 @@ json_lex_string(JsonLexContext *lex)
* shown it's not a performance win.
*/
lex->token_start = s;
lex->token_terminator = s + pg_encoding_mblen(lex->input_encoding, s);
lex->token_terminator = s + pg_encoding_mblen_bounded(lex->input_encoding, s);
return JSON_ESCAPING_INVALID;
}

View File

@ -1911,6 +1911,11 @@ const pg_wchar_tbl pg_wchar_table[] = {
/*
* Returns the byte length of a multibyte character.
*
* Caution: when dealing with text that is not certainly valid in the
* specified encoding, the result may exceed the actual remaining
* string length. Callers that are not prepared to deal with that
* should use pg_encoding_mblen_bounded() instead.
*/
int
pg_encoding_mblen(int encoding, const char *mbstr)
@ -1920,6 +1925,16 @@ pg_encoding_mblen(int encoding, const char *mbstr)
pg_wchar_table[PG_SQL_ASCII].mblen((const unsigned char *) mbstr));
}
/*
* Returns the byte length of a multibyte character; but not more than
* the distance to end of string.
*/
int
pg_encoding_mblen_bounded(int encoding, const char *mbstr)
{
return strnlen(mbstr, pg_encoding_mblen(encoding, mbstr));
}
/*
* Returns the display length of a multibyte character.
*/