On 2024-07-31 We 2:43 PM, Joe Conway wrote:
> 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 ]
First, thanks you very much, Robert for the analysis.
>>
>>> 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.
>
As I meant to say in my previous empty reply, I think your suggestions
make lots of sense.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
