[Home]

Summary:ASTERISK-07695: [patch] Transfer capability is inherited by a channel after being transfered via atxfer
Reporter:k-egg (k-egg)Labels:
Date Opened:2006-09-08 06:37:41Date Closed:2008-01-18 11:13:47.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_dial
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) dial.diff
( 1) transfer-fix-b14-r97657.diff
( 2) transfer-fix-trunk-r97657.diff
Description:PhoneA calls PhoneB (221)
by Dial("mISDN/12-1", "mISDN/1/221|15|tr")
PhoneA is not allowed to initiate transfers at that time.
PhoneB is allowed to.

PhoneB transfers PhoneA to PhoneC(208) (attended trans)
by Dial("Local/208@isdn-nt-1-bcec,2", "mISDN/8/208|15|")

now PhoneA now is allowed to initiate transfers:

for example:
exten => 1,1,Playback(tt-monkeys)
cli output:
- Started music on hold, class 'default', on Local/208@isdn-nt-1-bcec,1
   -- Playing 'pbx-transfer' (language 'de')
   -- Executing Playback("Local/1@macro-dial_intern-e687,2", "tt-monkeys") in new stack
   -- Playing 'tt-monkeys' (language 'en')



Is this a bug? a feature? or designed to behave like this?
wondering...

kegg
Comments:By: Serge Vecher (serge-v) 2006-09-12 10:54:28

the phones are prohibited/allowed to make a transfer by which mechanism?
By: k-egg (k-egg) 2006-09-12 10:59:26

okay, i dont think, that i get your question rightbut i think you are asking for that:

by dialing *8 for supervised transfer
By: k-egg (k-egg) 2006-09-12 11:03:56

no i got it wrong.

ahm...

prohibited allowed by which mechanism.
ahm the Application DIAL!?!

DIAL(..|options)
otions can contain t or T which allows a caller/calle to do transfers

so B has the capability of doing transfers, A is an external caller and shouldnt be able do make internal transfers. but when he is transfered once, he is able to make internal transfers
By: Serge Vecher (serge-v) 2006-09-13 11:02:49

Ok, gotcha. I think this is the way it works... I think the asterisk-dev mailing list is a better forum for whether this needs to change or not...
By: k-egg (k-egg) 2006-09-18 04:39:04

hmm nobody at -dev seems to be interested?
any ideas how to make them beeing interested?
By: k-egg (k-egg) 2006-09-25 02:22:29

seems nobody wants to alter this behaviour... or i did something wrong.
so maybe somebody listens to you, if you would ask to discuss this behaviour?

regards
kegg
By: jmls (jmls) 2006-11-01 12:46:39.000-0600

I think you should try -dev one more time. If no success, I would suggest that this is closed
By: k-egg (k-egg) 2006-11-02 04:39:03.000-0600

could cou do me a favour?
could you try on -dev?
sometimes it seems that post from my timzone are not read by ppl from "the other" timezone.

thx
Kegg
By: Tilghman Lesher (tilghman) 2006-11-30 02:16:22.000-0600

This is definitely a bug.  There's a security issue with this.
By: k-egg (k-egg) 2006-11-30 02:20:11.000-0600

thank god it's thursday. somebody read my bug!!! and understood the prob!
there must be a bug-god!
By: Anthony LaMantia (alamantia) 2006-12-01 15:03:11.000-0600

what type channel is PhoneA connecting from in the situation that you describe?
By: Anthony LaMantia (alamantia) 2006-12-01 15:04:09.000-0600

also, can you provide the relevent dialplan and .conf snippits to this entry to assist with solving the problem?
By: Serge Vecher (serge-v) 2006-12-01 15:46:08.000-0600

from 'additional information', phones A and B are ISDN phones, but this is probably a channel independent problem.
By: Anthony LaMantia (alamantia) 2006-12-01 16:56:37.000-0600

from what i can see only b and c are misdn, it's pretty safe to assume that a is as well. but i would like to be sure.


By: Anthony LaMantia (alamantia) 2006-12-01 18:24:25.000-0600

