GNOME Bugzilla – Bug 529082
Remote denial of service
Last modified: 2011-01-25 09:23:56 UTC
It is possible to cause a crash in Ekiga by sending a SIP request with exceptionally long elements in the From field that get displayed to the user when a notification for an incoming call is created. The following output is produced nnp@ubuntu:~$ ekiga The program 'ekiga' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAlloc (insufficient resources for operation)'. (Details: serial 2017 error_code 11 request_code 53 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Segmentation fault (core dumped)
Created attachment 109592 [details] Proof of concept This python script should recreate the issue. Run it as follows python ekiga_dos.py IP PORT
I confirm this bug. Start ekiga and execute "python ekiga_dos.py myIPaddr 5060". It's a bug in opal, SVN included. For me, at least, the problem is not that the From field is long (I removed nearly all the 'B'), but that GetSDP sees that sdp is null, hence it triggers this assertion error. File opal/src/sip/sipcon.cxx, function SIPConnection::GetMediaFormats, line SDPSessionDescription & sdp = originalInvite->GetSDP();
*** Bug 548686 has been marked as a duplicate of this bug. ***
Well, I can not reproduce the problem here. (there is a SDP). Having a NULL SDP in an incoming INVITE is not normal, so printing an asserting is not that bad.
I tested version from 30/08, and there was no crash anymore. Yannick
I can't crash it either. But I saw (dunno if that's related to something else, so feel free to open another bugreport): - once you click "Accept" in the desktop notify thing (which fails, clear), then you can't call it with that thing anymore. I don't have a possibility to test if that's a general issue or not, now. Again: The crash per se doesn't happen.
Tested with current master: no crash, can call 500 afterwards, 520 too. If you refuse the call, you have to wait 10-20 seconds, since ekiga tries to send the answer, which is too big for an UDP packet (33kB), until timeout. So closing.