Re: Different behaviour of storing plaintext passwords under Unix - svn log differes from svn co/up

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.
Received on 2014-11-23 01:20:45 CET