Skip to content

Wrong password column used for authentication #6

Closed
MeanwhileTheShipWasDrawingNear opened this Issue Jun 13, 2013 · 4 comments

2 participants

@MeanwhileTheShipWasDrawingNear

OpenSIPS branch 1.8

I am running into the same issue as described in bug #477. Are there any updates on this issue? I am having trouble finding the problem in the code as I am unfamiliar with the db/auth modules. It could be a while before I find a solution. Thanks for any support you can give me.

Description: When I authenticate two clients (one client with the digest username: "user1", and the other with the username: "user2@sip.domain.com"), the second client authentication fails. From debug messages, it seems that once a password column is used once (ha1 or ha1b), it will be used in all following queries even if the other password column should be used.

Relevant debug:
First authentication (Success, generates new query) :
DBG:auth_db:get_ha1: username: user2
DBG:auth_db:get_ha1: domain portion: sip.domain.com
DBG:auth_db:get_ha1: calc_ha1: 0
DBG:auth_db:get_ha1: using pass column 2 ha1b
DBG:db_mysql:db_mysql_do_prepared_query: conn=0x7f674f42ec98 (tail=140081688144552) MC=0x7f674f430ee8
DBG:db_mysql:db_mysql_do_prepared_query: new query=|select ha1b from subscriber where username=? AND domain=?|
DBG:db_mysql:re_init_statement: query is , ptr=(nil) DBG:db_mysql:db_mysql_do_prepared_query: new statement(0x7f674f441238) on connection: (0x7f674f42ec98) 0x7f674f42eaa8 DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run DBG:db_mysql:db_mysql_val2bind: added val (0): len=8; type=254; is_null=0 DBG:db_mysql:db_mysql_val2bind: added val (1): len=14; type=254; is_null=0 DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in... DBG:db_mysql:db_mysql_do_prepared_query: prepared statement has 1 columns in result DBG:db_mysql:db_mysql_do_prepared_query: doing to BIND_PARAM out ... DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f674f440ef8 DBG:db_mysql:db_mysql_get_columns: 1 columns returned from the query DBG:core:db_allocate_columns: allocate 28 bytes for result columns at 0x7f674f440f40 DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f674f440f48)[0]=[ha1b] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type DBG:core:db_allocate_rows: allocate 48 bytes for result rows and values at 0x7f674f440f78 DBG:db_mysql:db_mysql_str2val: converting STRING [a05a32187aab07c37c874b311bf5cc36] DBG:auth:check_response: our result = '416f60b359e7e74f6c427044addd80c1' DBG:auth:check_response: authorization is OK Second authentication (Failure, note that no new query is prepared and the result column name is ha1b) : DBG:auth_db:get_ha1: username: user1 DBG:auth_db:get_ha1: domain portion: DBG:auth_db:get_ha1: calc_ha1: 0 DBG:auth_db:get_ha1: using pass column 1 ha1 DBG:db_mysql:has_stmt_ctx: ctx found for subscriber DBG:db_mysql:db_mysql_do_prepared_query: conn=0x7f674f42ec98 (tail=140081688144552) MC=0x7f674f430ee8 DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run DBG:db_mysql:db_mysql_val2bind: added val (0): len=8; type=254; is_null=0 DBG:db_mysql:db_mysql_val2bind: added val (1): len=14; type=254; is_null=0 DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in... DBG:db_mysql:db_mysql_do_prepared_query: prepared statement has 1 columns in result DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f674f440cf8 DBG:db_mysql:db_mysql_get_columns: 1 columns returned from the query DBG:core:db_allocate_columns: allocate 28 bytes for result columns at 0x7f674f440f40 DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f674f440f48)[0]=[ha1b] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type DBG:core:db_allocate_rows: allocate 48 bytes for result rows and values at 0x7f674f441940 DBG:db_mysql:db_mysql_str2val: converting STRING [a05a32187aab07c37c874b311bf5cc36] DBG:auth:check_response: our result = 'bc17e12c512d25b469d6d131221b2ee9' DBG:auth:check_response: authorization failed

@MeanwhileTheShipWasDrawingNear

I've found the problem in modules/auth_db/authorize.c:get_ha1.

There should be two prepared statement variables in the function. One for the ha1 statement and a second for the ha1b statement.

Right now there is only one prepared statement variable (static db_ps_t auth_ps) so after the function is called once it sets which result column will be returned no matter which one is passed in on future calls.

@bogdan-iancu bogdan-iancu was assigned Jun 17, 2013
@bogdan-iancu bogdan-iancu added a commit that referenced this issue Jun 17, 2013
@bogdan-iancu bogdan-iancu - fixed usage of prepared statements durin auth - we may use 2 differ…
…ent queries in the same time.

  Credits for reporting the bug and the problem go to Steve Brisson
  Closes issue #6 on GH.
8d74b95
@bogdan-iancu
OpenSIPS - a versatile SIP Server member

Hi, thanks a lot for your report and troubleshooting - indeed, there was a case which was never considered, leading to using 2 different types of queries in the same time.

I made a fix on the trunk version (see 8d74b95 or 8d74b95).

Could you please validate my fix before doing the backport to 1.9 and 1.8 ?

Thanks and regards,
Bogdan

@MeanwhileTheShipWasDrawingNear

I have verified that the fix works correctly. Thanks!

@bogdan-iancu bogdan-iancu added a commit that referenced this issue Jun 17, 2013
@bogdan-iancu bogdan-iancu - fixed usage of prepared statements durin auth - we may use 2 differ…
…ent queries in the same time.

  Credits for reporting the bug and the problem go to Steve Brisson
  Closes issue #6 on GH.
6f25a0a
@bogdan-iancu bogdan-iancu added a commit that referenced this issue Jun 17, 2013
@bogdan-iancu bogdan-iancu - fixed usage of prepared statements durin auth - we may use 2 differ…
…ent queries in the same time.

  Credits for reporting the bug and the problem go to Steve Brisson
  Closes issue #6 on GH.
(cherry picked from commit 8d74b95)
88d4708
@bogdan-iancu
OpenSIPS - a versatile SIP Server member

Thanks, all backports done !

This was referenced Aug 5, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.