Horton

Re: SCRAM with channel binding downgrade attack

Heikki Linnakangas <hlinnaka@iki.fi>

View thread View on postgr.es
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Michael Paquier <michael@paquier.xyz>
Cc: Postgres hackers <pgsql-hackers@postgresql.org>, Robert Haas <robertmhaas@gmail.com>, Magnus Hagander <magnus@hagander.net>, Stephen Frost <sfrost@snowman.net>, Bruce Momjian <bruce@momjian.us>
Date: 2018-06-06T20:53:06Z
Lists: pgsql-hackers 
On 06/06/18 23:31, Peter Eisentraut wrote:
> On 6/6/18 16:26, Heikki Linnakangas wrote:
>> On 06/06/18 23:20, Peter Eisentraut wrote:
>>> Aren't we attacking this on the wrong level?  We are here attempting to
>>> prevent a SCRAM-SHA-256-PLUS -> SCRAM-SHA-256 downgrade, but we are not
>>> preventing a SCRAM-SHA-256-PLUS -> anything-else downgrade.
>>
>> The latest patch does prevent that, too. That was my complaint at
>> https://www.postgresql.org/message-id/030284cc-d1d6-ce88-b677-a814f61c1880%40iki.fi,
>> but it's been fixed now. (Or if you see a case where it still isn't,
>> that's a bug.)
> 
> OK, that would do, but we don't do anything about a SCRAM-SHA-256 ->
> anything-else downgrade.  Instead of tying this to the channel binding,
> should we tie it to the authentication type?

That would certainly be good. We've always had that problem, even with 
md5 -> plaintext password downgrade, and it would be nice to fix it. 
It's quite late in the release cycle already, do you think we should 
address that now? I could go either way..

What should the option look like? Perhaps something like:

allowed_authentication_methods=md5,SCRAM-SHA-256,SCRAM-SHA-256-PLUS

That would not be very user-friendly, though.

- Heikki

Commits

  1. doc: update PG 11 release notes

  2. Fix misspelled pg_trgm contrib name in PostgreSQL 11 release notes

  3. Doc: clarify release note text about v11's new window function features.

  4. Improve wording of release notes item

  5. Fix typos in release notes

  6. Doc: preliminary list of PG11 major features.

  7. Make numeric power() handle NaNs according to the modern POSIX spec.

  8. Various improvements of skipping index scan during vacuum technics

  9. Revert back-branch changes in power()'s behavior for NaN inputs.

  10. Avoid wrong results for power() with NaN input on more platforms.

  11. Avoid wrong results for power() with NaN input on some platforms.

  12. Skip full index scan during cleanup of B-tree indexes when possible

  13. Rewrite the code that applies scan/join targets to paths.

  14. Postpone generate_gather_paths for topmost scan/join rel.

  15. Add casts from jsonb

  16. Make plpgsql use its DTYPE_REC code paths for composite-type variables.

  17. Don't allow VACUUM VERBOSE ANALYZE VERBOSE.

  18. Pass InitPlan values to workers via Gather (Merge).

  19. Account for the effect of lossy pages when costing bitmap scans.

  20. Allow no-op GiST support functions to be omitted.

  21. Rearm statement_timeout after each executed query.

  22. Push limit through subqueries to underlying sort, where possible.