Resources.AlertsExamples HistoryHide minor edits - Show changes to output April 24, 2013, at 06:29 PM
by -
Changed lines 1-49 from:
!! Resources -> [[Resources.AlertsMain|OpenSIPS Alerts Service]] -> Examples (:toc-float Table of Content:) [[#Ex1]] ---- !!! Example 1 '''SVN commit''': http://opensips.svn.sourceforge.net/viewvc/opensips?view=revision&revision=7859 \\ '''Severity''': %red%High%% \\ '''Version''' : 1.6.4 only \\ '''Affected modules''' : ACC \\ '''Effect''' : OpenSIPS Crashes \\ '''Affected scenarios''': When using ACC module, with Dialog-based accounting (cdr_flag), in combination with data to be accounted larger than 128 chars. Typical scenario for this would be when in your OpenSIPS script you would like to also store the Contact fields for the Caller or Callee, and either of them supported [[http://tools.ietf.org/html/rfc5627 | GRUU ]]. Since the GRUU extension increases quite a lot the size of the actual Contact URI, it is very likely that the Contact would be larger than 128 bytes, and the bug would manifest itself with an OpenSIPS crash. \\ '''Description''' : The bug is a result of an integer overflow. When a field that needed to be stored in the accounting table ( be it one of the default fields, or an extra accounting one, or a per leg accounting field ) had a length greater than 128 bytes, OpenSIPS would overflow the size to a negative length for that field, thus subsequent operations for that field would result in a crash. \\ '''Risks''' : Since the bug affects a very simple and common scenario ( accounting ) and the bug can be exploited by %red%outside attackers%% ( by sending SIP packets with various very long fields), updating your sources is critical. \\ '''Update''' : If you have an SVN checkout , update from branch 1.6 for a revision later than 7859 ; If you have OpenSIPS from sources, download and apply the patch from [[http://opensips.svn.sourceforge.net/viewvc/opensips/branches/1.6/modules/acc/acc.c?r1=7859&r2=7858&pathrev=7859 | SVN ]] or see the attached patch. \\ [[#Ex2]] ---- !!! Example 2 '''SVN commit''': http://opensips.svn.sourceforge.net/viewvc/opensips?view=revision&revision=8628 \\ '''Severity''': %red%High%% \\ '''Version''' : 1.7 and below \\ '''Affected modules''' : CORE \\ '''Effect''' : Memory Corruption and eventually OpenSIPS Crash \\ '''Affected scenarios''': The bug is at a very low level and can affect a variety of scenarios involving changes over the message body - ranging from simply using the RTPProxy/MediaProxy or the Nathelper modules for NAT traversal, to simply modifying the message body from the OpenSIPS script, for various purposes ( codec stripping, etc ). This bug appears only when using UDP and when you handle a SIP message that advertises an Content-Lenght longer than the actual payload\\ '''Description''' : The bug relies in the fact that when getting the body of the SIP message, OpenSIPS relies entirely on the Content-Length header to get the body size. If the value in the Content-Length header is larger than the actual body of the SIP message, OpenSIPS will end up accesing invalid memory, and it can end up either in crashing or corrupting the memory. If the value is lower than the actual received body, then the end-result can be further malforming the SIP packet, since OpenSIPS will use wrong offsets when altering the SIP body. When receiving SIP messages on UDP, OpenSIPS can accurately determine the actual size of the SIP body, because it knows the size of the received Datagram from the UDP net, and this is what the fix is based on. \\ '''Risks''' : Since the bug can be exploited by %red%outside attackers%% ( by sending SIP packets with incorrect Content-Length headers ), updating your sources is critical. \\ '''Update''' : If you have an SVN checkout , update to a revision later than 8628 ; If you have OpenSIPS from sources, download and apply the patch from [[http://opensips.svn.sourceforge.net/viewvc/opensips?view=revision&revision=8628 | SVN ]] or see the attached patch. \\ [[#Ex3]] ---- !!! Example 3 '''SVN commit''': http://opensips.svn.sourceforge.net/viewvc/opensips?view=revision&revision=9081 \\ '''Severity''': Medium \\ '''Version''' : 1.8 \\ '''Affected modules''' : DROUTING \\ '''Effect''' : Failure to route to GWs \\ '''Affected Scenarios''' : The bug appears when using do_routing() function (that is supposed to return more than one gateway as possible destination for the given number) after you did changes over the RURI (either via other modules, either via script function - strip(), prefix() etc ). \\ '''Description''' : If the do_routing() call would result in multiple possible destinations for the matched prefix, the first Request URI would be ok, but the Request URIs for the next branches would become malformed. This is because OpenSIPS would internally use the wrong buffer for building the new Request URIs for the next branches. \\ '''Risks''' : The bug cannot be exploited by outside attackers, but since it's effect is the output of malformed SIP messages, it can affect the upstream routing, and thus updating is very important. \\ '''Update''' : If you have an SVN checkout , update to a revision later than 9081 ; If you have OpenSIPS from sources, download and apply the patch from [[http://opensips.svn.sourceforge.net/viewvc/opensips/branches/1.8/modules/drouting/drouting.c?r1=9081&r2=9080&pathrev=9081 | SVN ]] or see the attached patch. to:
(:redirect Support/Alerts-Examples quiet=1:) June 07, 2012, at 06:43 PM
by -
Changed line 45 from:
'''Effect''' : Malformed SIP messages \\ to:
'''Effect''' : Failure to route to GWs \\ June 07, 2012, at 06:42 PM
by -
Changed line 30 from:
'''Affected scenarios''': The bug is at a very low level and can affect a variety of scenarios, ranging from simply using the RTPProxy/MediaProxy or the Nathelper modules for NAT traversal, to simply modifying the message body from the OpenSIPS script, for various purposes ( codec stripping, etc ). \\ to:
'''Affected scenarios''': The bug is at a very low level and can affect a variety of scenarios involving changes over the message body - ranging from simply using the RTPProxy/MediaProxy or the Nathelper modules for NAT traversal, to simply modifying the message body from the OpenSIPS script, for various purposes ( codec stripping, etc ). This bug appears only when using UDP and when you handle a SIP message that advertises an Content-Lenght longer than the actual payload\\ Changed line 46 from:
'''Affected Scenarios''' : The bug appears when using the Dynamic Routing module in conjunction with any module ( like RR ) or script function ( strip(), prefix() etc ), that modifies the Request URI before the call to do_routing(). \\ to:
'''Affected Scenarios''' : The bug appears when using do_routing() function (that is supposed to return more than one gateway as possible destination for the given number) after you did changes over the RURI (either via other modules, either via script function - strip(), prefix() etc ). \\ June 07, 2012, at 06:18 PM
by -
Changed line 44 from:
'''Affected modules''' : DROUTING to:
'''Affected modules''' : DROUTING \\ Changed lines 46-47 from:
'''Affected Scenarios''' : The bug appears when using the Dynamic Routing module in conjunction with any module ( like RR ) or script function ( strip(), prefix() etc ), that modifies the Request URI before the call to do_routing(). '''Description''' : If the do_routing() call would result in multiple possible destinations for the matched prefix, the first Request URI would be ok, but the Request URIs for the next branches would become malformed. This is because OpenSIPS would internally use the wrong buffer for building the new Request URIs for the next branches. to:
'''Affected Scenarios''' : The bug appears when using the Dynamic Routing module in conjunction with any module ( like RR ) or script function ( strip(), prefix() etc ), that modifies the Request URI before the call to do_routing(). \\ '''Description''' : If the do_routing() call would result in multiple possible destinations for the matched prefix, the first Request URI would be ok, but the Request URIs for the next branches would become malformed. This is because OpenSIPS would internally use the wrong buffer for building the new Request URIs for the next branches. \\ Changed line 49 from:
'''Update''' : If you have an SVN checkout , update to a revision later than 9081 ; If you have OpenSIPS from sources, download and apply the patch from [[http://opensips.svn.sourceforge.net/viewvc/opensips/branches/1.8/modules/drouting/drouting.c?r1=9081&r2=9080&pathrev=9081 | SVN ]] or see the attached patch. \\ to:
'''Update''' : If you have an SVN checkout , update to a revision later than 9081 ; If you have OpenSIPS from sources, download and apply the patch from [[http://opensips.svn.sourceforge.net/viewvc/opensips/branches/1.8/modules/drouting/drouting.c?r1=9081&r2=9080&pathrev=9081 | SVN ]] or see the attached patch. June 07, 2012, at 06:18 PM
by -
Changed line 30 from:
'''Affected scenarios''': The bug is at a very low level and can affect a variety of scenarios, ranging from simply using the RTPProxy/MediaProxy or the Nathelper modules for NAT traversal, to simply modifying the message body from the OpenSIPS script, for various purposes ( codec stripping, etc ). to:
'''Affected scenarios''': The bug is at a very low level and can affect a variety of scenarios, ranging from simply using the RTPProxy/MediaProxy or the Nathelper modules for NAT traversal, to simply modifying the message body from the OpenSIPS script, for various purposes ( codec stripping, etc ). \\ Changed line 48 from:
'''Risks''' : The bug cannot be exploited by outside attackers, but since it's effect is the output of malformed SIP messages, it can affect the upstream routing, and thus updating is very important. to:
'''Risks''' : The bug cannot be exploited by outside attackers, but since it's effect is the output of malformed SIP messages, it can affect the upstream routing, and thus updating is very important. \\ June 07, 2012, at 06:17 PM
by -
Added line 30:
'''Affected scenarios''': The bug is at a very low level and can affect a variety of scenarios, ranging from simply using the RTPProxy/MediaProxy or the Nathelper modules for NAT traversal, to simply modifying the message body from the OpenSIPS script, for various purposes ( codec stripping, etc ). Changed line 33 from:
'''Risks''' : The bug is at a very low level and can affect a variety of scenarios, ranging from simply using the RTPProxy/MediaProxy or the Nathelper modules, to simply modifying the message body from the OpenSIPS script. Since the bug can be exploited by %red%outside attackers%% ( by sending SIP packets with incorrect Content-Length headers ), updating your sources is critical. \\ to:
'''Risks''' : Since the bug can be exploited by %red%outside attackers%% ( by sending SIP packets with incorrect Content-Length headers ), updating your sources is critical. \\ Deleted lines 36-37:
Changed lines 41-42 from:
'''SVN commit''': http://opensips.svn.sourceforge.net/viewvc/opensips?view=revision&revision=8628 \\ '''Severity''': Low \\ to:
'''SVN commit''': http://opensips.svn.sourceforge.net/viewvc/opensips?view=revision&revision=9081 \\ '''Severity''': Medium \\ Changed lines 46-49 from:
'''Description''' : The bug appears when using the Dynamic Routing module in conjunction with any module or script function that modifies the Request URI before the call to do_routing(). In such a case, if the do_routing() call would result in multiple possible destinations for the matched prefix, the first Request URI would be ok, but the Request URIs for the next branches to:
'''Affected Scenarios''' : The bug appears when using the Dynamic Routing module in conjunction with any module ( like RR ) or script function ( strip(), prefix() etc ), that modifies the Request URI before the call to do_routing(). '''Description''' : If the do_routing() call would result in multiple possible destinations for the matched prefix, the first Request URI would be ok, but the Request URIs for the next branches would become malformed. This is because OpenSIPS would internally use the wrong buffer for building the new Request URIs for the next branches. '''Risks''' : The bug cannot be exploited by outside attackers, but since it's effect is the output of malformed SIP messages, it can affect the upstream routing, and thus updating is very important. '''Update''' : If you have an SVN checkout , update to a revision later than 9081 ; If you have OpenSIPS from sources, download and apply the patch from [[http://opensips.svn.sourceforge.net/viewvc/opensips/branches/1.8/modules/drouting/drouting.c?r1=9081&r2=9080&pathrev=9081 | SVN ]] or see the attached patch. \\ June 07, 2012, at 05:49 PM
by -
Changed lines 40-47 from:
!!! Example 3 to:
!!! Example 3 '''SVN commit''': http://opensips.svn.sourceforge.net/viewvc/opensips?view=revision&revision=8628 \\ '''Severity''': Low \\ '''Version''' : 1.8 \\ '''Affected modules''' : DROUTING '''Effect''' : Malformed SIP messages \\ '''Description''' : The bug appears when using the Dynamic Routing module in conjunction with any module or script function that modifies the Request URI before the call to do_routing(). In such a case, if the do_routing() call would result in multiple possible destinations for the matched prefix, the first Request URI would be ok, but the Request URIs for the next branches June 07, 2012, at 04:28 PM
by -
Deleted line 30:
June 07, 2012, at 04:28 PM
by -
Changed lines 31-32 from:
When receiving SIP messages on UDP, OpenSIPS can accurately determine the actual size of the SIP body, because it knows the size of the received Datagram from the UDP net, and this is what the fix is based on. to:
When receiving SIP messages on UDP, OpenSIPS can accurately determine the actual size of the SIP body, because it knows the size of the received Datagram from the UDP net, and this is what the fix is based on. \\ June 07, 2012, at 04:27 PM
by -
Changed line 31 from:
When receiving SIP messages on UDP, OpenSIPS can accurately determine the actual size of the SIP body, because it knows the size of the received Datagram from the UDP net, and this is what the fix is based on. to:
When receiving SIP messages on UDP, OpenSIPS can accurately determine the actual size of the SIP body, because it knows the size of the received Datagram from the UDP net, and this is what the fix is based on. June 07, 2012, at 04:26 PM
by -
Changed lines 25-33 from:
to:
'''SVN commit''': http://opensips.svn.sourceforge.net/viewvc/opensips?view=revision&revision=8628 \\ '''Severity''': %red%High%% \\ '''Version''' : 1.7 and below \\ '''Affected modules''' : CORE \\ '''Effect''' : Memory Corruption and eventually OpenSIPS Crash \\ '''Description''' : The bug relies in the fact that when getting the body of the SIP message, OpenSIPS relies entirely on the Content-Length header to get the body size. If the value in the Content-Length header is larger than the actual body of the SIP message, OpenSIPS will end up accesing invalid memory, and it can end up either in crashing or corrupting the memory. If the value is lower than the actual received body, then the end-result can be further malforming the SIP packet, since OpenSIPS will use wrong offsets when altering the SIP body. When receiving SIP messages on UDP, OpenSIPS can accurately determine the actual size of the SIP body, because it knows the size of the received Datagram from the UDP net, and this is what the fix is based on. '''Risks''' : The bug is at a very low level and can affect a variety of scenarios, ranging from simply using the RTPProxy/MediaProxy or the Nathelper modules, to simply modifying the message body from the OpenSIPS script. Since the bug can be exploited by %red%outside attackers%% ( by sending SIP packets with incorrect Content-Length headers ), updating your sources is critical. \\ '''Update''' : If you have an SVN checkout , update to a revision later than 8628 ; If you have OpenSIPS from sources, download and apply the patch from [[http://opensips.svn.sourceforge.net/viewvc/opensips?view=revision&revision=8628 | SVN ]] or see the attached patch. \\ June 07, 2012, at 03:50 PM
by -
Changed line 10 from:
'''SVN commit''': http://opensips.svn.sourceforge.net/viewvc/opensips?view=revision&revision=7858 \\ to:
'''SVN commit''': http://opensips.svn.sourceforge.net/viewvc/opensips?view=revision&revision=7859 \\ Changed line 15 from:
'''Affected scenarios''': When using ACC module, with Dialog-based accounting (cdr_flag), in combination with data to be accounted larger than 16 chars. Typical scenario for this would be when in your OpenSIPS script you would like to also store the Contact fields for the Caller or Callee, and either of them supported [[http://tools.ietf.org/html/rfc5627 | GRUU ]]. Since the GRUU extension increases quite a lot the size of the actual Contact URI, it is very likely that the Contact would be larger than 128 bytes, and the bug would manifest itself with an OpenSIPS crash. \\ to:
'''Affected scenarios''': When using ACC module, with Dialog-based accounting (cdr_flag), in combination with data to be accounted larger than 128 chars. Typical scenario for this would be when in your OpenSIPS script you would like to also store the Contact fields for the Caller or Callee, and either of them supported [[http://tools.ietf.org/html/rfc5627 | GRUU ]]. Since the GRUU extension increases quite a lot the size of the actual Contact URI, it is very likely that the Contact would be larger than 128 bytes, and the bug would manifest itself with an OpenSIPS crash. \\ June 07, 2012, at 03:46 PM
by -
Changed lines 13-24 from:
'''Affected modules''' : ACC '''Effect''' : OpenSIPS Crashes '''Affected scenarios''': When using ACC module, with Dialog-based accounting (cdr_flag), in combination with data to be accounted larger than 16 chars. Typical scenario for this would be when in your OpenSIPS script you would like to also store the Contact fields for the Caller or Callee, and either of them supported [[http://tools.ietf.org/html/rfc5627 | GRUU ]]. Since the GRUU extension increases quite a lot the size of the actual Contact URI, it is very likely that the Contact would be larger than 128 bytes, and the bug would manifest itself with an OpenSIPS crash. '''Description''' : The bug is a result of an integer overflow. When a field that needed to be stored in the accounting table ( be it one of the default fields, or an extra accounting one, or a per leg accounting field ) had a length greater than 128 bytes, OpenSIPS would overflow the size to a negative length for that field, thus subsequent operations for that field would result in a crash. '''Risks''' : Since the bug affects a very simple and common scenario ( accounting ) and the bug can be exploited by %red%outside attackers%% ( by sending SIP packets with various very long fields), updating your sources is critical. '''Update''' : If you have an SVN checkout , update from branch 1.6 for a revision later than 7859 ; If you have OpenSIPS from sources, download and apply the patch from [[http://opensips.svn.sourceforge.net/viewvc/opensips/branches/1.6/modules/acc/acc.c?r1=7859&r2=7858&pathrev=7859 | SVN ]] or see the attached patch. to:
'''Affected modules''' : ACC \\ '''Effect''' : OpenSIPS Crashes \\ '''Affected scenarios''': When using ACC module, with Dialog-based accounting (cdr_flag), in combination with data to be accounted larger than 16 chars. Typical scenario for this would be when in your OpenSIPS script you would like to also store the Contact fields for the Caller or Callee, and either of them supported [[http://tools.ietf.org/html/rfc5627 | GRUU ]]. Since the GRUU extension increases quite a lot the size of the actual Contact URI, it is very likely that the Contact would be larger than 128 bytes, and the bug would manifest itself with an OpenSIPS crash. \\ '''Description''' : The bug is a result of an integer overflow. When a field that needed to be stored in the accounting table ( be it one of the default fields, or an extra accounting one, or a per leg accounting field ) had a length greater than 128 bytes, OpenSIPS would overflow the size to a negative length for that field, thus subsequent operations for that field would result in a crash. \\ '''Risks''' : Since the bug affects a very simple and common scenario ( accounting ) and the bug can be exploited by %red%outside attackers%% ( by sending SIP packets with various very long fields), updating your sources is critical. \\ '''Update''' : If you have an SVN checkout , update from branch 1.6 for a revision later than 7859 ; If you have OpenSIPS from sources, download and apply the patch from [[http://opensips.svn.sourceforge.net/viewvc/opensips/branches/1.6/modules/acc/acc.c?r1=7859&r2=7858&pathrev=7859 | SVN ]] or see the attached patch. \\ June 07, 2012, at 03:46 PM
by -
Changed lines 10-12 from:
'''SVN commit''': http://opensips.svn.sourceforge.net/viewvc/opensips?view=revision&revision=7858 '''Severity''': %red%High%% '''Version''' : 1.6.4 only to:
'''SVN commit''': http://opensips.svn.sourceforge.net/viewvc/opensips?view=revision&revision=7858 \\ '''Severity''': %red%High%% \\ '''Version''' : 1.6.4 only \\ June 07, 2012, at 03:46 PM
by -
Changed lines 10-11 from:
'''SVN commit''': http://opensips.svn.sourceforge.net/viewvc/opensips?view=revision&revision=7858 \ '''Severity''': %red%High%% \ to:
'''SVN commit''': http://opensips.svn.sourceforge.net/viewvc/opensips?view=revision&revision=7858 '''Severity''': %red%High%% June 07, 2012, at 03:45 PM
by -
Changed lines 10-13 from:
'''SVN commit''': http://opensips.svn.sourceforge.net/viewvc/opensips?view=revision&revision=7858 '''Severity''': %red%High%% to:
'''SVN commit''': http://opensips.svn.sourceforge.net/viewvc/opensips?view=revision&revision=7858 \ '''Severity''': %red%High%% \ June 07, 2012, at 03:45 PM
by -
Changed lines 10-11 from:
to:
'''SVN commit''': http://opensips.svn.sourceforge.net/viewvc/opensips?view=revision&revision=7858 '''Severity''': %red%High%% '''Version''' : 1.6.4 only '''Affected modules''' : ACC '''Effect''' : OpenSIPS Crashes '''Affected scenarios''': When using ACC module, with Dialog-based accounting (cdr_flag), in combination with data to be accounted larger than 16 chars. Typical scenario for this would be when in your OpenSIPS script you would like to also store the Contact fields for the Caller or Callee, and either of them supported [[http://tools.ietf.org/html/rfc5627 | GRUU ]]. Since the GRUU extension increases quite a lot the size of the actual Contact URI, it is very likely that the Contact would be larger than 128 bytes, and the bug would manifest itself with an OpenSIPS crash. '''Description''' : The bug is a result of an integer overflow. When a field that needed to be stored in the accounting table ( be it one of the default fields, or an extra accounting one, or a per leg accounting field ) had a length greater than 128 bytes, OpenSIPS would overflow the size to a negative length for that field, thus subsequent operations for that field would result in a crash. '''Risks''' : Since the bug affects a very simple and common scenario ( accounting ) and the bug can be exploited by %red%outside attackers%% ( by sending SIP packets with various very long fields), updating your sources is critical. '''Update''' : If you have an SVN checkout , update from branch 1.6 for a revision later than 7859 ; If you have OpenSIPS from sources, download and apply the patch from [[http://opensips.svn.sourceforge.net/viewvc/opensips/branches/1.6/modules/acc/acc.c?r1=7859&r2=7858&pathrev=7859 | SVN ]] or see the attached patch. June 07, 2012, at 03:33 PM
by -
Changed line 6 from:
to:
[[#Ex1]] Added lines 10-14:
[[#Ex2]] Added lines 18-23:
[[#Ex3]] June 07, 2012, at 03:31 PM
by -
Added lines 1-14:
!! Resources -> [[Resources.AlertsMain|OpenSIPS Alerts Service]] -> Examples (:toc-float Table of Content:) ---- !!! Example 1 ---- !!! Example 2 ---- !!! Example 3 |