This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
David A. Burgess dburgess at jcis.netHolger, Harald - I've been observing TMSI-handling bugs in GSM handsets for a while and saw a really good one last night, so I'm going to offer some comments here. > On Sat, Jan 10, 2009 at 01:40:33AM +0100, Holger Freyther wrote: > > Hey Guys, > > > > I'm currently implementing the CM Service Request of GSM 04.08 > and I wonder > > about the following: > > > > 1.) Some phones send us the TMSI of their current network > > 2.) One can ask the phone for the IMEISV/IMSI > > 3.) One can accept the LOCATION UPDATING REQUEST (or wait) > > 4.) A rogue MS could now request a channel with the BTS of the > original > > network > > 5.) Could send a CM Service Request with the TMSI of the > original phone and > > claim to not support A5 and such... > > 6.) Could initiate a call on the behalf of the other phone...? > > I think this would work, if > * we had a MS that we could fully control. > * the old network would accept the sudden classmark change for no > A5 support, > which in fact also depends on the cell itself. I would assume > that most > BTS in real-world netwokrs never announce that they support A5/0 According to GSM 02.07 Section 2, all GSM handsets are required support A5/1 and A5/2. According to GSM 02.09 Section 3.3, the network is SUPPOSED to deny service to any handset that doesn't support either A5/1 or A5/2. I'd be curious to see who's enforcing that, though. And any prudent operator will do an authentication at the start of a call, even for A5/0. Again, I'd be curious to see who's really doing it, but I'll bet most European operators do. You may not need to fully controlled a handset to do this, though. This is where TMSI handling bugs come into play. Last night, I was playing with a Treo 650. Having last registered in an AT&T network, the Treo sent a location updating request to my system (MNC=910, MCC=55) using that AT&T TMSI, which it is not supposed to do. I removed the SIM and cycled power. THAT should have cleared the old TMSI, but it came back to register by TMSI again. I sent a location updating accept, without sending a new TMSI. THAT should have cleared the old TMSI, but when I tried to place a mobile-oridinated call the Treo sent the same old AT&T-assigned TMSI in the CM service request. I am certain that if I had assigned a new TMSI to this handset and then switched off my system, that Treo would have taken my TMSI back the the AT&T network and tried to use it there. I suspect this kind of bug is fairly common and may be exploitable by a rogue network, even if only to expose the IMSI-TMSI relationships in the real carrier's BSC. As Harald points out, the attack described in the original e-mail should not work in a properly managed network. But I'll wager that most of the world's networks are not properly managed. -- David David A. Burgess OpenBTS on the web: http://openbts.sourceforge.net http://openbts.blogspot.com http://en.wikipedia.org/wiki/OpenBTS http://www.gnuradio.org/trac/wiki/OpenBTS