If you downloaded one of three messaging apps from the Horde Project's FTP …

For almost three months, versions of three widely distributed open-source applications from Horde.org contained a backdoor that allowed attackers to remotely execute malicious PHP code on systems that ran the programs.

Members of the Horde Project warned of the tampering earlier this week, in a bulletin that advised users of the collaboration and messaging applications to immediately reinstall newer versions that didn't contain the malicious code. Those affected included anyone who downloaded installation packages for Horde 3.3.12, Horde Groupware 1.2.10 or Horde Groupware Webmail Edition 1.2.10 between various dates in November and February 7. Horde 4 is not affected. A module that targets the vulnerability has already been added to the Metasploit framework for hackers and penetration testers.

According to the Eric Romang Blog, at least two Linux distributions, from Ubuntu and Debian, were delivering the tainted versions of Horde 3.3.12.

"The impact through Linux distribution should be not so important," Wednesday's post went on to say. "Only users who have download the source code from FTP are mainly affected."

Horde's advisory said the releases were altered after unidentified hackers breached an FTP server used to distribute the installation packages.

"We apologize for the inconvenience and assure you that we are undertaking a full security review of our procedures to prevent this kind of incident from happening again," members of the project wrote.

Horde's advisory is just the latest admission by a trusted developer of open-source software that its defenses were penetrated. In August, the archive site for the Linux kernel was compromised by hackers who gained root access to several servers and installed key-logging software. There was no evidence any of the repositories storing Linux source code was tampered with.

The security built into git helped us to immediately verify that none of the newer Horde 4 packages had been tampered with. Horde 4 is the release version that was published a year ago.

But of course git is not everything: In most cases software is not deployed via the version control system. Package management enters the game and that means package archives. These need to be secured as well and has a main focus now.

The Horde 3 line is reaching its end of live rather soon and our release from last week was the last one we actually intended for that version. Obviously security on that branch didn't receive the attention it should have.

Well the issue here is not binaries, but source tarballs that the distros use to build their binary packages. Likely the tarballs were replaced by the attacker, and the related checksums updated to match. If they wanted to be fancy they could likely even tamper with the modification dates on the files to make them appear untouched.

The only way to make sure then would be to unpack and check every file vs the equivalent revision in git or similar. This will take time, and so i suspect it will only happen if one suspect something or go in with a paranoid outlook on computing.

And if your checking against git, you can just as well grab it from there in the first place.

Well the issue here is not binaries, but source tarballs that the distros use to build their binary packages. Likely the tarballs were replaced by the attacker, and the related checksums updated to match. If they wanted to be fancy they could likely even tamper with the modification dates on the files to make them appear untouched.

Actually, the tarballs ARE the final products for the Horde 3 line. As a web application written in PHP, there are no compiled binaries. The source code *is* the application. Of course, some distros choose to download these packages from the FTP server and repackage them for their package management system - others may choose to obtain the code from version control.

We actually tried at one point to use Github as a distribution channel for our Horde 4 packages via Github Pages. After many discussions with Github support, we were told that this would be near impossible to sustain due to the size and number of packages, as well as the frequency of releases.

Nothing guarantees that any server or service is truly secure. However, there are different levels of risk involved in different services.

Take for example a FOSS project running its own Web and FTP servers (not sure if Horde is or not). If your FTP admin is a Starbucks barrista by day and FileNeo the FTP Lord by night, there's a damn good chance that you're operating with significantly higher risk than if your FTP admin is a professional sysadmin all day 'round.

Again, that does not mean that professional sysadmins never get hacked and every hobbyist does. It just means that, out of the hundreds of thousands of such individuals, the professionals have a lower rate of screwing up than the hobbyist crowd.

Also note that "professional" doesn't mean "is paid money." I know of far too many hobbyists who con IT-clueless HR managers into hiring them to do things that a professional will do much better (if only for a lot more money).