Bugzilla Bug 100519

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 an attachment (id=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