This is a minor bug fix release.
The bugs fixed are summarized below.
Servers with auto-update enabled will have this update automatically applied at some time over the next 24 hours. You can do the update manually also. Login to the server as root and run the command:
* Horde/IMP webmail security hole - This bug was brought to our attention by Alex from Sliqua Enterprise Hosting - thanks Alex!
* ClamAV failed to start and enable on new InterWorx installs.
* “Unknown Error” from Mass Transfer Import due to /usr/bin/expect version change
* Invalid API key fails to generate correct error message in some cases
* Manually adding or editing a MX record that exists under other domain names fails
* Importing an account with secondary domains would “get stuck” in some cases
* Adding a 4th dns-template NS record would add the record incorrectly
* When configuring server as cluster manager, NodeWorx would sometimes report the incorrect IP as the “primary” IP on an interface
* Restarting webserver via NodeWorx interface failed in some cases with the latest apache version
* Maximum non-zero account quota limit was incorrect
* DNS “mutual” synchronization between two servers didn’t always sync both ways when IP addresses and not hostnames were used for setting up the sync’s
* Misc language string fixes
I just did a yum update and the only thing that came up was an updated kernel 2.6.18-53.1.14.el5
Maybe your server already auto-updated Justin? You can check the current version with
rpm -qi | grep interworx
grep version ~iworx/iworx.ini
or anywhere in the NodeWorx or SiteWorx interface in the bottom right corner. If that’s not the case feel free to open a ticket and we’ll see why it isn’t updating.
Thank you for fixing the Horde exploit lads!
I just checked in NodeWorx and the update was done on the 7th. I just realized that you made that post at 4am EST :eek: so it had already updated.
ahh yes thank you didnt even notice
I’m away for a few days and you guys update without me.
Everything went well here, automatically.
No updates since 10/16/2007
My server has not auto updated Interworx since October 16th. 2007.
Also everytime I restart my server, the graphs (CPU, Memory and Bandwidth) stops. Complained about this a while ago, and received a reply I had to update (edit) a startup file on my server. However before an earlier update this had worked for a few years!?!
If you e-mail email@example.com, we’ll be happy to investigate both issues.
HAHAHA - VERY FUNNY - NOT!
"Your message to: firstname.lastname@example.org
was blocked by our Spam Firewall. The email you sent with the following subject has NOT BEEN DELIVERED:
Subject: RE: [#103291] Multiple problems."
RWF, I rarely email in and just start a ticket here:
More detail please?
[quote=IWorx-Paul;15134]* Horde/IMP webmail security hole - This bug was brought to our attention by Alex from Sliqua Enterprise Hosting - thanks Alex![/quote]Is there any additional information available about the fixed security hole? We discovered 3,000+ spams in the out-going queue this morning, all of which were emailing from iworx@[our-servers-hostname.net]. An explaination via PM is fine with me; I just want to be sure we have closed the hole so the spam authorities don’t come after us agian! :eek:
P.S. - InterWorx failed to auto-update this one for us. It looks like it failed because v3.0.3 used three RPM’s (interworx, interworx-nodeworx, and interworx-siteworx) but now there is only one (interworx).
[quote=jimp;15610]…I just want to be sure we have closed the hole…[/quote]It turns out the spam was coming from a compromised website. I’m still curious what actually changed with Horde, because the changelog before and after the upgrade was the same, but I wanted to clarify that our spam issue was not caused by InterWorx < 3.0.4.
The horde change had to do with validation of custom theme names as I recall. It wasn’t a problem with would have allowed mass spamming, and there was nothing else from 3.0.3 to 3.0.4 that fixed a mass spamming related problem either.
The question that remains is why did e-mail appear to be sent from the “iworx” user, and the answer there is a little odd. It has to do with qmail’s default behavior when no user is specified as a sender. It looks for certain environment variables to use, and since the spam was sent through a php scrript on the web server, and InterWorx uses php scripts for the cron tasks, a certain environment variable that qmail looks for was set to “iworx”. This is an odd side affect, but it’s not a cause for concern.