[Devel] [ openser-Bugs-1537245 ] mod_mangle crash

SourceForge.net noreply at sourceforge.net
Fri Mar 16 14:58:29 CET 2007


Bugs item #1537245, was opened at 2006-08-09 09:26
Message generated for change (Comment added) made by henningw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1537245&group_id=139143

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: ver 1.1.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Daniel-Constantin Mierla (miconda)
Summary: mod_mangle crash

Initial Comment:
mailto:michal.kara at nextiraone.cz

I am expiriencing crash that seems to happen when 
mod_mediaproxy's fix_contact() rewrites contact and I 
subsequently call encode_contact(). When fix_contact() 
is called but contact is not changed, all works OK. 
This bug has been there since 0.9.x.

Log:
 0(14215) SIP Request:
 0(14215)  method:  <INVITE>
 0(14215)  uri:     <sip:zdenek at 10.245.155.174>
 0(14215)  version: <SIP/2.0>
 0(14215) parse_headers: flags=2
 0(14215) Found param type 232, <branch> = <z9hG4bK-
d87543-767618259b786972-1--d87543->; state=6
 0(14215) Found param type 235, <rport> = <n/a>; 
state=17
 0(14215) end of header reached, state=5
 0(14215) parse_headers: Via found, flags=2
 0(14215) parse_headers: this is the first via
 0(14215) After parse_msg...
 0(14215) preparing to run routing scripts...
 0(14215) parse_headers: flags=100
 0(14215) DEBUG:maxfwd:is_maxfwd_present: value = 70
 0(14215) LOG: uri=sip:zdenek at 10.245.155.174
 0(14215) parse_headers: flags=80
 0(14215) LOG: Someone trying to register from private 
IP, rewriting
 0(14215) parse_headers: flags=80
 0(14215) parse_headers: flags=8000000
 0(14215) DEBUG:parse_to:end of header reached, 
state=10
 0(14215) DBUG:parse_to: display={}, ruri=
{sip:zdenek at 10.245.155.174}
 0(14215) DEBUG: get_hdr_field: <To> [29]; uri=
[sip:zdenek at 10.245.155.174]
 0(14215) DEBUG: to body [<sip:zdenek at 10.245.155.174>
]
 0(14215) get_hdr_field: cseq <CSeq>: <1> <INVITE>
 0(14215) BUG: del_lump: offset exceeds message size 
(239840 > 938) aborting...


Here's backtrace:

(gdb) bt
#0  0x4005a7c1 in kill () from /lib/libc.so.6
#1  0x4005a545 in raise () from /lib/libc.so.6
#2  0x4005ba88 in abort () from /lib/libc.so.6
#3  0x08053d8c in del_lump (msg=0x81279d0, 
offset=239840, len=30,
    type=HDR_OTHER_T) at data_lump.c:288
#4  0x40221e97 in patch (msg=0x6, oldstr=0x0, oldlen=0,
    
newstr=0x81246a8 "sip:encoded*michal**10.245.64.193*621
11*@62.141.0.225",
    newlen=0) at utils.c:53
#5  0x4021e5a1 in encode_contact (msg=0x81279d0,
    encoding_prefix=0x8125770 "encoded", 
public_ip=0x81257f8 "62.141.0.225")
    at contact_ops.c:114
#6  0x0805071b in do_action (a=0x8125880, 
msg=0x81279d0) at action.c:701
#7  0x08050631 in do_action (a=0x81258b0, 
msg=0x81279d0) at action.c:89
#8  0x08050631 in do_action (a=0x8125940, 
msg=0x81279d0) at action.c:89
#9  0x08050631 in do_action (a=0x8125970, 
msg=0x81279d0) at action.c:89
#10 0x080522c2 in run_actions (a=0x81247e0, 
msg=0x81279d0) at action.c:89
#11 0x08051f2e in run_top_route (a=0x0, msg=0x0) at 
action.c:151
#12 0x08071ec1 in receive_msg (
    buf=0x80ea340 "INVITE sip:zdenek at 10.245.155.174 