can you please apply this patch to your 1.2(svn) copy of asterisk, and see if this situation is duplicating itself,

this is not the final fix for the issue but i would be very helpful to know if it prevents PhoneA from inheriting the transfer capability.


By: Anthony LaMantia (alamantia) 2006-12-01 18:41:55.000-0600

it would also be great if you could provide a console debug log as well.
By: k-egg (k-egg) 2006-12-02 10:39:54.000-0600

okay, now i run into trouble. i dont have acces to that machine at the moment.
maybe i can test this at the end of upcoming week or the week after. sorry
By: Anthony LaMantia (alamantia) 2006-12-04 11:22:59.000-0600

ok, we shall wait till then.
By: k-egg (k-egg) 2006-12-11 04:00:37.000-0600

okay.. puh, not easy to re-creat this situation, cause i altered the DialPlan since then.

But i learned, that the best way to debug asterisk-problems is to creata an "as easy as possible" dialplan. so this is what i did.

my actual dialplan looks like this:

[isdn-te-ptmp]
exten => _X.,1,Dial(mISDN/8/208||t)

[isdn-nt]
exten => 201,1,Dial(mISDN/1/201)


i found out that, if i change the transfer-capability
  exten => 201,1,Dial(mISDN/1/201,,t)

then everything works as expected, the external caller is not allowed to transfer.


but when i don't change transfer-capability by just dialing
 exten => 201,1,Dial(mISDN/1/201)

then the "bug" is there

this ist still without the patch!!!

(will post results in a new comment)
By: k-egg (k-egg) 2006-12-11 04:10:08.000-0600

btw: the problem accures only on atxfer
By: k-egg (k-egg) 2006-12-11 04:36:37.000-0600

mISDN/9 (Adam) is from extern, and routed to mISDN/8/208 (Bob)
208 (Bob) transfers (atxfer) to 201 (Eve).
Adam transfers himself back to Bob (which he should be allowed to)


this is the cli output of this situation:

*CLI>
   -- Executing Dial("mISDN/9-1", "mISDN/8/208||t") in new stack
   -- DEBUG: chan->transfercapability  _not inherited_
   -- Called 8/208
   -- mISDN/8-u4 is ringing
   -- mISDN/8-u4 answered mISDN/9-1
   -- Started music on hold, class 'default', on channel 'mISDN/9-1'
   -- Playing 'pbx-transfer' (language 'de')
   -- Stopped music on hold on mISDN/9-1
   -- Executing Dial("Local/201@isdn-nt-a7c4,2", "mISDN/1/201") in new stack
   -- DEBUG: chan->transfercapability  _not inherited_
   -- Called 1/201
   -- mISDN/1-u5 is ringing
   -- Local/201@isdn-nt-a7c4,1 is ringing
   -- mISDN/1-u5 answered Local/201@isdn-nt-a7c4,2
Dec 11 11:18:37 NOTICE[17394]: res_features.c:1171 ast_feature_request_and_dial: Don't know what to do about control frame: -1
   -- Playing 'beep' (language 'en')
 == Spawn extension (isdn-te-ptmp, 75203, 2) exited non-zero on 'Transfered/mISDN/9-1<ZOMBIE>'
   -- Started music on hold, class 'default', on channel 'Local/201@isdn-nt-a7c4,1'
   -- Playing 'pbx-transfer' (language 'de')
   -- Stopped music on hold on Local/201@isdn-nt-a7c4,1
   -- Executing Dial("Local/208@isdn-te-ptmp-df3d,2", "mISDN/8/208||t") in new stack
   -- DEBUG chan->transfercapability  _not inherited_
   -- Called 8/208
   -- mISDN/8-u6 is ringing
   -- Local/208@isdn-te-ptmp-df3d,1 is ringing
   -- mISDN/8-u6 answered Local/208@isdn-te-ptmp-df3d,2

-------------
show channels

incoming call:
   -- Executing Dial("mISDN/9-2", "mISDN/8/208||t") in new stack
   --  chan->transfercapability  _not inherited_
   -- Called 8/208
   -- mISDN/8-u7 is ringing
   -- mISDN/8-u7 answered mISDN/9-2
