Testing extensions for malware.

[Frank]

Though it is easy to insert malicious code into the source of any app, like adding the line "system("rm -rf /")" in one of the apps functions before compiling which would be undetectable, I don't mind adding assurance by scanning files with Clamav before uploading to the repo.  That would detect any of the known malware functions that would be present, and also works on ELF binaries.

(emphasis added)

The emphasized part is the major problem with user-contributed binaries: once the source code is compiled, "customizations" made by the compiling person are no longer detectable. At least not with a reasonable effort.

The only solution that I see is to separate the development of extensions from the actual compilation of the source code. Let everyone upload build scripts [1] for new extensions, but let only a very small and hand-selected set of volunteers compile those scripts and send you the resulting binaries for inclusion in the repository [2]. Build scripts are easy to monitor for everyone with basic knowledge in shell syntax. Binaries that come out of such a process are way more trustworthy than binaries from nobody-can-really-tell-whom.

Just a suggestion, of course.

---

[1] Build scripts are used for example by gobolinux (called "recipes"), Slax (called "build scripts"), and SourceMage (called "spells"). Gentoo I have never used, but it must be based on something similar.

[2] If the process is well automated, then people will queue to volunteer their spare CPU cycles to this "distributed TCE compile farm."

[Kingdomcome]

Arch uses PKGBUILDS in their community repo as well to clearly spell out the compile process.  I like the idea of everyone knowing exactly how the extensions are built and I contribute my build script with every submission.  The script is complete in that you can boot TC/MC with "base norestore", download the script, run it and have a working extension with accompanying files when the script finishes.  It would be nice if all extension builders did the same, but that choice is still left up to the contributors and is has not caused any problems as of yet.

[Jason W]

For one thing, the recently announced practice of extensions not overwriting existing files will help in the pursuit of protection from malicious extensions.  It does not allow the flexibility in extension making that the ability to overwrite existing files does, but it will prevent the overwriting of existing base or extension files by a casually made extension.

Also, I have added some very detailed checks to my own extension audit process to help prevent the possibility of system or data loss from loading and running an extension that is being submitted.  As stated earlier, it would only undermine the effort to state exactly what is being looked for,  but I have spent the day today on this and will keep adding to it.

From the discussion, there seems to be 3 vulnerabilities at hand:

1. Malicious packages overwriting existing data/system files.

2. Malicious commands in various scripted programming languages being executed.

3. Maliciously compiled binaries that use malicious functions.


Obviously, the first threat is annulled by the announced changes in tce-load.

And I am dealing with the other 2 and making security a priority in extension checking.

[Harnessmaker]

Jason W:

Thank you.  That is very welcome news.

Regards,  Harnessmaker