[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fri, 08 Mar 2002 17:47:51 -0600
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 184.108.40.206. 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.
-- 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
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"
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
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?
- Abandoned CVS server processes, Dan Peterson, 2002/03/03
- Re: Abandoned CVS server processes, Stewart Brodie, 2002/03/04
- Re: Abandoned CVS server processes, Larry Jones, 2002/03/04
- Re: Abandoned CVS server processes, Dan Peterson, 2002/03/06
- Re: Abandoned CVS server processes, Larry Jones, 2002/03/07
- Re: Abandoned CVS server processes, Dan Peterson, 2002/03/07
- CVS "Official" Releases, Dan Peterson, 2002/03/08
- Connection hijacking,
Brian Smith <=
- Re: CVS "Official" Releases, Larry Jones, 2002/03/09
- Re: Abandoned CVS server processes, David Fuller, 2002/03/08
- Re: Abandoned CVS server processes, Larry Jones, 2002/03/08
- Re: Abandoned CVS server processes, Dan Peterson, 2002/03/14
- Re: Abandoned CVS server processes, Larry Jones, 2002/03/15