I seem to be able to crash Kamailio v3.1 by doing this when handling a REGISTER:
if(!www_authorize("$td", "subscriber")) { # $rc is -1 - "invalid user"
www_challenge("$td", "1"); exit; }
In other words, it cannot find the user, but I call www_challenge() anyway, and get a segfault. Can anyone reproduce, before I attempt to obtain a backtrace?
Actually, on further investigation, I think auth <-> auth_db is very broken in 3.1.0, at least when auth_db is used with Postgres. I imagine this is because the new 'auth' is from the SER side and 'auth_db' is from the Kamailio extraction.
In the below script, www_authorize() returns -1 even though the user is valid and is in the database table. However, when I look at my Postgres server's query logs, Kamailio does not actually check the 'subscriber' table to see if the user exists, nor is the table demand-loaded at startup. The user and the domain are both quite valid.
I have my script set to send_reply("403", "Forbidden") and 'exit' when www_authorize() returns -1, because if it's an invalid user, there is no point in challenging them. If I remove this reply and 'exit' however, to test what happens if I www_challenge() anyway, then Kamailio crashes.
On 10/06/2010 11:58 PM, Alex Balashov wrote:
I seem to be able to crash Kamailio v3.1 by doing this when handling a REGISTER:
if(!www_authorize("$td", "subscriber")) { # $rc is -1 - "invalid user"
www_challenge("$td", "1"); exit; }
In other words, it cannot find the user, but I call www_challenge() anyway, and get a segfault. Can anyone reproduce, before I attempt to obtain a backtrace?
I have tinkered with various combinations of modparam values for 'qop', 'nonce_count', and 'one_time_nonce' to see if it makes a difference. It does not.
On 10/07/2010 01:00 AM, Alex Balashov wrote:
Actually, on further investigation, I think auth <-> auth_db is very broken in 3.1.0, at least when auth_db is used with Postgres. I imagine this is because the new 'auth' is from the SER side and 'auth_db' is from the Kamailio extraction.
In the below script, www_authorize() returns -1 even though the user is valid and is in the database table. However, when I look at my Postgres server's query logs, Kamailio does not actually check the 'subscriber' table to see if the user exists, nor is the table demand-loaded at startup. The user and the domain are both quite valid.
I have my script set to send_reply("403", "Forbidden") and 'exit' when www_authorize() returns -1, because if it's an invalid user, there is no point in challenging them. If I remove this reply and 'exit' however, to test what happens if I www_challenge() anyway, then Kamailio crashes.
On 10/06/2010 11:58 PM, Alex Balashov wrote:
I seem to be able to crash Kamailio v3.1 by doing this when handling a REGISTER:
if(!www_authorize("$td", "subscriber")) { # $rc is -1 - "invalid user"
www_challenge("$td", "1"); exit; }
In other words, it cannot find the user, but I call www_challenge() anyway, and get a segfault. Can anyone reproduce, before I attempt to obtain a backtrace?
On 10/7/10 7:03 AM, Alex Balashov wrote:
I have tinkered with various combinations of modparam values for 'qop', 'nonce_count', and 'one_time_nonce' to see if it makes a difference. It does not.
Please send the backtrace. It is strange since authentication was deployed on many tests, but with mysql. Might be related to some of latest changes in postgres module.
Cheers, Daniel
On 10/07/2010 01:00 AM, Alex Balashov wrote:
Actually, on further investigation, I think auth <-> auth_db is very broken in 3.1.0, at least when auth_db is used with Postgres. I imagine this is because the new 'auth' is from the SER side and 'auth_db' is from the Kamailio extraction.
In the below script, www_authorize() returns -1 even though the user is valid and is in the database table. However, when I look at my Postgres server's query logs, Kamailio does not actually check the 'subscriber' table to see if the user exists, nor is the table demand-loaded at startup. The user and the domain are both quite valid.
I have my script set to send_reply("403", "Forbidden") and 'exit' when www_authorize() returns -1, because if it's an invalid user, there is no point in challenging them. If I remove this reply and 'exit' however, to test what happens if I www_challenge() anyway, then Kamailio crashes.
On 10/06/2010 11:58 PM, Alex Balashov wrote:
I seem to be able to crash Kamailio v3.1 by doing this when handling a REGISTER:
if(!www_authorize("$td", "subscriber")) { # $rc is -1 - "invalid user"
www_challenge("$td", "1"); exit; }
In other words, it cannot find the user, but I call www_challenge() anyway, and get a segfault. Can anyone reproduce, before I attempt to obtain a backtrace?
All right, will do. Compiling with debug symbols now for extra information.
I don't think it is Postgres-related; I briefly looked at the backtrace and there was no evidence at all of database activity. Nor did a TCP packet capture show any database activity. Instead, it seemed to me like the fact that the initial REGISTER request arrived without digest/auth headers (like it's supposed to) was taken as evidence that user does not exist without further developments.
I will post the backtrace as soon as I have it.
-- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
On Oct 7, 2010, at 2:45 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 10/7/10 7:03 AM, Alex Balashov wrote:
I have tinkered with various combinations of modparam values for 'qop', 'nonce_count', and 'one_time_nonce' to see if it makes a difference. It does not.
Please send the backtrace. It is strange since authentication was deployed on many tests, but with mysql. Might be related to some of latest changes in postgres module.
Cheers, Daniel
On 10/07/2010 01:00 AM, Alex Balashov wrote:
Actually, on further investigation, I think auth <-> auth_db is very broken in 3.1.0, at least when auth_db is used with Postgres. I imagine this is because the new 'auth' is from the SER side and 'auth_db' is from the Kamailio extraction.
In the below script, www_authorize() returns -1 even though the user is valid and is in the database table. However, when I look at my Postgres server's query logs, Kamailio does not actually check the 'subscriber' table to see if the user exists, nor is the table demand-loaded at startup. The user and the domain are both quite valid.
I have my script set to send_reply("403", "Forbidden") and 'exit' when www_authorize() returns -1, because if it's an invalid user, there is no point in challenging them. If I remove this reply and 'exit' however, to test what happens if I www_challenge() anyway, then Kamailio crashes.
On 10/06/2010 11:58 PM, Alex Balashov wrote:
I seem to be able to crash Kamailio v3.1 by doing this when handling a REGISTER:
if(!www_authorize("$td", "subscriber")) { # $rc is -1 - "invalid user"
www_challenge("$td", "1"); exit; }
In other words, it cannot find the user, but I call www_challenge() anyway, and get a segfault. Can anyone reproduce, before I attempt to obtain a backtrace?
-- Daniel-Constantin Mierla http://www.asipto.com
Attached:
- core.gz - compressed core file, just in case it is useful. - pcap.txt - capture of the REGISTER requests. - bt.txt - the GDB backtrace.
I compiled with -DEXTRA_DEBUG but a lot of strings have still been optimised out. What is the appropriate make target to compile with maximum debug info, disable all optimisations, etc?
From the backtrace, it looks to me as though it is trying to parse a digest header with nonce even though it is not in the request, although I may be mistaken.
On 10/07/2010 02:56 AM, Alex Balashov wrote:
All right, will do. Compiling with debug symbols now for extra information.
I don't think it is Postgres-related; I briefly looked at the backtrace and there was no evidence at all of database activity. Nor did a TCP packet capture show any database activity. Instead, it seemed to me like the fact that the initial REGISTER request arrived without digest/auth headers (like it's supposed to) was taken as evidence that user does not exist without further developments.
I will post the backtrace as soon as I have it.
-- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
On Oct 7, 2010, at 2:45 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 10/7/10 7:03 AM, Alex Balashov wrote:
I have tinkered with various combinations of modparam values for 'qop', 'nonce_count', and 'one_time_nonce' to see if it makes a difference. It does not.
Please send the backtrace. It is strange since authentication was deployed on many tests, but with mysql. Might be related to some of latest changes in postgres module.
Cheers, Daniel
On 10/07/2010 01:00 AM, Alex Balashov wrote:
Actually, on further investigation, I think auth <-> auth_db is very broken in 3.1.0, at least when auth_db is used with Postgres. I imagine this is because the new 'auth' is from the SER side and 'auth_db' is from the Kamailio extraction.
In the below script, www_authorize() returns -1 even though the user is valid and is in the database table. However, when I look at my Postgres server's query logs, Kamailio does not actually check the 'subscriber' table to see if the user exists, nor is the table demand-loaded at startup. The user and the domain are both quite valid.
I have my script set to send_reply("403", "Forbidden") and 'exit' when www_authorize() returns -1, because if it's an invalid user, there is no point in challenging them. If I remove this reply and 'exit' however, to test what happens if I www_challenge() anyway, then Kamailio crashes.
On 10/06/2010 11:58 PM, Alex Balashov wrote:
I seem to be able to crash Kamailio v3.1 by doing this when handling a REGISTER:
if(!www_authorize("$td", "subscriber")) { # $rc is -1 - "invalid user"
www_challenge("$td", "1"); exit; }
In other words, it cannot find the user, but I call www_challenge() anyway, and get a segfault. Can anyone reproduce, before I attempt to obtain a backtrace?
-- Daniel-Constantin Mierla http://www.asipto.com
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On Oct 07, 2010 at 03:17, Alex Balashov abalashov@evaristesys.com wrote:
Attached:
- core.gz - compressed core file, just in case it is useful.
- pcap.txt - capture of the REGISTER requests.
- bt.txt - the GDB backtrace.
I compiled with -DEXTRA_DEBUG but a lot of strings have still been optimised out. What is the appropriate make target to compile with maximum debug info, disable all optimisations, etc?
make cfg mode=debug FLAVOUR=.... make all
Andrei
On 10/07/2010 03:41 AM, Andrei Pelinescu-Onciul wrote:
On Oct 07, 2010 at 03:17, Alex Balashovabalashov@evaristesys.com wrote:
Attached:
- core.gz - compressed core file, just in case it is useful.
- pcap.txt - capture of the REGISTER requests.
- bt.txt - the GDB backtrace.
I compiled with -DEXTRA_DEBUG but a lot of strings have still been optimised out. What is the appropriate make target to compile with maximum debug info, disable all optimisations, etc?
make cfg mode=debug FLAVOUR=.... make all
Danke schön.
On Oct 07, 2010 at 03:17, Alex Balashov abalashov@evaristesys.com wrote:
Attached:
- core.gz - compressed core file, just in case it is useful.
- pcap.txt - capture of the REGISTER requests.
- bt.txt - the GDB backtrace.
I compiled with -DEXTRA_DEBUG but a lot of strings have still been optimised out. What is the appropriate make target to compile with maximum debug info, disable all optimisations, etc?
From the backtrace, it looks to me as though it is trying to parse a digest header with nonce even though it is not in the request, although I may be mistaken.
For me it looks like it's trying to use an unparsed from header. Did you set the 4 flag in auth_checks_register? (that would explain it)
Andrei
On 10/07/2010 04:01 AM, Andrei Pelinescu-Onciul wrote:
On Oct 07, 2010 at 03:17, Alex Balashovabalashov@evaristesys.com wrote:
Attached:
- core.gz - compressed core file, just in case it is useful.
- pcap.txt - capture of the REGISTER requests.
- bt.txt - the GDB backtrace.
I compiled with -DEXTRA_DEBUG but a lot of strings have still been optimised out. What is the appropriate make target to compile with maximum debug info, disable all optimisations, etc?
From the backtrace, it looks to me as though it is trying to parse a digest header with nonce even though it is not in the request, although I may be mistaken.
For me it looks like it's trying to use an unparsed from header. Did you set the 4 flag in auth_checks_register? (that would explain it)
I did. But I also tried setting all auth_checks_register flags to 0 as part of my testing and had the same crash.
On 10/07/2010 04:01 AM, Alex Balashov wrote:
I did. But I also tried setting all auth_checks_register flags to 0 as part of my testing and had the same crash.
I was incorrect to say this. I just tried setting flags to 0 again and now there is no crash.
However, www_authorize() still returns -1 (invalid user). The problem is not entirely solved. :/
On Oct 07, 2010 at 04:04, Alex Balashov abalashov@evaristesys.com wrote:
On 10/07/2010 04:01 AM, Alex Balashov wrote:
I did. But I also tried setting all auth_checks_register flags to 0 as part of my testing and had the same crash.
I was incorrect to say this. I just tried setting flags to 0 again and now there is no crash.
Could you try the latest git (with the flags set as before)? Should be fixed. The reason we haven't seen it before is that in the setups that did have the flags set, probably somebody did parse the complete from before (e.g. a t_newtran(), sanity module a.s.o.).
However, www_authorize() still returns -1 (invalid user). The problem is not entirely solved. :/
But that's another problem :-)
Andrei
On 10/07/2010 04:13 AM, Andrei Pelinescu-Onciul wrote:
On Oct 07, 2010 at 04:04, Alex Balashovabalashov@evaristesys.com wrote:
On 10/07/2010 04:01 AM, Alex Balashov wrote:
I did. But I also tried setting all auth_checks_register flags to 0 as part of my testing and had the same crash.
I was incorrect to say this. I just tried setting flags to 0 again and now there is no crash.
Could you try the latest git (with the flags set as before)? Should be fixed.
It is fixed; it does not crash. But it still thinks it's an invalid user, and there is no database activity to check if it is so. As you said below, that is another problem.
The reason we haven't seen it before is that in the setups that did have the flags set, probably somebody did parse the complete from before (e.g. a t_newtran(), sanity module a.s.o.).
Well, I have both in my configuration. For sanity, I have these checks:
modparam("sanity", "default_checks", 103) # 1 & 2 & 4 & 32 & 64
Here is a quick bitmask reference from the docs:
# SIP version in Request URI : 1 # Request URI scheme : 2 # Presence of RFC-mandated headers : 4 # CSeq method consistency : 32 # CSeq value consistency : 64 # Content length actual vs. declared : 128 # Expires value : 256 # Supported extensions : 512
And I do create a new transaction, as instructed by the new 'auth' documentation which says that to use nonce_count or one_time_nonce it is necessary that the transaction surrounding the digest authentication be stateful. I updated all my code to it today. It looks like this:
if(!t_newtran()) { # It must be a retransmission or similar.
xlog("L_ERR", "[REGISTER-HANDLER:$ci] !> " "Failed to create new transaction\n");
drop; }
if(!www_authorize("$td", "subscriber")) {
# Log the cause of the authorisation failure.
...
I have also replaced all sl_send_reply() with send_reply() so that SL can make the determination of whether to send the reply statefully based on whether a transaction exists.
However, www_authorize() still returns -1 (invalid user). The problem is not entirely solved. :/
But that's another problem :-)
Andrei
On Oct 07, 2010 at 04:04, Alex Balashov abalashov@evaristesys.com wrote:
On 10/07/2010 04:01 AM, Alex Balashov wrote:
[...]
However, www_authorize() still returns -1 (invalid user). The problem is not entirely solved. :/
That's a documentation problem. The return codes have changes (auth_db returns directly the error code of auth).
-1 = authentication error (could be bad credentials, internal error , credentials not found for the givel realm a.s.o) -2 = password -3 = user unknown
It could also be fixed by adding return code translation to the expected values for k, to modules_k/auth_*
Andrei
On 10/07/2010 04:28 AM, Andrei Pelinescu-Onciul wrote:
On Oct 07, 2010 at 04:04, Alex Balashovabalashov@evaristesys.com wrote:
On 10/07/2010 04:01 AM, Alex Balashov wrote:
[...]
However, www_authorize() still returns -1 (invalid user). The problem is not entirely solved. :/
That's a documentation problem. The return codes have changes (auth_db returns directly the error code of auth).
-1 = authentication error (could be bad credentials, internal error , credentials not found for the givel realm a.s.o) -2 = password -3 = user unknown
Oh. Shall I commit a fix for the docs?
On 10/07/2010 04:28 AM, Andrei Pelinescu-Onciul wrote:
On Oct 07, 2010 at 04:04, Alex Balashovabalashov@evaristesys.com wrote:
On 10/07/2010 04:01 AM, Alex Balashov wrote:
[...]
However, www_authorize() still returns -1 (invalid user). The problem is not entirely solved. :/
That's a documentation problem. The return codes have changes (auth_db returns directly the error code of auth).
-1 = authentication error (could be bad credentials, internal error , credentials not found for the givel realm a.s.o) -2 = password -3 = user unknown
It could also be fixed by adding return code translation to the expected values for k, to modules_k/auth_*
Brilliant; when I updated my code to look for these return codes instead, now the behaviour is much more sensible. :-) Thank you, Andrei!
I suggest just keeping the return codes like this and updating the docs.
-
Alex Balashov -
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla