On 7/31/24 14:03, Tom Lane wrote:
> Robert Haas <robertmhaas@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
