Main GNU source repository server compromised • Hacker News Board

Re: Main GNU source repository server compromised

#41

Post by JoachimSchipper » Wed, Dec 01, 2010, 2:17 PM UTC

sandGorgon wrote: post #36

JoachimSchipper wrote: post #35

Earlier quoted context omitted.

I don't think DVCS would have helped in any way. It's not the repository server itself that was compromised, AFAIK, but "only" the web interface. This allows password recovery and thus allows people to e.g. make malicious commits from a trusted account, but that would be no less true if there were a DVCS under it all.

agreed - but my question still stands: Take SVN for instance - if I managed to hack into a SVN server, can I change the source code (under SVN management) in a way that would be undetectable ? Repeat the same question for git, mercurial and CVS.

For CVS and svn: you can hide it until someone actually looks at the relevant code. For git: not really (as long as you assume you change only the data - clever attackers could serve one repository to the developers and another to .mil/the rest of the world/...) I don't know about mercurial, but I'd wager it's the same as git in this respect.

In either case, an attacker could add arbitrary commits, and the system administrator would roll back to the last known-good backup as soon as the compromise was detected. I don't think DVCSes help much here.

Re: Main GNU source repository server compromised

#42

Post by Dylan16807 » Wed, Dec 01, 2010, 6:40 PM UTC

tptacek wrote: post #30

btilly wrote: post #29

Earlier quoted context omitted.

What is the full story? It seems to me that two tricks nail it. First use parametrized queries. And secondly if you have information you need to send/receive from the client that isn't easily parametrized, have a limited list of possible things that can be accepted back, which is checked in code while building the query. If you're doing those two things, I don't see how much work it is to avoid SQLI. Furthermore if y…

There's almost nothing wrong with your second "trick" (when we write recommendations, we usually suggest people never allow users to directly write syntax, and that they structure their app so that the parameters the user sees couldn't possibly land in SQL; use "1" for "ASC" and "0" for "DESC", etc). But it's not nearly as powerful a statement to say "use parameterized queries and then do everything else right" as it…

How about "only pass user-sourced data in parameters"? So anything that isn't a parameter is coming from the app, possibly as a response to user data, but not actually from user data. This statement seems just as powerful as the original. Anything misleading about it? Somewhere you can't use parameters and can't simply use app-supplied query pieces?

Re: Main GNU source repository server compromised

#43

Post by linuxaddict » Wed, Dec 01, 2010, 6:46 PM UTC

technomancy wrote: post #23

linuxaddict wrote: post #11

I thought more eyes on the source means that OSS is impenetrable. Guess not.

Nobody really cares about helping out with Savannah. On the emacs-devel mailing list every time Savannah is mentioned, it's in the context of "Yeah, we would like to do that but lack the manpower. Any volunteers?" followed by crickets.

That is no excuse for the software getting hacked. It is poorly developed, and that is the bottom line. If no one is working on it, it should be turned off, now it is just a flawed, insecure tool thats insecurity will be used against OSS.

Stop making excuses, and start fixing the sources.

Re: Main GNU source repository server compromised

#44

Post by tptacek » Wed, Dec 01, 2010, 6:47 PM UTC

Dylan16807 wrote: post #42

tptacek wrote: post #30

Earlier quoted context omitted.

There's almost nothing wrong with your second "trick" (when we write recommendations, we usually suggest people never allow users to directly write syntax, and that they structure their app so that the parameters the user sees couldn't possibly land in SQL; use "1" for "ASC" and "0" for "DESC", etc). But it's not nearly as powerful a statement to say "use parameterized queries and then do everything else right" as it…

How about "only pass user-sourced data in parameters"? So anything that isn't a parameter is coming from the app, possibly as a response to user data, but not actually from user data. This statement seems just as powerful as the original. Anything misleading about it? Somewhere you can't use parameters and can't simply use app-supplied query pieces?

You see how we're converging on "just use proper input validation", which is the all-time least useful piece of advice in software security?

Re: Main GNU source repository server compromised

#45

Post by Dylan16807 » Thu, Dec 02, 2010, 4:04 AM UTC

tptacek wrote: post #44

Dylan16807 wrote: post #42

Earlier quoted context omitted.

How about "only pass user-sourced data in parameters"? So anything that isn't a parameter is coming from the app, possibly as a response to user data, but not actually from user data. This statement seems just as powerful as the original. Anything misleading about it? Somewhere you can't use parameters and can't simply use app-supplied query pieces?

You see how we're converging on "just use proper input validation", which is the all-time least useful piece of advice in software security?

Because input validation is hard to do. A rule to not pass input EVER (outside of parameters), even in a supposedly validated form, is something different.

Re: Main GNU source repository server compromised

#46

Post by sandGorgon » Thu, Dec 02, 2010, 4:40 AM UTC

JoachimSchipper wrote: post #41

sandGorgon wrote: post #36

Earlier quoted context omitted.

agreed - but my question still stands: Take SVN for instance - if I managed to hack into a SVN server, can I change the source code (under SVN management) in a way that would be undetectable ? Repeat the same question for git, mercurial and CVS.

For CVS and svn: you can hide it until someone actually looks at the relevant code. For git: not really (as long as you assume you change only the data - clever attackers could serve one repository to the developers and another to .mil/the rest of the world/...) I don't know about mercurial, but I'd wager it's the same as git in this respect. In either case, an attacker could add arbitrary commits, and the system adm…

For CVS and svn: you can hide it until someone actually looks at the relevant code. For git: not really

I don't think DVCSes help much here.

Those statements sound contradictory. Let me try to understand - the distributed aspects of DVCSes would not have helped here. But the incidental fact of checksums in DVCSes (maybe necessitated by the nature of "distributed") does help. Right ?

Re: Main GNU source repository server compromised

#47

Post by JoachimSchipper » Thu, Dec 02, 2010, 8:16 AM UTC

sandGorgon wrote: post #46

JoachimSchipper wrote: post #41

Earlier quoted context omitted.

For CVS and svn: you can hide it until someone actually looks at the relevant code. For git: not really (as long as you assume you change only the data - clever attackers could serve one repository to the developers and another to .mil/the rest of the world/...) I don't know about mercurial, but I'd wager it's the same as git in this respect. In either case, an attacker could add arbitrary commits, and the system adm…

For CVS and svn: you can hide it until someone actually looks at the relevant code. For git: not really I don't think DVCSes help much here. Those statements sound contradictory. Let me try to understand - the distributed aspects of DVCSes would not have helped here. But the incidental fact of checksums in DVCSes (maybe necessitated by the nature of "distributed") does help. Right ?

Not all that much. If I hack your SVN repository, I put something like "if ($password == "1337h4xx0r") $admin = 1" into an old revision and hope you don't notice it when inspecting code. If I hack your git repository, I make a commit with text "spelling fix: invole -> involve" and slip in something like the above. Yes, it's a bit easier to detect, but not all that much - most such breaches seem to be found by system administrators before the developers notice them. (The kernel.org source code breach was detected because some mirror failed to line up with the main repository, for instance)

Of course, a smart hacker would do something less obvious. See the obfuscated C contest for inspiration.

And again, this assumes that I do not have any other access. In reality, I could change your $PATH to invoke a trojaned git binary, or somesuch.