From secunia security advisory at $URL:
A vulnerability has been reported in InspIRCd, which can be exploited by malicious people to compromise a vulnerable system.
The vulnerability is caused due to an error within dns.cpp when handling DNS responses and can be exploited to cause a heap-based buffer overflow.
Successful exploitation may allow execution of arbitrary code.
The vulnerability is reported in version 2.0.5. Other versions may also be affected.
As a workaround, update the configuration file to set "<performance:nouserdns>" to "yes".
Is a gentoo configuration vulnerable?
I guess our configuration is vulnerable since it defines <performance:nouserdns> to "no".
The inspircd website has been down for more than a week. I tried to contact them some months ago wrt the update of the current gentoo version shown in their webpage but I got no response.
I'll bump the current version to apply the workaround proposed and some pending minor changes.
Removing Dane Smith (c1pher) from CC, he was my proxy.
Thanks for the heads up.
(In reply to comment #1)
> Removing Dane Smith (c1pher) from CC, he was my proxy.
Please also remove it from metadata.xml
Heap-based buffer overflow in dns.cpp in InspIRCd 2.0.5 might allow remote
attackers to execute arbitrary code via a crafted DNS query that uses
inspircd-2.0.5-r1 now in the tree, includes suggested workaround.
Arches, please test and mark stable:
Target KEYWORDS : "amd64 x86"
The following configuration directory sample can help to test the package:
Thanks, everyone. Already in GLSA request.
There is an issue in this ebuild, about the "ssl" use flag which used to be "openssl" use flag.
IUSE="gnutls ipv6 ldap mysql postgres sqlite ssl" <<--- was "openssl" in previous ebuilds, even 2.0.5 non-r1.
ssl? ( dev-libs/openssl ) <<--- same here
Thus m_ssl_openssl.so isn't build anymore, preventing eventually inspircd from starting.
(In reply to comment #10)
> There is an issue in this ebuild, about the "ssl" use flag which used to be
> "openssl" use flag.
The flag name was changed, according to use.desc:
ssl - Adds support for Secure Socket Layer connections
> Thus m_ssl_openssl.so isn't build anymore, preventing eventually inspircd
> from starting.
You are right, my bad here, the package is not been properly configured for the new flag name. Thanks for the catch!
@ago: I have a fix for this. I'd fix it in inspircd-2.0.5-r2, but, would it be ok to include it in current inspircd-2.0.5-r1, avoiding the revision bump?. Thanks
gnutls also affected:
Unable to load m_ssl_gnutls.so: /usr/lib64/inspircd/modules/m_ssl_gnutls.so: undefined symbol: gcry_randomize
(In reply to comment #12)
> gnutls also affected:
> Unable to load m_ssl_gnutls.so: /usr/lib64/inspircd/modules/m_ssl_gnutls.so:
> undefined symbol: gcry_randomize
correction: resolved as incompatible with gnutls-2.12.18
(In reply to comment #13)
> (In reply to comment #12)
> correction: resolved as incompatible with gnutls-2.12.18
This commit  fixes the m_ssl_gnutls module link breakage with gnutls-2.12.18.
Unfortunately it was not included in inspircd-2.0.5 upstream version. I'll include this fix in the upcoming inspircd-2.0.5-r2 revision.
This issue was resolved and addressed in
GLSA 201204-02 at http://security.gentoo.org/glsa/glsa-201204-02.xml
by GLSA coordinator Sean Amoss (ackle).