subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <...@daniel.shahaf.name>
Subject Re: Different behaviour of storing plaintext passwords under Unix - svn log differes from svn co/up
Date Sun, 23 Nov 2014 00:18:02 GMT
Branko ─îibej wrote on Sat, Nov 22, 2014 at 08:38:29 +0100:
> There is a possible attack vector through that: Since Subversion was
> told to trust the stored certificate, one can imagine a situation where
> an attacker (a) subverts IP routing and/or DNS to redirect your
> connections to their own server, with a different certificate; (b)
> breaks in to your, and (c) every other, client machine to change their
> stored server certs. However, at least (c) unlikely.
> 
> OTOH, since "unlikely" is not the same as "can't happen", we should
> perhaps consider not storing the server cert, too, if plaintext password
> storage is disabled.
> 

Whether or not you store the cert simply doesn't matter if your attacker
controls the contents of ~/.subversion/auth/.  The way to deal with a
poisoned cache is to nuke it or disregard it.

For example, 'rm -rf ~/.subversion' or '--config-dir=$(mktemp -d)'.

Daniel

> P.S.: Compare the above scenario with the far more simple and likely one
> where the attacker breaks into your server and steals it wholesale,
> including the server's private key.

Mime
View raw message