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.
