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:
CC: (none) => olavWhiteboard: (none) => MGA2TOO
4.0.1 will probably fix Mageia bug 9249 and close/resolve bug 9147
CC: (none) => junk_no_spamHardware: i586 => All
fixed in cauldron
CC: (none) => nicolas.lecureuil
Whiteboard: MGA2TOO => (none)Version: Cauldron => 2
(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.
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
Assignee: fundawang => qa-bugs
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)
Whiteboard: (none) => feedbackCC: (none) => davidwhodgins
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.
CC: (none) => sysadmin-bugs
ptlib deleted and rebuilt.
Whiteboard: feedback => (none)
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.
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.
Whiteboard: (none) => feedback has_procedure
i've used siproxd on my router/gateway/firewall and used it as a stun in the setup (instead of opening ports)
CC: (none) => alien
(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.
Created attachment 3853 [details] ekiga voip port check/test
i'm unable to get things working properly... no audio is coming back...
(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.
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...
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.
Can you also confirm you are testing on Mageia 2 with ekiga-4.0.1-1.mga2 from core updates testing. Thanks.
(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.
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?
(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.
ok, in understand... i'm gonna retry with port forwarding instead
/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
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.
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!
Keywords: (none) => validated_updateWhiteboard: feedback has_procedure => has_procedure
(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.
thanks for testing it, now we know there's nothing wrong and it's us (or our respective environment) that is fucking things up.
Created attachment 3896 [details] Updated voip_ck
Attachment 3853 is obsolete: 0 => 1
Update pushed: https://wiki.mageia.org/en/Support/Advisories/MGASA-2013-0138
Resolution: (none) => FIXEDStatus: NEW => RESOLVEDCC: (none) => tmb