[cvsnt] SSPI Security (was "Setting up shared repositories")
Michael.Wojcik at microfocus.com
Wed Aug 22 15:46:02 BST 2007
> From: cvsnt-bounces at cvsnt.org
> [mailto:cvsnt-bounces at cvsnt.org] On Behalf Of Arthur Barrett
> Sent: Sunday, 19 August, 2007 22:37
> To: cvsnt at cvsnt.org
> > The records are stored, by default, in the file $HOME/.cvspass
> > (Unix) or the Registry (NT).
> Yes - the same potential problem is there with SSH and this
> is solved with cvsagent.
For sufficiently small values of "solved", I suppose.
cvsagent listens on a TCP socket for password queries and responds with
cached passwords. That's hardly inaccessible to an attacker.
In fact, a quick glance at the cvsagent source
(cvsagent/win32/ListenServer.cpp) shows that it calls getaddrinfo to get
a list of local addresses and then binds a socket to each interface.
That should be unnecessary (why doesn't it just bind one socket to
INADDR_ANY?) and it means that the agent is listening on all external
interfaces, modulo firewalls. Does the agent actually need to listen on
anything other than the loopback interface? That would at least limit
its exposure to local attackers.
cvsagent appears to just trade one form of password exposure for
another. I admit I have not actually created a POC attack yet, but I
don't see anything in the sources to complicate one.
Password caching is widely recognized as a hard problem, and CVSNT does
at least provide a couple of different mechanisms for it. But under a
variety of reasonable threat models, its password caching isn't secure.
I can't offhand think of an easy way to improve it. The CVS
command-line client is a transient process running with normal
privileges; it has no way of securely authenticating itself to a
password cache without input from the user, and if the user has to enter
a secret, it might as well be the password for the server.
If encryption were added to the cvsagent protocol, agents and clients
could keep a shared secret in a side file (or registry key, etc) with
restrictive permissions, so that attackers running under different
accounts couldn't extract plaintext passwords from the cache. That
would require agent and client to run on the same system, and some
thought would have to go into managing the secrets and the ACLs that
protect them. And the passwords would still be vulnerable to an
attacker who could run processes as the local user (via trojans, social
engineering, etc). But it'd prune some branches off the attack tree.
And cvsagent should really bind only to the loopback interface, unless
there's a good reason to bind to external interfaces - and even then it
should be a configurable option and off by default.
Principal Software Systems Developer, Micro Focus
More information about the cvsnt