Tobias Ringstrom <tobias@ringstrom.mine.nu> writes:
> Joe Orton wrote:
> > e.g. I log in to IRC and someone persuades me to checkout some
> > funky new code from https://funkycode.org/repos/, and I naively
> > hit the "accept permanently" button on my SVN client when prompted
> > for this new cert.
> > To arrange the MITM, the attacker had placed a subjectAltName
> > extension on the funkycode.org cert naming svn.webdav.org, and
> > then subverts the DNS for svn.webdav.org to point to a server
> > hosting trojaned neon code. Then when I "svn co" to make a new
> > neon release, I get trojaned code without knowing it.
>
> Fortunately this attack does not work with the current implementation
> becuase we do not consider any alternative hostnames for non-CA
> trusted certs. If you choose to permanently trust the cert above, you
> will get a question when you connect to svn.webdav.org because the
> hostname will not match the DN. You can only temporarily accept that
> error.
Hold on a second... let me summarize what I see happening in the code.
The subversion auth system caches credentials on disk based on a
'realmstring' key. The caller of the auth system defines custom
realmstring formats for each type of credential.
In the case of http 'basic' auth, ra_dav creates a realmstring based
on the host, port, and http-realm header, something like:
"<http://svn.foo.net:8080> Frank's repository"
We did this, of course, to help prevent spoofing.
In the case of our new server-cert handling, ra_dav is simply using
the entire ascii-ized server-cert as a realmstring key. As Joe points
out, this is pretty darn spoofable.
But I see a simple remedy here:
1. mimic what we're doing in the http-basic-auth scenario: build a
realmstring key based on {host, port, cert-fingerprint}.
2. beyond that, the auth-provider which actually fetches the cache
from disk (server_ssl_file_first_credentials()) should *compare*
the cache contents with the incoming cert to make sure they're
the same cert... which we're not doing!
Am I making sense?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 23 16:57:15 2003