8 ms·

Horde backdoored

84 points by kaeso 15y ago

jvehent 15y ago
it's 2012: stop using horde and install roundcube !
- imr 15y ago
  Have you tried Horde 4? It is much better than version 3 and is not affected by this issue.
  - mverwijs 15y ago
    Tried? Yes. Failed? Miserably. I've happily used Horde for well over 5 years. I was really really looking forward to Horde4. Once it came out, I immediately tried it. Tried to install it, that is. I failed. The lack of clear documentation combined with the dark magic of php-pear kept me from migrating. And even when I did get it installed I was unable to comprehend the UI. It completely changes depending on what 'application' you're using. There is no consistency. E.g.: The calendar in Horde4. The interface completely changes into nothing you've ever experienced. It's unrecognisable from the rest of Horde4. I migrated to RoundCube + Plugins for calendar (caldav+davical) and addressbooks (carddav + davical) and have been a happy, android syncing camper ever since.
    - imr 15y ago
      php-pear dark magic is nothing compared to installing the framework libraries from git! The pear.horde.org instructions fail to mention that you must install horde/Horde_Role before any of the applications. The UI is currently undergoing a rewrite, but the default interface can be forced into the traditional view in the Horde configuration.
fuscata 15y ago
Check with: grep -r "\$m\[1\](\$m\[2\])" /path/to/horde
bryanh 15y ago
I've always been very trusting of open source software. I've often thought "surely someone else has looked through this source code" and just assumed that malicious code never hits stable releases. The same goes for "verified" binaries, packages, etc... apparently that is not always the case. What are the possibilities that such code could make its way into some piece of extremely popular public facing software, say Apache? How many cleverly hidden "bugs" already exist that open us up to complete pwnage for the clever bastard behind them? Just think about the havoc someone could do with a few popular but nasty PyPi or RubyGem packages...
- warp 15y ago
  Typically the people looking "through the source code" are the developers working on the the project. Both occasional contributors who want to fix a bug or add a feature for themselves, or the main developers taking those patches and adding them to the main release branch after reviewing the code. All those developers use VCS repositories, not the releases distributed through FTP sites and such -- which were the files affected here.
- kylemaxwell 15y ago
  While those points all matter, don't think of this as an open source issue. This can happen to any software provider, and often does.
- brador 15y ago
  Wasn't there a serious backdoor situation with some Linux distros (Ubuntu?) last year? Some guy came out detailing a 10 year contract of silence or something...
  - dignan 15y ago
    As I recall, numerous developers and security experts tore through the relevant code there, and they didn't find anything.
  - kijin 15y ago
    You mean the OpenBSD IPSec backdoor controversy? Nothing found AFAIK.
NelsonMinar 15y ago
So several Horde releases were trojaned for three months? That's pretty terrible. Good on them for coming clean. What's the best way for open source projects to make it easy for their customers to get verified downloads? A lot of packages post MD5 checksums but no one tests them when downloading manually, do they? Automated signature checking on Debian packages seem to work better in practice; homebrew also verifies download checksums automatically.
- ctz 15y ago
  Checksums provide no security. Idea: protocol- and package-format-independent verification of packages, with trust rooted in DNSSEC of the ultimate source domain using DANE.
  - dlgtho 15y ago
    That's not entirely true. Since i found how to poison my ISP's PeerApp "invisible" cache servers i started to check MD5 when downloading manually. It does cache big files but not small ones. Here is the link for technical details if you are interested. http://godlessmechanics.blogspot.com/2011/12/tale-of-sneaky-proxy.html http://godlessmechanics.blogspot.com/2011/12/tale-of-sneaky-...
- adbachman 15y ago
  If they have access to the packages, they have access to the checksums. The checksums only verify that the file isn't corrupt, what you should receive is what you actually received.
  - NelsonMinar 15y ago
    True; proper digital signatures would be better. My understanding is the checksums exist to be distributed so that maybe someone would notice "hey, foo.tar.gz on this mirror has the wrong checksum!" The way it works in Homebrew, for instance, is that the sha256 of a file downloaded from the source server is verified against the checksum stored in Homebrew's github repository. Someone would have to compromise both the source server and the github repository to break it. Not ideal, but better than nothing. More importantly it's automatic; Homebrew users don't think about it. git has pretty good signatures for tags. Maybe there's a way to leverage that for secure open source distribution.
jaryd 15y ago
kernel.org, vsftpd, unrealircd, who will fall next?
mlntn 15y ago
"Horde backdoored" - Hey, that rhymes!
d3b14n 15y ago
Horde 4 is not affected. If you're running it, you're fine. The affected releases are: - Horde 3.3.12 downloaded between November 15 and February 7 - Horde Groupware 1.2.10 downloaded between November 9 and February 7 - Horde Groupware Webmail Edition 1.2.10 downloaded between November 2 and February 7
deleted 15y ago
[deleted]
cs702 15y ago
The comments on this page immediately reminded me of Ken Thompson's point: "You can't trust code that you did not totally create yourself." He wrote this right after demonstrating how to create, step-by-step, an undetectable trojan horse in the C compiler. Here are the steps for creating such a trojan horse: http://cm.bell-labs.com/who/ken/trust.html http://cm.bell-labs.com/who/ken/trust.html [ Also see http://news.ycombinator.com/item?id=2642486 http://news.ycombinator.com/item?id=2642486 ]
- justinlau 15y ago
  You can't totally trust your own code, either. Look at all the buffer overrun vulnerabilities that have been found over the years.
- atdt 15y ago
  Thanks for sharing the link. It's one of the finest things about programming I've read. I enjoyed it a lot.
laconian 15y ago
Well, shit. So much for host-it-yourself services being more secure. Which dogma do I trust now?
deleted 15y ago
[deleted]

