Greetings, * Jacob Champion (jchamp...@timescale.com) wrote: > On Thu, Jul 7, 2022 at 4:24 PM Jacob Champion <jchamp...@timescale.com> wrote: > > So my question is this: does substituting my credentials for the admin's > > credentials let me weaken or break the transport encryption on the > > backend connection, and grab the password that I'm not supposed to have > > access to as a front-end client? > > With some further research: yes, it does. > > If a DBA is using a GSS encrypted tunnel to communicate to a foreign > server, accepting delegation by default means that clients will be > able to break that backend encryption at will, because the keys in use > will be under their control.
This is coming across as if it's a surprise of some kind when it certainly isn't.. If the delegated credentials are being used to authenticate and establish the connection from that backend to another system then, yes, naturally that means that the keys provided are coming from the client and the client knows them. The idea of arranging to have an admin's credentials used to authenticate to another system where the backend is actually controlled by a non-admin user is, in fact, the issue in what is being outlined above as that's clearly a situation where the user's connection is being elevated to an admin level. That's also something that we try to avoid having happen because it's not really a good idea, which is why we require a password today for the connection to be established (postgres_fdw/connection.c: Non-superuser cannot connect if the server does not request a password. ). Consider that, in general, the user could also simply directly connect to the other system themselves instead of having a PG backend make that connection for them- the point in doing it from PG would be to avoid having to pass all the data back through the client's system. Consider SSH instead of PG. What you're pointing out, accurately, is that if an admin were to install their keys into a user's .ssh directory unencrypted and then the user logged into the system, they'd then be able to SSH to another system with the admin's credentials and then they'd need the admin's credentials to decrypt the traffic, but that if, instead, the user brings their own credentials then they could potentially decrypt the connection between the systems. Is that really the issue here? Doesn't seem like that's where the concern should be in this scenario. > > Maybe there's some ephemeral exchange going on that makes it too hard to > > attack in practice, or some other mitigations. > > There is no forward secrecy, ephemeral exchange, etc. to mitigate this [1]: > > The Kerberos protocol in its basic form does not provide perfect > forward secrecy for communications. If traffic has been recorded by > an eavesdropper, then messages encrypted using the KRB_PRIV message, > or messages encrypted using application-specific encryption under > keys exchanged using Kerberos can be decrypted if the user's, > application server's, or KDC's key is subsequently discovered. > > So the client can decrypt backend communications that make use of its > delegated key material. (This also means that gssencmode is a lot > weaker than I expected.) The backend wouldn't be able to establish the connection in the first place without those delegated credentials. > > I'm trying to avoid writing Wireshark dissector > > code, but maybe that'd be useful either way... > > I did end up filling out the existing PGSQL dissector so that it could > decrypt GSSAPI exchanges (with the use of a keytab, that is). If you'd > like to give it a try, the patch, based on Wireshark 3.7.1, is > attached. Note the GPLv2 license. It isn't correct code yet, because I > didn't understand how packet reassembly worked in Wireshark when I > started writing the code, so really large GSSAPI messages that are > split across multiple TCP packets will confuse the dissector. But it's > enough to prove the concept. > > To see this in action, set up an FDW connection that uses gssencmode > (so the server in the middle will need its own Kerberos credentials). The server in the middle should *not* be using its own Kerberos credentials to establish the connection to the other system- that's elevating the credentials used for that connection and is something that should be prevented for non-superusers already (see above). We do allow that when a superuser is involved because they are considered to essentially have OS-level privileges and therefore could see those credentials anyway, but that's not the case for non-superusers. Thanks, Stephen
signature.asc
Description: PGP signature
