On Mon, May 20, 2024 at 8:29 AM Robert Haas <robertmh...@gmail.com> wrote: > It does occur to me that if some compression algorithm has a buffer > overrun bug, restricting its use until after authentication might > reduce the score of the resulting CVE, because now you have to be able > to authenticate to make an exploit work. Perhaps that's an argument > for imposing a restriction here, but it doesn't seem to be the > argument that you're making.
It wasn't my argument; Jacob B said above: > in general postgres servers are usually connected to by > clients that the server admin has some channel to talk to (after all > they somehow had to get access to log in to the server in the first > place) if they are doing something wasteful, given that a client can > do a lot worse things than enable aggressive compression by writing > bad queries. ...and my response was that, no, the proposal doesn't seem to be requiring that authentication take place before compression is done. (As evidenced by your email. :D) If the claim is that there are no security problems with letting unauthenticated clients force decompression, then I can try to poke holes in that; or if the claim is that we don't need to worry about that at all because we'll wait until after authentication, then I can poke holes in that too. My request is just that we choose one. > But if the client says in the startup message that it would like to > send and receive compressed data and the server is happy with that > request, I don't see why we need to postpone implementing that request > until after the authentication exchange is completed. I think that > will make the code more complicated and I don't see a security > benefit. I haven't implemented compression bombs before to know lots of details, but I think the general idea is to take up resources that are vastly disproportionate to the effort expended by the client. The systemic risk is then more or less multiplied by the number of intermediaries that need to do the decompression. Maybe all three of our algorithms are hardened against malicious compression techniques; that'd be great. But if we've never had a situation where a completely untrusted peer can hand a blob to the server and say "here, decompress this for me", maybe we'd better check? --Jacob