Horde backdoored

84 points by kaeso 15y ago

jvehent 15y ago

it's 2012: stop using horde and install roundcube !

imr 15y ago
Have you tried Horde 4? It is much better than version 3 and is not affected by this issue.
- mverwijs 15y ago
  Tried? Yes. Failed? Miserably. I've happily used Horde for well over 5 years. I was really really looking forward to Horde4. Once it came out, I immediately tried it. Tried to install it, that is. I failed. The lack of clear documentation combined with the dark magic of php-pear kept me from migrating. And even when I did get it installed I was unable to comprehend the UI. It completely changes depending on what 'application' you're using. There is no consistency. E.g.: The calendar in Horde4. The interface completely changes into nothing you've ever experienced. It's unrecognisable from the rest of Horde4. I migrated to RoundCube + Plugins for calendar (caldav+davical) and addressbooks (carddav + davical) and have been a happy, android syncing camper ever since.
  - imr 15y ago
    php-pear dark magic is nothing compared to installing the framework libraries from git! The pear.horde.org instructions fail to mention that you must install horde/Horde_Role before any of the applications. The UI is currently undergoing a rewrite, but the default interface can be forced into the traditional view in the Horde configuration.

fuscata 15y ago

Check with: grep -r "\$m\[1\](\$m\[2\])" /path/to/horde

bryanh 15y ago

I've always been very trusting of open source software. I've often thought "surely someone else has looked through this source code" and just assumed that malicious code never hits stable releases. The same goes for "verified" binaries, packages, etc... apparently that is not always the case. What are the possibilities that such code could make its way into some piece of extremely popular public facing software, say Apache? How many cleverly hidden "bugs" already exist that open us up to complete pwnage for the clever bastard behind them? Just think about the havoc someone could do with a few popular but nasty PyPi or RubyGem packages...

warp 15y ago
Typically the people looking "through the source code" are the developers working on the the project. Both occasional contributors who want to fix a bug or add a feature for themselves, or the main developers taking those patches and adding them to the main release branch after reviewing the code. All those developers use VCS repositories, not the releases distributed through FTP sites and such -- which were the files affected here.
kylemaxwell 15y ago
While those points all matter, don't think of this as an open source issue. This can happen to any software provider, and often does.
brador 15y ago
Wasn't there a serious backdoor situation with some Linux distros (Ubuntu?) last year? Some guy came out detailing a 10 year contract of silence or something...
- dignan 15y ago
  As I recall, numerous developers and security experts tore through the relevant code there, and they didn't find anything.
- kijin 15y ago
  You mean the OpenBSD IPSec backdoor controversy? Nothing found AFAIK.

NelsonMinar 15y ago

So several Horde releases were trojaned for three months? That's pretty terrible. Good on them for coming clean. What's the best way for open source projects to make it easy for their customers to get verified downloads? A lot of packages post MD5 checksums but no one tests them when downloading manually, do they? Automated signature checking on Debian packages seem to work better in practice; homebrew also verifies download checksums automatically.

ctz 15y ago
Checksums provide no security. Idea: protocol- and package-format-independent verification of packages, with trust rooted in DNSSEC of the ultimate source domain using DANE.
- dlgtho 15y ago
  That's not entirely true. Since i found how to poison my ISP's PeerApp "invisible" cache servers i started to check MD5 when downloading manually. It does cache big files but not small ones. Here is the link for technical details if you are interested. http://godlessmechanics.blogspot.com/2011/12/tale-of-sneaky-proxy.html http://godlessmechanics.blogspot.com/2011/12/tale-of-sneaky-...
adbachman 15y ago
If they have access to the packages, they have access to the checksums. The checksums only verify that the file isn't corrupt, what you should receive is what you actually received.
- NelsonMinar 15y ago
  True; proper digital signatures would be better. My understanding is the checksums exist to be distributed so that maybe someone would notice "hey, foo.tar.gz on this mirror has the wrong checksum!" The way it works in Homebrew, for instance, is that the sha256 of a file downloaded from the source server is verified against the checksum stored in Homebrew's github repository. Someone would have to compromise both the source server and the github repository to break it. Not ideal, but better than nothing. More importantly it's automatic; Homebrew users don't think about it. git has pretty good signatures for tags. Maybe there's a way to leverage that for secure open source distribution.

jaryd 15y ago

kernel.org, vsftpd, unrealircd, who will fall next?

mlntn 15y ago

"Horde backdoored" - Hey, that rhymes!

d3b14n 15y ago

Horde 4 is not affected. If you're running it, you're fine. The affected releases are: - Horde 3.3.12 downloaded between November 15 and February 7 - Horde Groupware 1.2.10 downloaded between November 9 and February 7 - Horde Groupware Webmail Edition 1.2.10 downloaded between November 2 and February 7

deleted 15y ago

[deleted]

cs702 15y ago

The comments on this page immediately reminded me of Ken Thompson's point: "You can't trust code that you did not totally create yourself." He wrote this right after demonstrating how to create, step-by-step, an undetectable trojan horse in the C compiler. Here are the steps for creating such a trojan horse: http://cm.bell-labs.com/who/ken/trust.html http://cm.bell-labs.com/who/ken/trust.html [ Also see http://news.ycombinator.com/item?id=2642486 http://news.ycombinator.com/item?id=2642486 ]

justinlau 15y ago
You can't totally trust your own code, either. Look at all the buffer overrun vulnerabilities that have been found over the years.
atdt 15y ago
Thanks for sharing the link. It's one of the finest things about programming I've read. I enjoyed it a lot.

laconian 15y ago

Well, shit. So much for host-it-yourself services being more secure. Which dogma do I trust now?

deleted 15y ago

[deleted]