[Ffmpeg-devel] SVN challenge response authentication weaknesses

[Attila Kinali]

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.

 
> 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.
 
> 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.


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!
The only way to protect against this case are full reviews
of commits made to svn.



				Attila Kinali
-- 
??????????????