SIP/2.0\r\nVia: SIP/2.0/UDP
192.168.0.2:8286;branch=z9hG4bK-d87543-
2d69a52d124c2029-1--d87543-;rport\r\nMax-
Forwards: 69\r\nContact: 
<sip:michal at 192.168.0.2:8286>\r\nTo: <sip:"...,
    len=938, rcv_info=0xbffffbb0) at receive.c:155
#13 0x08089654 in udp_rcv_loop () at udp_server.c:465
---Type <return> to continue, or q <return> to quit---
#14 0x08063b64 in main_loop () at main.c:925
#15 0x08064fae in main (argc=7, argv=0xbffffd34) at 
main.c:1477

Configuration file snippet:

...

# main routing logic
route{

...

  if ((src_ip != 10.245.155.174) && (client_nat_test
("3"))) {
    if (method == "REGISTER" || ! search("^Record-
Route:")) {
      fix_contact(); # Rewrite contact with source IP 
of signalling

      if (method == "INVITE") {
          encode_contact("encoded","62.141.0.225");
      };

...

}

...



----------------------------------------------------------------------

Comment By: Henning Westerholt (henningw)
Date: 2007-03-16 13:58

Message:
Logged In: YES 
user_id=337916
Originator: NO

Communication with bug reporter:

> Problem solved with internal patch.
> If it is a feature of the lump system that it is impossible to rewrite
> a url more than once, than this could be closed. 

Perhaps then we should then document this?


----------------------------------------------------------------------

Comment By: Daniel-Constantin Mierla (miconda)
Date: 2006-08-14 09:37

Message:
Logged In: YES 
user_id=1246013

It is possible to rewrite same field twice or more, the new
values will be concatenated. See on the mailing list issues
related to calling twise force_rtp_proxy().

To have the proxy in the path of dialog request you must use
Record Route mechanism (see rr module). Many of us do NAT
traversal in their paltforms and usage of mangler module is
not necessary.

However, OpenSER should not crash - this module has to be
fixed or removed (if no longer necessary).

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2006-08-10 12:07

Message:
Logged In: NO 

The bug is 100% reproducible.

To explain what I am doing: I have a client (eyeBeam) 
behind NAT that is using my proxy. I use openser in 
conjunction with MediaProxy, so I have mediaproxy module 
loaded.

When client makes a call, there's his private address in 
the Contact: field. I rewrite this contact with the 
fix_contact() function of the mediaproxy module. That puts 
there IP and port his packets are really comming from.

But that's not enough. A packet will go back to the client 
through the NAT _only_ when it is sent from the proxy. So, 
for example, sending BYE to this contact by remote endpoint 
does not work. What I have to do is encode the original 
contact information and put proxy IP in it. This way, the 
BYE command will reach the proxy, which will decode back 
the uri and use it to forward the request.

So I have to first fix the contact and then encode it. The 
problem is, that fix_contact() allocates new memory for 
fixed contact and this memory is placed (of course) after 
msg->buf + msg->len. Then when the mangle module wants to 
rewrite the contact again, it cannot delete lump created by 
the fix_contact() function, since offset of the data is too 
high.

>From the impression I got now the bug is not directly 
related to neither mediaproxy not mangle module, but it is 
rather a (design?) bug in the lump system, because it seems 
it is not possible to rewrite single field twice during the 
same processing.


----------------------------------------------------------------------

Comment By: Daniel-Constantin Mierla (miconda)
Date: 2006-08-10 09:32

Message:
Logged In: YES 
user_id=1246013

It seem to be some data corrupted. The offset to del_lump is
for sure greater than the whole message. Also, the
parameters  to patch() function are null and there is a test
for such values. It might be that the core file was overwritten.

Could this crash be reproduced in an easy way, or is it a
rare event.

On the other hand, mangler is a bit deprecated, you can use
nathelper to change the contact addresses and perform NAT
traversal.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2006-08-09 11:37

Message:
Logged In: NO 

I have investigated this problem futher. As far as I 
understand the "lump" system, it seems to be more design 
problem - it is not possible to delete lump that was added, 
just one that was originally present. Am I right?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1537245&group_id=139143



More information about the Devel mailing list