Centericq segfaults under certain circumstances. I've tracked them down to some, but i'm not sure how easy it is to reproduce the crash. 1. centericq must be running and connected to some icq server (Server : login.icq.com:5190 here) 2. There should be direct connection to the internet (not behind a router/masquerading). Not sure exactly when it (doesn't) work, but centericq opens a port for icq messages. 3. Find port with netstat -tlp |grep centericq - let's say it's 38096 in this example. 4. Start nessus on same box or somewhere on the lan (haven't tried it from a completely different host on the internet) 5. Use a port range that is the port -1 until the port +1 (in this case 38095 to 38097). Check nmap scan in Scan options. The port range may also be bigger than that, but selecting only the port doesn't seem to work. This may be more a problem with the way nessus works though. 6. Check Plugins -> Service detection -> Services. No other plugins necessary. 7. Nessus does some probes, centericq segfaults. I hope someone can reproduce the problem, if you're not able to you can also ping me on irc.
DerCorny just found out the option "Enable peer-to-peer communications" needs to be set to yes for the listening port to appear. It seems to be set to no by default. We've been able to verify the Segfault on his box.
Created attachment 64566 [details] centericq PoC "exploit"
well yeah, check my dirty attachment. sends nothing but 0x01 to centericq and crashes it. i had not enough time to find out where exactly it crashes, but i guess during Client::ParseCh2 in Client.cpp of the icq2000-lib, but i'm not sure.
This has been around for a month now, any activity on this? If not, what about just reporting it upstream so they can fix it?
Auditors you want to check on this or should we CC upstream?
Rob confirms this, moving into vulnerabilities.
Someone volunteers to push it upstream ?
Mail sent to upstream.
No news, Wolfram, could you check with your upstream friends what they are up to ?
the only reaction from thekonst so far: "I am on business trip in California now" "actually, I don't even know what crash it is about" I know it's not our job, but can someone here produce a patch that we can send him? I fear otherwise nothing will happen soon... :-(
Tigger/Taviso/Vapier/Solar will you patch or recommend a mask?
centericq probably misses several sanity checks on that connection, so it's more a rewrite than a patch. If upstream fails to see the need, we should probably mask it (but that implies going public).
If it's just a crash I don't think it's worth masking... Maybe documenting the option as unsafe ? Auditors: any chance this can be used to execute code ? If nobody complains, I'll open this tomorrow Thursday at 1400 UTC, since it's not a big deal anyway.
Opening.
wolfram/wernfried could you put a warning somewhere in the documentation? Changing component until someone shows that RCE is possible. Feel free to change it back if you disagree.
wschlich please provide an updated ebuild with the Debian patch.
Let's put it back in "Vulnerabilities" scope
Sorry for the delay, I'm working on it...
Committed =net-im/centericq-4.21.0-r1 archmasked, so the arches can check and mark it stable. Arches are: amd64 hppa ppc ppc64 sparc x86
Thanks Wolfram. Arches please test and mark stable...
gnah, if i knew that there is an open security bug where 4.21.1 is affected too i wouldn't have marked it stable yesterday. -r1 stable on amd64
sparc stable.
x86 stable.
Marked ppc stable.
Ready for GLSA vote, I tend to vote yes.
A weak YES from me.
Full yes and glsa-ed
Hm. Maybe we should wait for bug 113683 to be resolved ?
Both are ready now.
GLSA 200512-11
