7 May
2012
7 May
'12
7:53 p.m.
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
7 May
7 May
8:08 p.m.
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
8:20 p.m.
Sylvain Munaut wrote:
Oh yay. Thanks for pointing this out.
When libdbi goes away I'll see if a database upgrade can be done
transparently.
//Peter
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.
8:36 p.m.
Hi
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
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.
8 May
8 May
9:33 a.m.
Hi,
thanks for a quick reply.
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
> 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.
9:45 a.m.
Hi,
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
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.
9:53 a.m.
Sylvain Munaut <246tnt(a)gmail.com> wrote:
Hi,
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
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.
4840
days inactive
4841
days old
7 comments
3 participants
participants (3)
-
Peter Stuge -
Robert Ingr -
Sylvain Munaut