info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Connection hijacking


From: Brian Smith
Subject: Connection hijacking
Date: Fri, 08 Mar 2002 17:47:51 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8+) Gecko/20020301

I am working on the below patch for Tony Hoyle's CVSNT 1.11.1.4. If the "mainline" CVS developers would like this integrated, please let me know and I will create a patch for "regular" CVS.

At the very least, if you feel that the changes below will not fix the problem described, please let me know so I can come up with a more secure fix. Similarly, if there is a better way to communicate the idea of "rootless stream modification" (see below) back to new clients without breaking older clients, I would like to know what it is. As far as I can tell, there is no mechanism in the protocol for the server to send preferences/requirements to the client.

Thank you,
Brian

-- BEGIN ORIGINAL MESSAGE --

In the CVS Client/Server protocol document, there is the following note about Gssapi-encrypt (and the other encryption requests)

Gssapi-encrypt: Note that this request does not fully prevent an attacker from hijacking the connection, in the sense that it does not prevent hijacking the connection between the initial authentication and the Gssapi-encrypt request.

My understanding is that, when using Kerberos as the GSSAPI implementation, the authentication information (between "BEGIN GSSAPI REQUEST" and "I LOVE YOU") is guarenteed (by Kerberos) to be legitimate. Similarly, All the information after Gssapi-encrypt is guarenteed (by Kerberos) to be legitamate. The only problem is that a malicious user could insert requests between the authentication and the Gssapi-encrypt request (or even prevent the Gssapi-encrypt message from ever being sent). These requests would be executed using the credentials of whoever authenticated the connection at the beginning, which is dangerous. Is this a correct summary of the problem? Are there other dangers?

Now, I am planning to fix this problem for :gserver: mode by doing the following (analogous changes would be made to other protocols as appropriate):
   1. I will make Gssapi-encrypt "rootless" (not require a preceding
      Root request). This is needed anyway protect any sensitive
      information that is encoded in the root directory's name.
   2. I will provide an option in the server to require that the first
      request after authentication be "Gssapi-encrypt"
      or "Gssapi-authenticate".

Obviously, current "Gssapi-encrypt" unfortunately is currently not considered a rootless command. So, I have to make the client send the "Root" request first for older and current servers, and Gssapi-encrypt/authenticate first for servers that have the rootless Gssapi-encrypt.

My thinking is that I will have the new server send back an extra valid request "Rootless-Stream-Modification" that the new client can check for, to see if the stream modification requests (Gssapi-encrypt, Kerberos-encrypt, Protocol-encrypt, Gzip-stream) are rootless on the current server. If so, it will send the Root request _after_ the stream modification requests; otherwise, it will send the Root request _before_ the stream modification requests.

What do you think?

- Brian




reply via email to

[Prev in Thread] Current Thread [Next in Thread]