On 7/31/24 14:03, Tom Lane wrote:
Robert Haas <robertmh...@gmail.com> writes:
If there are some inputs that cause upper() and lower() to fail and
others that do not, the functions aren't leakproof, because an
attacker can extract information about values that they can't see by
feeding those values into these functions and seeing whether they get
a failure or not.
[ rather exhaustive analysis redacted ]
So in summary, I think upper() is ... pretty close to leakproof. But
if ICU sometimes fails on certain strings, then it isn't. And if the
multi-byte libc path can be made to fail reliably either with really
long strings or with certain choices of the LC_CTYPE locale, then it
isn't.
The problem here is that marking these functions leakproof is a
promise about a *whole bunch* of code, much of it not under our
control; worse, there's no reason to think all that code is stable.
A large fraction of it didn't even exist a few versions ago.
Even if we could convince ourselves that the possible issues Robert
mentions aren't real at the moment, I think marking these leakproof
is mighty risky. It's unlikely we'd remember to revisit the marking
the next time someone drops a bunch of new code in here.
I still maintain that there is a whole host of users that would accept
the risk of side channel attacks via existence of an error or not, if
they could only be sure nothing sensitive leaks directly into the logs
or to the clients. We should give them that choice.
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
