Bug 100519 – net-im/centericq: 4.20.0-r3 remote crash (CVE-2005-3694)

• Product: Gentoo Security
• Status: RESOLVED FIXED

[Description Wernfried Haas (RETIRED) 2005-07-27 14:42:32 UTC]

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.

[Comment 1 Wernfried Haas (RETIRED) 2005-07-27 15:24:07 UTC]

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.

[Comment 2 Stefan Cornelius (RETIRED) 2005-07-28 11:55:25 UTC]

Created attachment 64566 [details]
centericq PoC "exploit"

[Comment 3 Stefan Cornelius (RETIRED) 2005-07-28 11:58:26 UTC]

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.

[Comment 4 Wernfried Haas (RETIRED) 2005-08-26 15:39:41 UTC]

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?

[Comment 5 Sune Kloppenborg Jeppesen (RETIRED) 2005-09-08 23:24:08 UTC]

Auditors you want to check on this or should we CC upstream?  

[Comment 6 Tavis Ormandy (RETIRED) 2005-09-19 05:45:15 UTC]

Rob confirms this, moving into vulnerabilities.

[Comment 7 Thierry Carrez (RETIRED) 2005-09-20 00:54:17 UTC]

Someone volunteers to push it upstream ?

[Comment 8 Thierry Carrez (RETIRED) 2005-09-27 07:28:52 UTC]

Mail sent to upstream.

[Comment 9 Thierry Carrez (RETIRED) 2005-10-04 05:50:25 UTC]

No news, Wolfram, could you check with your upstream friends what they are up to ?

[Comment 10 Wolfram Schlich (RETIRED) 2005-10-06 03:11:34 UTC]

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... :-(

[Comment 11 Sune Kloppenborg Jeppesen (RETIRED) 2005-10-06 03:19:39 UTC]

Tigger/Taviso/Vapier/Solar will you patch or recommend a mask? 

[Comment 12 Thierry Carrez (RETIRED) 2005-10-07 01:08:04 UTC]

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).

[Comment 13 Thierry Carrez (RETIRED) 2005-10-12 09:01:54 UTC]

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.

[Comment 14 Thierry Carrez (RETIRED) 2005-10-13 09:07:53 UTC]

Opening.

[Comment 15 Sune Kloppenborg Jeppesen (RETIRED) 2005-10-21 23:46:24 UTC]

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. 

[Comment 16 Sune Kloppenborg Jeppesen (RETIRED) 2005-11-20 13:04:18 UTC]

wschlich please provide an updated ebuild with the Debian patch. 

[Comment 17 Thierry Carrez (RETIRED) 2005-11-21 01:28:37 UTC]

Let's put it back in "Vulnerabilities" scope

[Comment 18 Wolfram Schlich (RETIRED) 2005-11-25 06:38:36 UTC]

Sorry for the delay, I'm working on it...

[Comment 19 Wolfram Schlich (RETIRED) 2005-11-25 06:58:43 UTC]

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

[Comment 20 Thierry Carrez (RETIRED) 2005-11-25 07:15:53 UTC]

Thanks Wolfram.
Arches please test and mark stable...

[Comment 21 Simon Stelling (RETIRED) 2005-11-25 08:14:14 UTC]

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

[Comment 22 Gustavo Zacarias (RETIRED) 2005-11-25 09:27:56 UTC]

sparc stable.

[Comment 23 Chris White (RETIRED) 2005-11-25 12:00:36 UTC]

x86 stable.

[Comment 24 Joe Jezak (RETIRED) 2005-11-27 11:59:42 UTC]

Marked ppc stable.

[Comment 25 Thierry Carrez (RETIRED) 2005-11-27 13:46:13 UTC]

Ready for GLSA vote, I tend to vote yes.

[Comment 26 Sune Kloppenborg Jeppesen (RETIRED) 2005-11-27 13:57:19 UTC]

A weak YES from me. 

[Comment 27 Thierry Carrez (RETIRED) 2005-11-29 02:37:17 UTC]

Full yes and glsa-ed

[Comment 28 Thierry Carrez (RETIRED) 2005-11-29 02:42:16 UTC]

Hm. Maybe we should wait for bug 113683 to be resolved ?

[Comment 29 Thierry Carrez (RETIRED) 2005-12-18 03:40:54 UTC]

Both are ready now.

[Comment 30 Thierry Carrez (RETIRED) 2005-12-20 03:09:24 UTC]

GLSA 200512-11