0

I would like to know if there is an effective way to audit source codes of open-source projects without having to examine all the plaintext files every time the application gets updated, and when a new source is putted available for download.

I thought in creating an application that could scan the projects automatically for me, but I think it wouldn't be even near of a good level of effectiveness, since there are many ways to implement malware codes inside the projects which aren't common. The auditing is intended to detect malwares inside open-source projects.

Do you have any suggestions for me?

Bernhard Barker
  • 54,589
  • 14
  • 104
  • 138
Bole Grat
  • 71
  • 10
  • @IraBaxter, try escaping the \* but won't `rm *.*` remove all files? – Popnoodles Jan 11 '14 at 15:57
  • Don't use any open source, where the community that creates it either codes malware, or allows malware to be contributed. Anyother option is just another flavour of the arms race that is malware detection in closed source. – Tony Hopkinson Jan 11 '14 at 16:19
  • @Popnoodles: something deleted my comment. Yes, the point of rm star dot star is that it removes all files, thus is malicious. In particular, changing two characters converts an program from benign to malicious. [What are the rules for quoting text in comments? Where are they documented?] – Ira Baxter Jan 12 '14 at 18:04

1 Answers1

1

Backdoors in Open Source Software have traditionally been pretty hard to insert, and they have to be very subtle. Take a look at this article about Linux for one data point. Using automated tools to try and find something like that is more than likely going to fail, especially since there are so many ways to hide/obfuscate code.

One option would be to run a standard Static Analysis tool (such as Gimpel's Lint, Purify, etc.) on the initial code to create a baseline. Then run it again on the new code drop. If there are any deltas in the outputs, you would want to investigate each individual change.

I think more common than backdoors/malware are changes that inadvertently (accidentally) gimp the security. There was a change in the OpenSSL library where an edit removed some code because analysis tools complained. But the code was intentionally left that way to provide more bits of entropy. Once the entropy was reduced, the session was a lot easier to break. The impact of changes like that are going to be neigh impossible to interpret, as it takes an expert who is intimately familiar with the code to understand effects.

josh poley
  • 7,236
  • 1
  • 25
  • 25
  • Bottom line: you are analyzing Turing Machines. It is well known that this is impossible to do right. Using open source is a version of Alice in Wonderland's bottle labelled "Drink Me". Side effects may be surprising. – Ira Baxter Jan 12 '14 at 18:06