Re: Question about scm security holes

Hi,

On Thu, 4 Mar 2010, Avery Pennarun wrote:

I disagree that stealing the code in this particular case is uninteresting. You know that there are billions in the business how to manipulate Google's search results. If you can see how Google rates websites, you can prepare your xxx sites for it, and nobody would be able to know, let alone prove, that you "reverse-engineered" the system.

That is not true in all cases.

If you're talking about a workflow as git.git has it, you're right, there is a maintainer, and a refused push would ring all kinds of alarm bells there.

Except, of course, when the maintainer happens to work on different machines, and is likely to pull from her main repository quite often. Think "get something compiling on an obscure platform while developing something different on your main computer, then do a criss-cross merge at the end".

It gets even much, much worse in the common setup of companies: a central repository. (The two main reasons why a central repository is used are: tradition (we did it with Subversion, too), and bottleneck problems: a single maintainer reviewing all changes is often deemed too expensive and slow.)

So in the regular case, it is _very_ easy to sneak in a code-change unnoticedly.

The trick now is to craft the commit in such a manner that it will not be noticed retro-actively. This is a simple case of social engineering: you have to imitate the style of the committer/author you are impersonating. The commit message must look like the usual ones (typos, preferred words, grammar, length of paragraphs, comprehensibility, etc)

Likewise, the code has to be analyzed for style, and obviously for most likely targets of a backdoor (both in terms of "it is a perfect spot for a backdoor" and "it is not uncommon for the author to touch that part of the code").

Crafting the commit message and the backdoor needs some time, and it needs to be done _after_ succeeding with the break-in, as you can only then start analyzing style (and most likely workflow -- whether there is a single maintainer or whether everybody pushes to a single repository).

The most likely route, therefore is to have _two_ break-ins. One for reconaissance, the second for the actual change.

Conclusion: there are no technical reasons why Git should be better than 
Perforce when it comes to a break-in.

Short version: it's a social problem, so it needs a social solution.

Ciao, Dscho

P.S.: Sorry for the overly long mail. I did not have time to make it short.