overreacting (was: Re: [MPlayer-dev-eng] uau - svn account removal)

[Uoti Urpala]

On Mon, 2007-02-26 at 03:19 +0100, Michael Niedermayer wrote:
> > You're seriously using the chance that I might intentionally add
> > vulnerabilities as a reason?
> 
> OF COURSE NOT you but its possible that someone else tries possibly
> with a cracked account ...
> its a not so unlikely scenario, getting a svn account is easy ...
> 
> and mallicious code which is executed every time is way more effective
> than some buffer overflow which is dependant various other factors like
> gcc, and kernel and of course a video file which exploits it ...

So you're talking about the case where someone hacks the account of a
person with svn access and commits code which directly does malicious
things (and so needs to contain a "payload" and is thus likely harder to
hide than a subtle vulnerability)?

If the commit is done entirely by the attacker then I think making the
commit large to "hide" the payload is hard to make work for long. First
they'd need to be able to make a large commit that the account owner
could make and that is not obvious nonsense (I think this part would be
quite hard). Afterward the breach would be obvious at least to the
account owner if he saw it, and it would be odd if there was no
communication related to a large change either before or after the
commit (or the attacker would need to impersonate the account owner).
Overall I think making a smallish commit that doesn't attract much
attention would have a better chance of succeeding (hope that nobody
happens to pay much attention to it).

If the attacker tries to get the malicious code in by modifying a real
commit being done by the account owner then large commits (or equally
series of commits, breaking down the patches doesn't help much here) are
better. Still intentional commits large enough to hide something just by
hoping that someone otherwise interested doesn't have time to read it
fully are rare, especially if the attacker just manages to crack a
"random" developer.

Even a not-particularly-subtle exploit would survive for some time - at
least until someone would read the commit log mail with some care,
possibly longer if the person reading it would be unable to restore svn
to a safe state with access equal to the attacker and would need to get
in contact with admins.