[I originally sent this to Tony Hoyle, and then to info-cvs. Somebody
suggested I would get feedback if I posted it to [EMAIL PROTECTED], so I'm
sending it here too. - Brian]
I am working on the below bug fix for Tony Hoyle's CVSNT 1.11.1.4. A
similar problem exists with the regular CVS. If you would like to
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
_______________________________________________
Bug-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-cvs
