[Home]

Summary:ASTERISK-20677: Action Challenge not working with allowmultiplelogin=no
Reporter:Vladimir Astafiev (vldmr)Labels:
Date Opened:2012-11-12 01:41:03.000-0600Date Closed:2012-11-28 10:31:45.000-0600
Priority:MajorRegression?Yes
Status:Closed/CompleteComponents:Core/ManagerInterface
Versions:11.0.1 Frequency of
Occurrence
Constant
Related
Issues:
is caused byASTERISK-18479 ast_manager_register_struct attempts to unlock an uninitialized rwlock
Environment:CentOS 5.8 i386, AMD Opteron 1214 CentOS 5.8 x86_86, Intel Xeon E5-2620Attachments:( 0) challenge_action_nomultiplelogin.diff
Description:With option {{allowmultiplelogin=no}} in manager.conf action Challenge not working. When I try connect to Manager Interface via telnet I've got these responses:
{code}
[root@asterisk-test ~]# telnet 127.0.0.1 5038
Trying 127.0.0.1...
Connected to asterisk-test.company.tld (127.0.0.1).
Escape character is '^]'.
Asterisk Call Manager/1.3
Action: Challenge
AuthType: MD5

Response: Error
Message: Login Already In Use

Connection closed by foreign host.
{code}
or periodically
{code}
[root@asterisk-test ~]# telnet 127.0.0.1 5038
Trying 127.0.0.1...
Connected to asterisk-test.company.tld (127.0.0.1).
Escape character is '^]'.
Asterisk Call Manager/1.3
Action: Challendge
AuthType: MD5

Response: Error
Message: Permission denied

Connection closed by foreign host.
{code}

No users connected to manager at this time:
{code}
[root@asterisk-test ~]# asterisk -rx 'manager show connected'
 Username         IP Address                                               Start       Elapsed     FileDes   HttpCnt   Read   Write
0 users connected.
{code}
With {{allowmultiplelogin=yes}} action Challenge working fine. Login without challenge working fine.

{code:title=manager.conf}
[general]
enabled=yes
webenabled=no

port=5038
bindaddr=0.0.0.0

allowmultiplelogin=no
displayconnects=yes

[admin]
secret=secret
read=all
write=all
{code}
Comments:By: Matt Jordan (mjordan) 2012-11-12 09:13:53.087-0600

It appears as if the Challenge action wasn't implemented properly in this situation.  When performing a Challenge without being logged in, a {{UserName}} header must be supplied with the action:

{noformat}
Action: Challenge
UserName: foo
AuthType: MD5

Response: Success
Challenge: 1583744384
{noformat}

The contents of the {{UserName}} field are immaterial - so long as any character string is provided, a challenge will be sent back.  Otherwise, the "Login Already In Use" error will be kicked back.

In many ways, this makes a small amount of sense - allowing an unauthenticated connection to enumerate potential user accounts would be a security vulnerability.  That being said, at that point the UserName field is useless, so it shouldn't be a requirement for the command to be executed.



By: Matt Jordan (mjordan) 2012-11-12 09:23:12.986-0600

Bug introduced in r340279.  Previously, the check for whether or not the manager session was in use would not occur on a Challenge if a username wasn't specified.

The correct behavior in this case is to not require the UserName header.

By: Jonathan Rose (jrose) 2012-11-26 09:38:19.371-0600

I checked this in 1.8 r340278 and the issue persists in that revision as well. I'm going to check the behavior in 1.6.2.
EDIT: Behavior is the same in 1.6.2. I don't think this is actually a regression. That said, I've got a patch that I think works. I'll post it shortly.
EDIT: Well, it is a regression, but the regression is between 1.4 and 1.6.2.
EDIT: Nevermind to the above. 1.4 didn't have the allowmultiplelogin option. This behavior was probably introduced with the option... meaning it isn't a regression since this never really worked with allowmultiplelogin set to no in the first place.

By: Jonathan Rose (jrose) 2012-11-26 10:26:38.878-0600

challenge_action_nomultiplelogin.diff is the patch. It works by bypassing the user already in use check on actions that are allowed before login is authenticated when no username is specified. This wasn't caught by '!user' which was in 1.6.2 because user would be set to an empty string in these cases, so ast_strlen_zero can be used to detect this instead.