Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
> 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 cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook > > > 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. -- Michael Wojcik Principal Software Systems Developer, Micro Focus