[Ffmpeg-devel] SVN challenge response authentication weaknesses

[Rich Felker]

On Sat, May 27, 2006 at 01:10:58PM +0200, Attila Kinali wrote:
> Moin,
> 
> On Sat, 27 May 2006 12:57:35 +0200
> Michael Niedermayer <michaelni at gmx.at> wrote:
> 
> > 1. passwords are stored in plaintext on the server this means everyone
> > who has root or can get his hands on the servers harddisk knows your password
> > -> dont reuse any important password
> 
> This is the biggest problem. If anyone makes it onto natsuki and
> can perform a local root exploit, then he can get all passwords.
> But on the other hand, if some gets root on natsuki, we are screwed
> anyways.

I don't consider this a problem at all. Any "vuln" by which someone
with more-privileged status (root) gets less-privileged information
(passwords) is not a vuln at all.

> > 2. someone who can listen to network traffic can get salt + md5 pairs
> >    with which he can perform a offline bruteforce attack (never use weak
> >    passwords)
> 
> This is the second biggest thread. Mostly because a damn lot of people
> use wireless these days. But then, there is no reason to use a weak
> password anyways as this password is handled by svn and does not need
> to be remembered by a human.

Hopefully strong passwords are "strong enough". How strong is strong
enough?

> > 3. someone who can listen to network traffic and can inject packets
> >    can hijack your connection and possibly inject some changes iam not
> >    sure how easy this is in practice the problem is the connection will
> >    get reset unless the client is kept from participating (by DOS or so)
> > 
> > 4. someone who can listen and modify network traffic will trivially
> >    be able to do anything he wants after authentication
> 
> TCP hijacking is known for a very long time. But i've not heard
> of any case that someone performed it successfully outside a test
> enviroment. The main difficulty here is that you need to be able
> to be in a MAC domain where ALL packets of this connection pass
> trough. Unless you sit on a wireless network or at one of the
> transit ISPs, this wont be easy.

I'm not sure whether this is feasible or not. I brought it up back
when non-ssl SVN was first proposed. IMO this is the only actual
serious security issue that merits looking into.

> But there is one thread that is more serious than any of these
> above and a lot more likely to happen: If someone is able to
> overtake one of the machines of a developer, he can simply
> extract the svn password from the config files. Unlike with
> ssh-keys those files are not encrypted!

No one kept their rsa keys encrypted anyway. If they did they'd have
to enter a password each time they did anything with cvs, even
read-only ops..

> The only way to protect against this case are full reviews
> of commits made to svn.

Yes, and demanding the developers not be incompetent about security..

Rich