Bow Sineath has reported a vulnerability in Eggdrop, which can be exploited by malicious people to compromise a vulnerable system. The vulnerability is caused due to a boundary error within the server module (/mod/server.mod/servrmsg.c) when processing private messages sent by an IRC server. This can be exploited to cause a stack-based buffer overflow via e.g. a specially crafted private message sent to the bot as a server reply. Successful exploitation may allow execution of arbitrary code but requires that the bot connects to a malicious IRC server. The vulnerability is reported in version 1.6.18. Other versions may also be affected. Solution: Do not connect to untrusted IRC servers. Reproducible: Always
lets wait for upstream to provide a fix
upstream takes too long. a simple strncpy should fix this?
Created attachment 125783 [details, diff] Fix strcpy to strncpy to avoid buffer overflow
Comment on attachment 125783 [details, diff] Fix strcpy to strncpy to avoid buffer overflow ><HTML><HEAD/><BODY><PRE>--- servmsg.c 2006-03-28 04:35:51.000000000 +0200 >+++ servmsg.c.new 2007-07-23 22:30:57.000000000 +0200 >@@ -461,7 +461,7 @@ static int gotmsg(char *from, char *msg) > to = newsplit(&msg); > fixcolon(msg); > /* Only check if flood-ctcp is active */ >- strcpy(uhost, from); >+ strncpy(uhost, from, UHOSTLEN); >+ uhost[UHOSTLEN-1] = '\0'; > nick = splitnick(&uhost); > if (flud_ctcp_thr && detect_avalanche(msg)) { > if (!ignoring) { ></PRE></BODY></HTML>
Given the "complexity" of the bug, I think we can just patch it without waiting upstream. pulling herd for advise.
Created attachment 126537 [details, diff] Fix strcpy #2 Corrected the patch instead of the html crap above :) net-irc, any news here?
eggdrop-1.6.18-r2 updated (give it an hour or so to hit the mirrors) with pretty much this same patch. If you USE=vanilla then the ebuild will skip the security patch all together.
Hi arches, please test and mark stable net-irc/eggdrop-1.6.18-r2. target keywords are: "alpha amd64 ia64 mips ppc sparc x86"
amd64 stable
Note to arches. This is pretty much the exact same eggdrop that was -r1. While proper testing is desired (ie put a bot on IRC) it's probably not required assuming the previous keyword was already stable. If 'from' is longer than 'dest' unexpected results may happen. Unexpected may or may not be better then the segv that probably would of happened otherwise. So on that note it's probably good to maybe setup a fake server which might actually attempt to trigger this and point all the arch teams at it. (jeeves is an egg)
sparc stable.
alpha/ia64/x86 stable
ppc stable, ready for glsa
mips stable.
GLSA 200709-07 thanks everyone
actually we've got a problem. my fix was incomplete, thanks to Nico Golde from Debian for pointing that out. here's his patch: http://nion.modprobe.de/01_CVE-2007-2807_servmsg.patch checking mandriva to see if they got the same fix.
mandriva used his patch too, so we should do the same. if someone can please fix this.
eggdrop-1.6.18-r3 is in the tree now as ~alpha ~amd64 ~ia64 ~mips ~ppc ~sparc ~x86
(In reply to comment #18) > eggdrop-1.6.18-r3 is in the tree now as ~alpha ~amd64 ~ia64 ~mips ~ppc ~sparc > ~x86 > Thanks. Arches, please test and mark stable.
x86 stable
alpha/ia64 stable
ppc stable
I know the sparc team is currently having some manpower issues, but please stabilize eggdrop so we can close this one for good. thanks.
sparc stable Ready to go
GLSA-200709-07 was already published actually :p mips, don't forget to mark stable so you can benefit from it.
(In reply to comment #26) > GLSA-200709-07 was already published actually :p Doesn't this require an errata GLSA with the new unaffected version number?
We need an errata on this one.
any news here?
A Happy New Year... and could someone perhaps clarify the situation here please?
Since the xml GLSA was already updated, this just needs an ERRATA email be sent. I hope we'll do it this week.
errata sent, finally closing and sorry for the long delay :-/