--
mISDN/8-u7           208@isdn-nt:1        Up      Bridged Call(mISDN/9-2)
mISDN/9-2            75203@isdn-te-ptmp:2 Up      Dial(mISDN/8/208||t)
2 active channels
1 active call

--
bob transfers to eve


   -- Started music on hold, class 'default', on channel 'mISDN/9-2'
   -- Playing 'pbx-transfer' (language 'de')
Dec 11 11:30:31 WARNING[17299]: res_musiconhold.c:712 moh_generate: Only doing 2624 of 6398 requested bytes on mISDN/9-2
   -- Stopped music on hold on mISDN/9-2
   -- Executing Dial("Local/201@isdn-nt-b455,2", "mISDN/1/201") in new stack
   --  chan->transfercapability  _not inherited_
   -- Called 1/201
   -- mISDN/1-u8 is ringing
   -- Local/201@isdn-nt-b455,1 is ringing
   -- mISDN/1-u8 answered Local/201@isdn-nt-b455,2
Dec 11 11:30:36 NOTICE[17457]: res_features.c:1171 ast_feature_request_and_dial: Don't know what to do about control frame: -1

*CLI>
*CLI> show channels
Channel              Location             State   Application(Data)
mISDN/1-u8           201@isdn-nt:1        Up      Bridged Call(Local/201@isdn-nt
Local/201@isdn-nt-b4 201@isdn-nt:1        Up      Dial(mISDN/1/201)
Local/201@isdn-nt-b4 s@isdn-nt:1          Up      Bridged Call(mISDN/8-u7)
mISDN/8-u7           208@isdn-nt:1        Up      Bridged Call(mISDN/9-2)
mISDN/9-2            75203@isdn-te-ptmp:2 Up      Dial(mISDN/8/208||t)
5 active channels
2 active calls

----

bob hangs up:

   -- Playing 'beep' (language 'en')
 == Spawn extension (isdn-te-ptmp, 75203, 2) exited non-zero on 'Transfered/mISDN/9-2<ZOMBIE>'
show channels
Channel              Location             State   Application(Data)
mISDN/9-2            75203@isdn-te-ptmp:2 Up      Bridged Call(Local/201@isdn-nt
mISDN/1-u8           201@isdn-nt:1        Up      Bridged Call(Local/201@isdn-nt
Local/201@isdn-nt-b4 201@isdn-nt:1        Up      Dial(mISDN/1/201)
Local/201@isdn-nt-b4 s@isdn-nt:1          Up      Transferred Call(mISDN/9-2)
4 active channels
1 active call

-----
adam transfers himself back to bob:

   -- Started music on hold, class 'default', on channel 'Local/201@isdn-nt-b98e,1'
   -- Playing 'pbx-transfer' (language 'de')
   -- Stopped music on hold on Local/201@isdn-nt-b98e,1
   -- Executing Dial("Local/208@isdn-te-ptmp-3ae1,2", "mISDN/8/208||t") in new stack
   --  chan->transfercapability  _not inherited_
   -- Called 8/208
   -- mISDN/8-u12 is ringing
   -- Local/208@isdn-te-ptmp-3ae1,1 is ringing
   -- mISDN/8-u12 answered Local/208@isdn-te-ptmp-3ae1,2
Dec 11 11:33:42 NOTICE[17570]: res_features.c:1171 ast_feature_request_and_dial: Don't know what to do about co

eve is still up:
Channel              Location             State   Application(Data)
mISDN/8-u12          208@isdn-nt:1        Up      Bridged Call(Local/208@isdn-te
Local/208@isdn-te-pt 208@isdn-te-ptmp:2   Up      Dial(mISDN/8/208||t)
Local/208@isdn-te-pt s@isdn-te-ptmp:1     Up      Bridged Call(mISDN/9-1)
mISDN/9-1            75203@isdn-te-ptmp:2 Up      Bridged Call(Local/201@isdn-nt
mISDN/1-u11          201@isdn-nt:1        Up      Bridged Call(Local/201@isdn-nt
Local/201@isdn-nt-b9 201@isdn-nt:1        Up      Dial(mISDN/1/201)
Local/201@isdn-nt-b9 s@isdn-nt:1          Up      Transferred Call(mISDN/9-1)
7 active channels
2 active calls

eve hangs up:
*CLI> show channels
Channel              Location             State   Application(Data)
mISDN/8-u12          208@isdn-nt:1        Up      Bridged Call(Local/208@isdn-te
Local/208@isdn-te-pt 208@isdn-te-ptmp:2   Up      Dial(mISDN/8/208||t)
Local/208@isdn-te-pt s@isdn-te-ptmp:1     Up      Bridged Call(mISDN/9-1)
mISDN/9-1            75203@isdn-te-ptmp:2 Up      Bridged Call(Local/201@isdn-nt
Local/201@isdn-nt-b9 s@isdn-nt:1          Up      Transferred Call(mISDN/9-1)
5 active channels
1 active call
By: k-egg (k-egg) 2006-12-11 04:39:17.000-0600

i hope this helps to find the problem.

access to machine is still not possibel each day, but i'll try to rebuild situation at home.


By: Anthony LaMantia (alamantia) 2006-12-12 15:26:48.000-0600

thanks for the logs, i'm currently re-working the patch for this issue, and hopefully will have a new one uploaded rather soon.
By: k-egg (k-egg) 2006-12-13 03:38:59.000-0600

You'r welcome.

Got an idea where to search for the bug?
By: Anthony LaMantia (alamantia) 2006-12-13 15:19:00.000-0600

somewhat, im experimenting with it a tad to be sure.
By: Serge Vecher (serge-v) 2007-02-28 14:21:07.000-0600

hmm, a high priority bug grew a 6-month beard
By: k-egg (k-egg) 2007-02-28 15:50:52.000-0600

serge-v, xou cant say that its was only since  11-30-06
that somebody understood the problem... ;)
By: Iñaki Baz Castillo (ibc) 2007-07-13 18:01:03

As I've reported in bug ASTERISK-9872 this big vulnerability occurs too with blind transfer, not just attended transfer.

 http://bugs.digium.com/view.php?id=10198

This is very serious problem, I can't believe why there is not more activity around it.
By: k-egg (k-egg) 2007-07-14 07:50:15

i can't either. but who cares?!
By: Joshua C. Colp (jcolp) 2007-07-16 07:35:41

With blind transfer the other party is just thrown back into the dialplan to execute dialplan logic, there is not much that could be done to stop the options that the user selected from being used.
By: k-egg (k-egg) 2007-07-16 12:28:43

file, i don't agree your words.

i looked in the code month before.
i agree:
there is no possibility to differentiate whether a channel is created by asterisk (by initiating a call) or by transfering (atx or blind).

i don't agree:
It is possible to determine if a channel is created during a xfer, (not sure if i released that patch here.).
and not only possible - it is essential (SIC!) to differentiate between these cases. It must be possible to handle these channels differently! really!

(edit:nothing deleted just adding these)
it's a pitty that a fantastic software and a fantastic team does not see the small but very very dangerous "features" of asterisk

btw: it was possible do determine, if a channel was created during a xfer in asterisk 1.09, but i don't know nothing about the inheritance of features to new channels in this version


By: Iñaki Baz Castillo (ibc) 2007-11-06 15:37:16.000-0600

Any new about this SECURITY issue?
By: Sergey Tamkovich (sergee) 2008-01-10 06:28:23.000-0600

1 year and 4 months :) time to get rid of this bug.


This bug is present in 1.4 and in trunk. it resides in builtin_atxfer() some logical problem in defining who is who (transferer, transferee, caller, callee...).

I'm uploadiing patches for trunk and 1.4 branch. I tested it with trunk and it works well. I didn't test patch for 1.4 though.

Testers are welcome!
By: Terry Wilson (twilson) 2008-01-11 15:12:03.000-0600

If A should not be able to transfer, and B should, then it looks like the patch provided would work for the situation that:
A calls B, B transfers to C
 but not
B calls A, B transfers to C


By: Sergey Tamkovich (sergee) 2008-01-12 02:07:13.000-0600

otherwiseguy, thank you for a quick feedback, i will test this case on monday.
By: Sergey Tamkovich (sergee) 2008-01-14 07:28:09.000-0600

otherwiseguy,

option T is a cruel option.

I think that the case you wrote about isn't a bug.


Then you use option T, caller is able to perfom transfer and callee is not.

Let's imagine situation:

'A' calls 'B', then 'A' transfers call to 'C'. The final Call looks like 'C' -> 'B'. From asterisk's point of view 'C' is a caller, and 'C' inherits A's capabilities. So if 'A' was able to transfer and 'B' wasn't, then in the resulting call ('C' -> 'B') 'C' would be able to transfer and 'B' still wouldn't.

This logic is a little bit complex, but i don't see anything wrong with it
By: Iñaki Baz Castillo (ibc) 2008-01-14 07:39:30.000-0600

> This logic is a little bit complex, but i don't see anything wrong with it.

Really you don't see anything wrong? Let set an example:

- Enterprise_X using Asterisk.
- worker_A calls to a client mobile.
- Mobile answers.
- After a while, worker_A needs to transfer this call to other worker_B.
- So worker_A press Asterisk transfer code and the call is transferred.
- But now, the mobile can press Asterisk transfer code and do a transfer to any number that worker_A is able to call.

Isn't it enough dangerous to consider it wrong?
By: k-egg (k-egg) 2008-01-14 15:18:43.000-0600

@ibc: sergee is right. T is not t and then everything is okay. RTFM ;)

@sergee, sry can not test your patches any more.not working with asterisk at the moment.
By: Terry Wilson (twilson) 2008-01-14 15:44:11.000-0600

I have tested, and it is, in fact, a problem.

[outside]
exten => 5551212,1,Dial(SIP/test1,60,t)

[internal]
exten => _600X,1,Dial(SIP/test${EXTEN:3},60,T)
exten => _5552222,1,Dial(SIP/external_caller,60,T)

If someone from internal, calls an external number (where they alone should be able to transfer), then uses a builtin atxfer to an internal phone the external caller can then transfer themselves.  Sorry, I'd like to see this bug get closed too (I've been actively looking at it for a while now), but this particular fix is not it.
By: Sergey Tamkovich (sergee) 2008-01-15 01:27:25.000-0600

otherwiseguy,

there were 2 things:

1. Initialy Reported problem with 't' option
2. Problem with 'T' option - reported by you.


There was definitely a bug (wrong C code) with 1st issue - my patch fixes it.

2nd issue is not a bug, code is ok there is nothing wrong with it. This is how transfer was _designed_ to work. As for me i don't like it too, but i don't see a way of fixing it in current implementation of transfer (described in my previous posts here).

May be you can offer a way of fixing it? i would glad to hear a fresh ideas..

Probably we need to export some sort of API to Asterisk's dialplan, for controlling xfer capabilities by users. But anyway - this is different issue IMHO, more likely feature request.


By: Iñaki Baz Castillo (ibc) 2008-01-15 02:40:22.000-0600

k-egg said:
> @ibc: sergee is right. T is not t and then everything is okay. RTFM ;)

The issue I described was about T, and as you comment in the post before this, the behaviour is unexpected even if the code is perfect. Yes, maybe it's a design limitation but also an issue (from user and admin perspective).
By: k-egg (k-egg) 2008-01-15 06:34:52.000-0600

hmm okay, as i said before, i'm unhappily not working with astersik at the moment. so i cannot test anything.

But when T is designed in that way it behaves at the moment, it should be redesigned, shouldn't it?

[edited/added]
i think it's not the expected behavior of an PBX, that somebody who is transfered inherits the capability to transfer himself.


By: Sergey Tamkovich (sergee) 2008-01-15 07:20:15.000-0600

k-egg,

i want to clearify the process of 'inheriting' transfer capabilities:

3 parties participate in transfer: transferer, transferee and 3rd party :) (let's say 111,222,333)
call legs for transferer and transferee are created during normal call

exten => XXX,1,DIAL(SIP/${EXTEN}||t)

let's say 111 calls 222, call established and bridged, 222 is capable of transfer and 111 is not. When 222 is trying to transfer this call to 333, transfer creates new call leg by calling DIAL(LOCAL/333@..) - so it would be looped into dialplan, and 333 will "inherit" transfer capabilities (because of 't' option).

But what happens when our dialplan use 'T' option?

exten => XXX,1,DIAL(SIP/${EXTEN}||T)

Once again 111 calls 222, call bridged. Now 111 is capable of transfer and 22 is not. 111 transfers call to 333. Transfer calls DIAL(Local/333@..) again, and this is the place where everything happens, each DIAL creates atleast 2 call-legs. Dial through "Local" channel creates virtual call-leg, you can see it in "core show channels" - something like "Local/333@default-2111;1". And this virtual leg is considered to be a caller, so the option 'T' is applyed to it, and later to 222, when 111 hangup and 222 become connected to 333.

what we could do in this case? explicitly ignore/revoke all transfer capabilities? That would brake nice behaviour of 't' option...
By: Tilghman Lesher (tilghman) 2008-01-15 08:55:58.000-0600

I think it's clear that if we can't fix it to work correctly, then we should remove inheritance of the transfer capability.  In other words, make it work safely, even if it decreases functionality, to avoid an incorrect capability.
By: Terry Wilson (twilson) 2008-01-15 13:42:19.000-0600

sergee: I see your point and agree that the patch does seem to fix for the issue of only having a 't' option. I think most dialplans out there that use 't' would use a mix of 't' and 'T' for different situations, though.  But, also, it looks like it might take a little bit of time before the 'T' option gets resolved (I've been looking at it for a couple of days now)--so I would consider applying this patch.  I'm going to give it a couple of days for more people to come and test and to raise objections, though.

Corydon76: I just talked to file and he said he had done that in the past and was forced to revert it, so apparently we've been down that road before.
By: Sergey Tamkovich (sergee) 2008-01-16 02:44:13.000-0600

otherwiseguy, that is exactly what i meant to say!
meanwhile i'll try to roll out some ideas that i have about 'T' option.


By: k-egg (k-egg) 2008-01-17 17:21:22.000-0600

puh, things are moving... i think.

so good luck on the way to solve this. and thx for working on that issue!
By: Digium Subversion (svnbot) 2008-01-18 10:56:21.000-0600

Repository: asterisk
Revision: 99026

U   trunk/res/res_features.c

------------------------------------------------------------------------
r99026 | twilson | 2008-01-18 10:56:19 -0600 (Fri, 18 Jan 2008) | 12 lines

This should at least temporarily fix a problem where the 't' Dial
option is incorrectly passed to the transferee when built-in
attended transfers are used.  There is still a problem with 'T',
but better to fix some problems than no problems while we work
on it.

(closes issue ASTERISK-7695)
Reported by: k-egg
Patches:
     transfer-fix-trunk-r97657.diff uploaded by sergee (license 138)
Tested by: sergee, otherwiseguy

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

http://svn.digium.com/view/asterisk?view=rev&revision=99026
By: Digium Subversion (svnbot) 2008-01-18 11:10:38.000-0600

Repository: asterisk
Revision: 99032

U   branches/1.4/res/res_features.c

------------------------------------------------------------------------
r99032 | twilson | 2008-01-18 11:10:37 -0600 (Fri, 18 Jan 2008) | 12 lines

This should at least temporarily fix a problem where the 't' Dial
option is incorrectly passed to the transferee when built-in
attended transfers are used.  There is still a problem with 'T',
but better to fix some problems than no problems while we work
on it.

(closes issue ASTERISK-7695)
Reported by: k-egg
Patches:
     transfer-fix-b14-r97657.diff uploaded by sergee (license 138)
Tested by: sergee, otherwiseguy

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

http://svn.digium.com/view/asterisk?view=rev&revision=99032
By: Terry Wilson (twilson) 2008-01-18 11:13:41.000-0600

Patches applied.  Thanks!  Now we just need to get that 'T' option fixed.