Summary: | ASTERISK-20677: Action Challenge not working with allowmultiplelogin=no | ||||
Reporter: | Vladimir Astafiev (vldmr) | Labels: | |||
Date Opened: | 2012-11-12 01:41:03.000-0600 | Date Closed: | 2012-11-28 10:31:45.000-0600 | ||
Priority: | Major | Regression? | Yes | ||
Status: | Closed/Complete | Components: | Core/ManagerInterface | ||
Versions: | 11.0.1 | Frequency of Occurrence | Constant | ||
Related Issues: |
| ||||
Environment: | CentOS 5.8 i386, AMD Opteron 1214 CentOS 5.8 x86_86, Intel Xeon E5-2620 | Attachments: | ( 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. |