Hi all,
as we were running openbsc with a nanobts in a nitb configuration at our institute we observed two bugs in the authentification part of openbsc.
First: In file openbsc/openbsc/src/libmsc/db.c on line 372 there is
"ainfo->a3a8_ki_len = sizeof(ainfo->a3a8_ki_len);"
which takes the sizeof of the length value. This always results in a wrong keylength and hence no authentification will ever be executed. This should rather be changed to:
ainfo->a3a8_ki_len = sizeof(ainfo->a3a8_ki);
Secondly: I haven't found the piece of code which is responsible for this bug particulary but: Whenever the key for the a3a8_comp128 is being read from the database a shift of one bit occurs.
i.e. when you set the a3a8_key in the hlr.sqlite3 to 01010101010101010101010101010101 the value being processed as key in the a3a8_comp128 algorithm is 02020202020202020202020202020202.
Best Regards, Robert Ingr
Hi,
First: In file openbsc/openbsc/src/libmsc/db.c on line 372 there is
"ainfo->a3a8_ki_len = sizeof(ainfo->a3a8_ki_len);"
which takes the sizeof of the length value. This always results in a wrong keylength and hence no authentification will ever be executed. This should rather be changed to:
ainfo->a3a8_ki_len = sizeof(ainfo->a3a8_ki);
There is indeed a bug. But it's only in the "exception" processing, so in a normal case that shouldn't have prevented auth. (and since we use auth at the camp and 27c3, I can guarantee it works in the normal case :)
Secondly: I haven't found the piece of code which is responsible for this bug particulary but: Whenever the key for the a3a8_comp128 is being read from the database a shift of one bit occurs.
i.e. when you set the a3a8_key in the hlr.sqlite3 to 01010101010101010101010101010101 the value being processed as key in the a3a8_comp128 algorithm is 02020202020202020202020202020202.
That's not a bug per-se. I think you're assuming the binary value stored in the field is used as key. This is _not_ the case. libdbi has some special binary escaping that results in the binary value stored not being the "raw" key.
You have to either: - Use the vty to set the key - Set the key using libdbi - Escape the binary value yourself the same way as libdbi does.
Cheers,
Sylvain
Sylvain Munaut wrote:
i.e. when you set the a3a8_key in the hlr.sqlite3 to 01010101010101010101010101010101 the value being processed as key in the a3a8_comp128 algorithm is 02020202020202020202020202020202.
That's not a bug per-se. I think you're assuming the binary value stored in the field is used as key. This is _not_ the case. libdbi has some special binary escaping that results in the binary value stored not being the "raw" key.
Oh yay. Thanks for pointing this out.
When libdbi goes away I'll see if a database upgrade can be done transparently.
//Peter
Hi
i.e. when you set the a3a8_key in the hlr.sqlite3 to 01010101010101010101010101010101 the value being processed as key in the a3a8_comp128 algorithm is 02020202020202020202020202020202.
That's not a bug per-se. I think you're assuming the binary value stored in the field is used as key. This is _not_ the case. libdbi has some special binary escaping that results in the binary value stored not being the "raw" key.
Oh yay. Thanks for pointing this out.
I had to implement it for pysim (since we support updating HLR db directly from it), you can see the python code here :
http://cgit.osmocom.org/cgit/pysim/tree/ccc-gen.py?h=ccc#n33
Cheers,
Sylvain
Hi,
thanks for a quick reply.
First:
There is indeed a bug. But it's only in the "exception" processing, so in a normal case that shouldn't have prevented auth. (and since we use auth at the camp and 27c3, I can guarantee it works in the normal case :)
I'm sorry, i don't see why this is only an exceptional case, but ok. In our case it was always executed and hece the authentification was skipped. Or id rather say, the execution of comp128 was skipped due to an "invalid" key. The base station continued to work fine. We wouldn't have recognized it if we weren't waiting for the simcard to be asked to do the gsm_algorithm.
I can just tell that for us, it always printed the LOG error in _use_comp128_v1 function from line 57 in openbsc/openbsc/src/libmsc/auth.c
i.e. when you set the a3a8_key in the hlr.sqlite3 to 01010101010101010101010101010101 the value being processed as key in the a3a8_comp128 algorithm is 02020202020202020202020202020202.
That's not a bug per-se. I think you're assuming the binary value stored in the field is used as key. This is _not_ the case. libdbi has some special binary escaping that results in the binary value stored not being the "raw" key.
Oh yay. Thanks for pointing this out.
I had to implement it for pysim (since we support updating HLR db directly from it)
Ok, i used my own php script do manipulate the database directly. I figured it would be something with that dbi function. Thanks for the help!
Regards, Robert
Hi,
There is indeed a bug. But it's only in the "exception" processing, so in a normal case that shouldn't have prevented auth. (and since we use auth at the camp and 27c3, I can guarantee it works in the normal case :)
I'm sorry, i don't see why this is only an exceptional case, but ok.
Here's the faulty code :
if (ainfo->a3a8_ki_len > sizeof(ainfo->a3a8_ki)) ainfo->a3a8_ki_len = sizeof(ainfo->a3a8_ki_len);
So it's only executed if the current value is too big, which shouldn't happen if the DB field content is correct. This might be related to manually fiddling with the binary value without using the DBI escape method.
Cheers,
Sylvain
Sylvain Munaut 246tnt@gmail.com wrote:
Hi,
There is indeed a bug. But it's only in the "exception" processing, so in a normal case that shouldn't have prevented auth. (and since we use auth at the camp and 27c3, I can guarantee it works in the normal case :)
I'm sorry, i don't see why this is only an exceptional case, but ok.
Here's the faulty code :
if (ainfo->a3a8_ki_len > sizeof(ainfo->a3a8_ki)) ainfo->a3a8_ki_len = sizeof(ainfo->a3a8_ki_len);
So it's only executed if the current value is too big, which shouldn't happen if the DB field content is correct. This might be related to manually fiddling with the binary value without using the DBI escape method.
Cheers,
Sylvain
-
Peter Stuge -
Robert Ingr -
Sylvain Munaut