From lemenkov at gmail.com Tue Aug 12 00:52:22 2008 From: lemenkov at gmail.com (Peter Lemenkov) Date: Tue, 12 Aug 2008 11:52:22 +0400 Subject: [RTPproxy Devel] Solved. (Was: rtpproxy useless when built with -D_FORTIFY_SOURCE=2) Message-ID: Hello All! Just FYI, long time ago I found nasty issue with rtpproxy, compiled with -D_FORTIFY_SOURCE=2. ---------- Forwarded message ---------- From: Peter Lemenkov Date: 2008/2/20 Subject: rtpproxy useless when built with -D_FORTIFY_SOURCE=2 To: Maxim Sobolev Hello Max. I found that rtpproxy can't be built with -D_FORTIFY_SOURCE=2 which is a part of default CFLAGS in Fedora. Take a look at the appropriate buildlog http://koji.fedoraproject.org/packages/rtpproxy/1.1/0.1.beta.20071218.fc8/data/logs/x86_64/build.log Although build seems to be completed successfully openser can't find rtpproxy at all. ---------- -------------------- ---------- I just checked ver. 1.1 - this issue was gone! -- With best regards! From sobomax at sippysoft.com Tue Aug 12 14:46:18 2008 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Tue, 12 Aug 2008 14:46:18 -0700 Subject: [RTPproxy Devel] Solved. (Was: rtpproxy useless when built with -D_FORTIFY_SOURCE=2) In-Reply-To: References: Message-ID: <48A204AA.5030909@sippysoft.com> Peter Lemenkov wrote: > Hello All! > Just FYI, long time ago I found nasty issue with rtpproxy, compiled > with -D_FORTIFY_SOURCE=2. > > > ---------- Forwarded message ---------- > From: Peter Lemenkov > Date: 2008/2/20 > Subject: rtpproxy useless when built with -D_FORTIFY_SOURCE=2 > To: Maxim Sobolev > > > Hello Max. > I found that rtpproxy can't be built with -D_FORTIFY_SOURCE=2 which is > a part of default CFLAGS in Fedora. > > Take a look at the appropriate buildlog > > http://koji.fedoraproject.org/packages/rtpproxy/1.1/0.1.beta.20071218.fc8/data/logs/x86_64/build.log > > Although build seems to be completed successfully openser can't find > rtpproxy at all. > > ---------- -------------------- ---------- > > I just checked ver. 1.1 - this issue was gone! Nice to hear, thanks! We had tried to reproduce it some time ago, but failed. Therefore, I am not sure what was the reason in the first place. Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com From sobomax at sippysoft.com Wed Aug 13 18:17:08 2008 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Thu, 14 Aug 2008 03:17:08 +0200 (CEST) Subject: [RTPproxy Devel] CVS:commitlog: rtpproxy AUTHORS Message-ID: <20080814011708.0ADB514E03D@mail.berlios.de> sobomax 2008/08/14 03:17:08 CEST SER CVS Repository Modified files: . AUTHORS Log: 3rd test checkin to check commit log delivery. Revision Changes Path 1.4 +0 -0 rtpproxy/AUTHORS http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/AUTHORS.diff?r1=1.3&r2=1.4 From sobomax at sippysoft.com Wed Aug 13 18:40:52 2008 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Thu, 14 Aug 2008 03:40:52 +0200 (CEST) Subject: [RTPproxy Devel] CVS:commitlog: rtpproxy main.c rtp_server.c rtpp_command.c rtpp_defines.h rtpp_util.c rtpp_util.h Message-ID: <20080814014052.50C5612A83E@mail.berlios.de> sobomax 2008/08/14 03:40:52 CEST SER CVS Repository Modified files: . main.c rtp_server.c rtpp_command.c rtpp_defines.h rtpp_util.c rtpp_util.h Log: Implement random ports allocation. Basically, instead of allocating UDP ports sequentally as before this change, generate a random "path" through the available port range at startup. Then select a random port by simply skipping to the next port in that list of random ports. This should provide good resistance not only against RTP injections attacks but also against DOS attacks. DOS attack was possible if attacker could place a call through the proxy and observe port allocated for her own session. Then she could have generated flood of UDP packets to port numbers close to that port resulting in RTPproxy possibly "latching" attacker's IP instead of legitimate IPs of the new sessions' endpoints preventing RTP path from establishing. Submitted by: Tavis Paquette Peter Baer Revision Changes Path 1.82 +19 -10 rtpproxy/main.c http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/main.c.diff?r1=1.81&r2=1.82 1.9 +1 -2 rtpproxy/rtp_server.c http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/rtp_server.c.diff?r1=1.8&r2=1.9 1.17 +14 -23 rtpproxy/rtpp_command.c http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/rtpp_command.c.diff?r1=1.16&r2=1.17 1.17 +5 -2 rtpproxy/rtpp_defines.h http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/rtpp_defines.h.diff?r1=1.16&r2=1.17 1.10 +27 -1 rtpproxy/rtpp_util.c http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/rtpp_util.c.diff?r1=1.9&r2=1.10 1.11 +2 -1 rtpproxy/rtpp_util.h http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/rtpp_util.h.diff?r1=1.10&r2=1.11 From sobomax at sippysoft.com Wed Aug 13 18:49:20 2008 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Thu, 14 Aug 2008 03:49:20 +0200 (CEST) Subject: [RTPproxy Devel] CVS:commitlog: rtpproxy rtpp_defines.h Message-ID: <20080814014920.5F6E614E03D@mail.berlios.de> sobomax 2008/08/14 03:49:20 CEST SER CVS Repository Modified files: . rtpp_defines.h Log: Increase POLL_LIMIT from 100 to 200. This should cut additional jitter introduced by the RTPproxy in half, from 5ms on average to 2.5ms. Some UAs out there appear to be overly sensitive to jitter. Prompted by: Ronald Voermans Revision Changes Path 1.18 +2 -2 rtpproxy/rtpp_defines.h http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/rtpp_defines.h.diff?r1=1.17&r2=1.18