Bug 9254 - ekiga, ptlib, opal3 new security issue CVE-2012-5621
: ekiga, ptlib, opal3 new security issue CVE-2012-5621
Status: RESOLVED FIXED
Product: Mageia
Classification: Unclassified
Component: Security
: 2
: All Linux
: Normal Severity: major
: ---
Assigned To: QA Team
: Sec team
: http://lwn.net/Vulnerabilities/541085/
: has_procedure
: validated_update
:
:
  Show dependency treegraph
 
Reported: 2013-03-04 22:47 CET by David Walser
Modified: 2013-05-09 12:34 CEST (History)
7 users (show)

See Also:
Source RPM: ekiga-4.0.0-3.mga3.src.rpm, ptlib-2.10.9-2.mga3.src.rpm, opal3-3.10.9-2.mga3.src.rpm
CVE:


Attachments
ekiga voip port check/test (4.38 KB, text/plain)
2013-04-30 16:52 CEST, Bit Twister
Details
Updated voip_ck (5.61 KB, text/plain)
2013-05-06 20:19 CEST, Bit Twister
Details

Description David Walser 2013-03-04 22:47:02 CET
Fedora has issued advisories on February 24:
http://lists.fedoraproject.org/pipermail/package-announce/2013-March/099555.html
http://lists.fedoraproject.org/pipermail/package-announce/2013-March/099553.html
http://lists.fedoraproject.org/pipermail/package-announce/2013-March/099554.html

The issues are fixed upstream in ekiga 4.0.1, ptlib 2.10.10, opal3 3.10.10.

Mageia 2 is likely to be affected as well.

Reproducible: 

