On Thu, 4 Mar 2010, walt wrote: > I just saw this article about the "google hackers" exploiting weaknesses in > scms, > Perforce in particular: > > http://www.wired.com/threatlevel/2010/03/source-code-hacks/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+wired%2Findex+%28Wired%3A+Index+3+%28Top+Stories+2%29%29 > > I guess google didn't take Linus's advice to dump Perforce :) > > I can't tell from the article if Perforce is any worse than any other scm for > security holes, in fact it seems to imply that others haven't been tested in > the same way. > > Just curious if anyone here has any thoughts about how the article may or may > not have any relevance for git (git being the scm I use most, by far, which is > the reason I'm interested). I took a look at the white paper the article links to. I had to ignore a lot of the introductory sections (yes, the most secure system would be to prevent people from doing any work that might be stolen or released after it was corrupted), but I assume that the "findings" are the actually relevant part. Comparing git and Perforce here: - The Perforce server software for Windows installs to run as root. I'm not sure what the norm is for git central repositories on Windows, but it's probably better. I don't know if people actually run Perforce servers on Windows in practice, either. - Perforce has built-in authorization and authentication. By default, it allows unauthenticated people to create users without any specific authorization. It transmits passwords in cleartext in some cases. It discloses a lot of information about the authorization and authentication in force to arbitrary people, including users of the internal web site who do not have protocol access at all. It issues login tickets that last a long time. The authorization controls are not applied reliably to operations that modify the authorization and authentication information in some of the server software. The initial configuration with respect to access control is completely unrestrictive. Git does not have built-in authorization or authentication, so avoiding or making these mistakes is outside git's scope. - Perforce sends all of content over the network in cleartext. This is essentially true of git as well, but in order to get any sort of access control with git, you need to use some wrapping method, which will generally provide encryption as well. - Perforce stores, on the server, the location of the working directory on the client, and this is used by the client to place files. Git does not store this information at all. In general, they seem to have found numerous flaws due to the fact that Perforce includes security-related code while not being designed by security specialists. Git is designed not to include security-related code, and to have properly developed security code control access to it. It is possible to run Perforce in a configuration where access control is external to Perforce, but it's not easy or standard. On the other hand, I don't see any indication that the attack they were investigating used any of the problems they found, or any problems of a similar class. The actual attack seemed to involve a successful attack on the workstation of someone with legitimate priviledges, which the attackers then used. It's hard to say if any security measures on the part of the SCM could have any effect other than limiting the choice of the user to target. -Daniel *This .sig left intentionally blank* -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html