2

Just an open question to the security community at large because... well... the phpMyAdmin thing has made me more paranoid than usual...

Specifically, I'm thinking about Kali Linux (ex-BackTrack). There are a lot of different (awesome) tools that go into Kali, many of which are open source. Obviously, the people actually developing Kali can't fully audit everything that goes in.

Does anyone? I know the 'many eyes' argument of open source. I've heard it many, many times. But there doesn't seem to be a great deal of organization.

So, people on here...

  • What are the well-organized projects for looking through open-source repositories?
  • Are any of the people on here involved with them?
  • Do they have enough momentum to realistically outpace people who might try to put malware into root-privilege utilities?

edit: I am aware of this question. Still, the fact that no one's been found to abuse something yet isn't compelling enough evidence it can't be abused. Also aware that packages get reviewed before they get put into the update repositories. Again, I'm curious about how much the developers can realistically review to both be up-to-date and safe.

Community
  • 1
root
  • 1,547
  • 3
  • 12
  • 20
  • 2
    It would seem to me that the very people who use Backtrack or Kali are the people most likely to detect that their machine started behaving maliciously after using it, for instance by having egress logging on their network firewall. If *I* were trying to sneak malicious code into an open source project, I would target something else. – Ladadadada Apr 02 '13 at 10:43
  • A valid point. It just occurred to me that, though it would be dangerous and inadvisable to try, that hasn't stopped people writing malware in the past. Someone could still try sneaking a backdoor in an obscure package. Not necessarily one that actively phoned home, but as an insurance policy if they thought someone else using that set of tools was likely to attack them. Your comment does assuage my unreasonable paranoia significantly, though. Thank you. – root Apr 02 '13 at 11:06
  • 1
    As a side note: Maltego Casefile (Community Edition) does try to call home for updates. @root, if you have paranoia it doesn't mean they are not out to get you. – Deer Hunter Apr 02 '13 at 11:13
  • This question has been covered several times on IT Security. It's very likely to draw opinion-driven answers with no actual reference. – Adi Apr 02 '13 at 11:52
  • @Adnan So... There really *aren't* any large open source auditing projects? If government agencies use this stuff, how... Just how? – root Apr 02 '13 at 12:05

1 Answers1

7

The following anecdote does not have a general value:

In 1999, I took the source code for PGP (not GnuPG, still in its infancy), version 5.5, and compiled it on my machine (which was an Alpha running NetBSD, i.e. a rather "normal" Unix system). PGP's source code had been available for quite some years, and it was often touted as necessarily secure since it was open source.

Of course, I almost immediately encountered bugs. I looked at the source, and it turned out that:

  • The code was using the char type as if it was unsigned, and, as such, was completely incapable of correctly processing any character beyond the 7-bit ASCII set. It was so throughout the code.
  • The source code was several hundreds of source files, in more than 30 sub-directories (and sub-directories thereof).

So I came to the conclusion that despite being a high-profile target, with source code open for inspection for several years (the source code had even been printed as a book to work around the US export regulations of that time), nobody actually bothered to look at it (or those who did, did not possess enough knowledge in C to do it correctly).

The code did not make it easy to be audited; auditing code is already a quite boring endeavour that unpaid amateurs are unlikely to tackle on their own accord. It is much more interesting, for the amateur, to rewrite the whole thing from scratch, which is exactly what occurred (with GnuPG).

While I do not believe, generally speaking, in hordes of unnamed amateur reviewers who audit code simply because it is there, there are projects which gather a bit of review, mostly because of people who want to modify the project to suit their needs. Therefore, malicious alterations of security tools are a risky thing. What you will find in all projects, open source or not, security-related or not, are bugs, some of them being exploitable into behaving to the advantage of third parties (i.e. vulnerabilities).

The plausible way to inject a backdoor in open-source security tools is to make an honest-looking implementation or design error, in particular when dealing with PRNG (there have been some allegations, apparently unfounded, of such a backdoor in OpenBSD; see this answer; the backdoor was not there, but everybody took the thing seriously, because it is plausible).

On a pure theoretical basis, external audit can find out all backdoors exactly as much as it can find out all bugs in the audited code -- i.e. it cannot.

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • Well that's ominous... – root Apr 02 '13 at 12:07
  • Glad to see the Many Eyes meme put into context. Seems a healthy open source community with strong leadership and good commit attribution is the best hope overall. Lacking that why trust at all instead sandbox. – zedman9991 Apr 02 '13 at 12:33