Steps to Reproduce:
Comment 1 Bit Twister 2013-03-05 00:45:13 CET
4.0.1 will probably fix Mageia bug 9249 and close/resolve bug 9147
Comment 2 Nicolas Lécureuil 2013-03-14 10:47:07 CET
fixed in cauldron
Comment 3 Bit Twister 2013-03-14 14:32:34 CET
(In reply to Nicolas Lécureuil from comment #2)
> fixed in cauldron

Still seg faults when attempting to place a echo test.  :(
worse, packages do not have signatures.
Comment 4 David Walser 2013-04-24 23:53:02 CEST
Updated packages uploaded by Nicolas.  Thanks Nicolas!

Advisory:
========================

Updated ekiga, opal3, ptlib packages fix security vulnerability:

A denial of service flaw was found in the way Ekiga processed information from
certain OPAL connections (UTF-8 strings were not verified for validity prior
showing them). A remote attacker (other party with a not UTF-8 valid name)
could use this flaw to cause ekiga executable crash (CVE-2012-5621).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5621
http://lists.fedoraproject.org/pipermail/package-announce/2013-March/099555.html
http://lists.fedoraproject.org/pipermail/package-announce/2013-March/099553.html
http://lists.fedoraproject.org/pipermail/package-announce/2013-March/099554.html
========================

Updated packages in core/updates_testing:
========================
libpt2.10.10-plugins-2.10.10-1.mga2
libpt2.10.10-plugins-avc-2.10.10-1.mga2
libpt2.10.10-plugins-dc-2.10.10-1.mga2
libpt2.10.10-2.10.10-1.mga2
libpt-devel-2.10.10-1.mga2
libopal3.10.10-plugins-3.10.10-1.mga2
libopal3.10.10-3.10.10-1.mga2
libopal3-devel-3.10.10-1.mga2
ekiga-4.0.1-1.mga2

from SRPMS:
ptlib-2.10.10-1.mga2.src.rpm
opal3-3.10.10-1.mga2.src.rpm
ekiga-4.0.1-1.mga2.src.rpm
Comment 5 Dave Hodgins 2013-04-25 03:08:39 CEST
The following packages have bad signatures:
/var/cache/urpmi/rpms/lib64pt2.10.10-2.10.10-1.mga2.x86_64.rpm: Missing signature (OK ((none)))
/var/cache/urpmi/rpms/lib64pt2.10.10-plugins-2.10.10-1.mga2.x86_64.rpm: Missing signature (OK ((none)))
Do you want to continue installation ? (y/N)
Comment 6 David Walser 2013-04-25 05:24:57 CEST
Ahh, guess ptlib was built back when the signing issues were happening.

We don't want it to have a newer release tag than Cauldron, so we'll need a sysadmin to remove ptlib from Mageia 2 updates_testing so that it can be rebuilt.
Comment 7 David Walser 2013-04-25 22:27:25 CEST
ptlib deleted and rebuilt.
Comment 8 Dave Hodgins 2013-04-26 01:25:38 CEST
Just fyi for anyone else testing this.  I had to use "urpmi --clean",
to get rid of the old packages, before it would download the new ones.
This will only affect qa testers who had downloaded the unsigned
versions.
Comment 9 claire robinson 2013-04-30 15:20:55 CEST
Testing x86_64

I've not had any luck with ekiga. Created an account at ekiga.net 

Forwarded ports http://wiki.ekiga.org/index.php/Enable_port_forwarding_manually

Calling the echo test it plays the recorded message but then is unable to send any audio back to be repeated.

Starting it with 'ekiga -d 2 2>output.txt' and browsing output.txt. There are various RTP_UDP failures and it finishes with UDP read error. I cut out some repetition.

OpalPlugin	Not adding H.323 capability for plugin codec MPEG4 as this has been specifically disabled
PTLib	No permission to set priority level 4

CallSetup:...2cfc13b700	RTP_UDP	SetOption(55,8,1048576) failed, even though it said it succeeded!
CallSetup:...2cfc13b700	RTP_UDP	SetOption(55,8,524288) failed, even though it said it succeeded!
CallSetup:...2cfc13b700	RTP_UDP	SetOption(55,8,262144) failed, even though it said it succeeded!

Pool:0x7f2cfc0fa700	SIP	Cannot find transaction z9hG4bK50bbc4c9-03b0-e211-9e40-00218514ca4e for response PDU "2 INVITE <200>"

RTP Jitter...2cfc0b9700	Jitter	Attempt to insert two RTP packets with same timestamp: 157120
RTP Jitter...2cfc0b9700	Jitter	Attempt to insert two RTP packets with same timestamp: 157280
RTP Jitter...2cfc0b9700	RTP_UDP	Session 1, Data port on remote not ready.
Media Patc...2cd409d700	RTP_UDP	Session 2, Data port on remote not ready.
Media Patc...2cd409d700	RTP_UDP	Session 2, Data port on remote not ready.
Media Patc...2cd409d700	RTP_UDP	Session 2, Data port on remote not ready.
Media Patc...2cd409d700	RTP_UDP	Session 2, Data port on remote not ready.
RTP Jitter...2cfc0b9700	RTP_UDP	Session 1, Data port on remote not ready.

OnRelease:...2ca8349700	SIP	Transaction 3 INVITE sip:500@192.168.1.117:5060 failed, unknown handler, ID: 9c0bbfc9-03b0-e211-9e40-00218514ca4e@computer

Housekeepe...2d1e615700	SIP	Starting SUBSCRIBE for offline retry
Housekeepe...2d1e615700	SIP	No compatible listener to create transport for tcp$ekiga.net:5060
Opal Liste...2cfddef700	SIP	Received response for unmatched transaction, id=z9hG4bK662fdbc9-03b0-e211-9e40-00218514ca4e
Opal Liste...2cfddef700	Listen	UDP read error.


It's not a regression though so maybe something for a new bug. Ekiga starts but doesn't actually appear to work very well.
Comment 10 AL13N 2013-04-30 16:31:29 CEST
i've used siproxd on my router/gateway/firewall and used it as a stun in the setup (instead of opening ports)
Comment 11 Bit Twister 2013-04-30 16:51:23 CEST
(In reply to claire robinson from comment #9)

> 
> Calling the echo test it plays the recorded message but then is unable to
> send any audio back to be repeated.

Could be you need to run the mic audio up to about 80%.

You may also want to re-order/enable your audio codecs. What is working for me
  Audio Codecs PCMU
  Audio Codecs PCMA
  Audio Codecs Speex 16 kHx H.323, SIP

I am attaching a user executable script which tests pc firewall, then router for ports used by ekiga.
Comment 12 Bit Twister 2013-04-30 16:52:27 CEST
Created attachment 3853 [details]
ekiga voip port check/test
Comment 13 AL13N 2013-05-02 22:36:14 CEST
i'm unable to get things working properly... no audio is coming back...
Comment 14 Bit Twister 2013-05-02 23:20:15 CEST
(In reply to AL13N from comment #13)
> i'm unable to get things working properly... no audio is coming back...

I am going to assume sound system is Pulse and the above attached port test script passed all the ports.

May be a device selection problem. I have a pci video card with audio hardware.
Had to run pavucontrol->Configuration to select on board audio and disable PCI audio, Input Devices picked correct mic, set ~80%, thumped mic to make sure I could hear mic.

After that, had to get into ekiga->Edit->Pref->Audio->devices to figure out just which were correct selections by going back to General->Sound Events and verifying I could play/hear a sound event. Then try echo test to finally get the correct mic input selected.
Comment 15 AL13N 2013-05-03 07:52:54 CEST
yeah, i verified with pulseaudio volume that the ekiga was actually capturing the correct audio (and the volume control inside ekiga itself verified that the microphone was actually captured correctly)

however, making a call, didn't make a sound; while clicking play on the configured sounds, did work well.

i also tried the callback test which made a sound as well...
Comment 16 AL13N 2013-05-05 15:05:43 CEST
Bit Twister, did you get this working on your end?

since this is a security bug, but we can't get this working normally (are we missing something) if other people can use it just fine, we should push this.
Comment 17 claire robinson 2013-05-05 16:43:27 CEST
Can you also confirm you are testing on Mageia 2 with ekiga-4.0.1-1.mga2 from core updates testing. Thanks.
Comment 18 Bit Twister 2013-05-05 17:02:11 CEST
(In reply to AL13N from comment #16)
> Bit Twister, did you get this working on your end?

64 bit Mageia 3 with pulseaudio setup as a system wide audio server is running 4.0.1 without problems.

> since this is a security bug, but we can't get this working normally (are we
> missing something) if other people can use it just fine, we should push this.

Went and applied all updates to my 64 bit mga2 working ekiga 3.x.x setup which did not know about my new video card. 150+ updates and reboot, I can not get any audio from pulseaudio as a single user or as a system wide audio server at the command line. Example:  /usr/bin/aplay /somewhere/any_file.wav  :(

You have not indicated if you were able to run my port test without port problems.
I was assuming your siproxd/router was giving you problems since you indicated normal pulseaudio mic/playback operation.
Comment 19 AL13N 2013-05-05 17:10:29 CEST
BitTwister: this means you tested cauldron? and not mga2 which this bug report is about? :-S

if you still have a mageia2 around, could you retest with the version 4.0.1-1.mga2 which is the one being validated as a security fix for mga2?
Comment 20 Bit Twister 2013-05-05 18:25:33 CEST
(In reply to AL13N from comment #19)
> BitTwister: this means you tested cauldron? and not mga2 which this bug
> report is about? :-S

Yup.

> if you still have a mageia2 around, could you retest with the version
> 4.0.1-1.mga2 which is the one being validated as a security fix for mga2?

Does my port test pass on your system?

If you re-read comment 18 you might notice I updated my mga2 and lost the ability to get any audio though pulseaudio, let alone through ekiga.

All my suggestions in this bug report were what I had to go through to get 4.x working with my SIP provider on cauldron.

I was hoping Claire, you or someone else would pass the application. With 5 months left for mga2, I did not want to go back through mga2 clean install/update just to do a QA test for you. This system is my "Production" machine and all my automated install scripts have been modified to run on mga3.
Comment 21 AL13N 2013-05-05 19:40:41 CEST
ok, in understand...

i'm gonna retry with port forwarding instead
Comment 22 AL13N 2013-05-05 21:31:55 CEST
/me sighs

i think my new router is somehow trying to be "smart" about voip and failing...

port forwarding doesn't help.

i tried to disable stun but ekiga doesn't let me...

i spent already several hours today trying to get this to work...

i think this is not a regression, so, imho just push it.

/me is giving up
Comment 23 David Walser 2013-05-05 23:22:11 CEST
I think so too...I know we try not to do that in QA if we can help it, but certainly if there's a packaging error we'd like to try and fix it.  If the upstream software just doesn't work very well, there's really not much we can do about that.
Comment 24 claire robinson 2013-05-06 08:25:07 CEST
I agree in this case. It's not a regression. It doesn't appear to do with ptlib as it shows audio input and only the udp connection seems to be failing in some way which points to ekiga itself.

Bug 9997 created for it.

Validating

Advisory & srpm's in comment 4

Could sysadmin please push from core/updates_testing to core/updates

Thanks!
Comment 25 Bit Twister 2013-05-06 18:30:14 CEST
(In reply to AL13N from comment #19)

> if you still have a mageia2 around, could you retest with the version
> 4.0.1-1.mga2 which is the one being validated as a security fix for mga2?

Alright, did a clean install mga2 64 bit, applied updates, changed audio source from pci video/audio card to motherboard hardware, enabled testing, did the urpm,libc updates, added ekiga ports to shorewall rules, rebooted, updated ekiga to 4.0.1, ran through the setup wizard, inserted my ekiga.net id/pw, answered no to call out, took defaults for audio devices. No other changes. Echo test and Call back worked without problems after I boosted mic and output levels using audio controls in ekiga during echo test.
Comment 26 AL13N 2013-05-06 18:55:58 CEST
thanks for testing it, now we know there's nothing wrong and it's us (or our respective environment) that is fucking things up.
Comment 27 Bit Twister 2013-05-06 20:19:05 CEST
Created attachment 3896 [details]
Updated voip_ck
Comment 28 Thomas Backlund 2013-05-09 12:34:36 CEST
Update pushed:
https://wiki.mageia.org/en/Support/Advisories/MGASA-2013-0138

Note You need to log in before you can comment on or make changes to this bug.