Hi!
Collin Mulliner, Tobias Engel and myself have been meeting yesterday to discuss a generic application interface for OpenBSC.
They are both doing security analysis and want to achieve a clean way how an external application can get access to a more or less transparent communication channel to the phone.
The purpose of this is to be able to send intentionally malformed packets to the mobile phone GSM stack at various different levels within the stack.
As of now, they have both hacked some custom code into openbsc that gets them half way where they want to be - but not quite all the way.
The requirements can be summarized as follows:
1) Ability to establish a SDCCH or TCH channel by paging the phone As of now, the 'silent call' feature from the VTY already does this.
2) Ability to send arbitrary layer3 protocol messages to the phone Adding this is relatively easy (use rsl_sendmsg on the lchan from the silent call)
3) Ability to receive responses from the phone, as well as error conditions such as 'readio link failure'. We don't have a solution for this yet, and we also have no clean way to identify what might be a response from the phone to the external app, and what might be a message from the phone to the normal network code in OpenBSC
4) Ability to selectively disable partial protocol handling in OpenBSC. Let's say you want to play with the mobile phone call control implementation. In this case, you want to make sure all CC related messages go from/to the external program and not from the regular OpenBSC network code.
So what I've been thinking of as a solution to the problem:
* store a bypass_flags bitmask related to the subscriber structure, where we indicate values such as BYPASS_RR, BYPASS_MM, BYPASS_CC, BYPASS_SAPI3.
* if we process an incoming message from the MS in gsm0408_rcvmsg(), we check if a bypass flag matching the message is found. If yes, forward the message to the external program
* if we want to send a message from our own protocol stack to the MS, we check if a bypass flag matching the message is found. If yes, we drop the message that we were about to send.
* any messages received from the application will be forwarded to the MS
The application interface protocol will likely have a close resemblance to RSL RLL. We need to exchange the following primitives with the application, like:
* ESTABLISH REQUEST -- app requests a channel be established to MS (by IMSI) * ESTABLISH CONFIRM -- network confirms a channel has been established * ESTABLISH INDICATION -- network tells app connection was made by MS * [UNIT] DATA REQUEST -- app requests data to be sent to MS * [UNIT] DATA INDICATION -- network indicates data was received from MS * ERROR INDICATION -- network tells app something went wrong * RELEASE REQUEST -- app asks network to release channel * RELEASE CONFIRM -- net tells app that channel was released (as rqd) * RELEASE INDICATION -- net tells app that channel was released (by MS)
The channel_number of RSL (indicating on-air timeslot) doesn't make much sense in this context, of course.
The link_identifier on the other hand is great as it allows the app to indicate SDCCH/FACCH or SACCH as well as the SAPI.
The actual RSL-like protocol would be encapsulated by UDP and available on a socket of the MSC.
What do you think?
Regards, Harald
On Wednesday 14 April 2010 23:48:22 Harald Welte wrote:
Hi!
Collin Mulliner, Tobias Engel and myself have been meeting yesterday to discuss a generic application interface for OpenBSC.
very nice.
They are both doing security analysis and want to achieve a clean way how an external application can get access to a more or less transparent communication channel to the phone.
The purpose of this is to be able to send intentionally malformed packets to the mobile phone GSM stack at various different levels within the stack.
Let me answer to your question from the bottom. If our only goal is to send malformed packets to the MS I think this interface is way too low level and for now all requirements can be handled by basic GSM08.08 messages.
- Ability to establish a SDCCH or TCH channel by paging the phone As of now, the 'silent call' feature from the VTY already does this.
GSM08.08 Paging Request which will be answered with a GSM08.08 Complete Layer3 Information (a new connection)
- Ability to send arbitrary layer3 protocol messages to the phone Adding this is relatively easy (use rsl_sendmsg on the lchan from the silent call)
GSM08.08 DTAP
- Ability to receive responses from the phone, as well as error conditions such as 'readio link failure'. We don't have a solution for this yet, and we also have no clean way to identify what might be a response from the phone to the external app, and what might be a message from the phone to the normal network code in OpenBSC
GSM08.08 DTAP and GSM08.08 Cleanup Request (Error Cause Radio Link Failure)
So what I've been thinking of as a solution to the problem:
- store a bypass_flags bitmask related to the subscriber structure, where we indicate values such as BYPASS_RR, BYPASS_MM, BYPASS_CC, BYPASS_SAPI3.
That sounds easy so far. We could easily extend it to MSG type in the future.
Hi Zecke,
On Thu, Apr 15, 2010 at 02:53:02AM +0200, Holger Freyther wrote:
They are both doing security analysis and want to achieve a clean way how an external application can get access to a more or less transparent communication channel to the phone.
The purpose of this is to be able to send intentionally malformed packets to the mobile phone GSM stack at various different levels within the stack.
Let me answer to your question from the bottom. If our only goal is to send malformed packets to the MS I think this interface is way too low level and for now all requirements can be handled by basic GSM08.08 messages.
what do you mean by 'low level'? Their intent really is to send arbitrary L3 messages in L2, even on strange SAPIs or on an unexpected logical channel (SACCH vs. SDCCH).
- Ability to establish a SDCCH or TCH channel by paging the phone As of now, the 'silent call' feature from the VTY already does this.
GSM08.08 Paging Request which will be answered with a GSM08.08 Complete Layer3 Information (a new connection)
true.
- Ability to send arbitrary layer3 protocol messages to the phone Adding this is relatively easy (use rsl_sendmsg on the lchan from the silent call)
GSM08.08 DTAP
true.
- Ability to receive responses from the phone, as well as error conditions such as 'readio link failure'. We don't have a solution for this yet, and we also have no clean way to identify what might be a response from the phone to the external app, and what might be a message from the phone to the normal network code in OpenBSC
GSM08.08 DTAP and GSM08.08 Cleanup Request (Error Cause Radio Link Failure)
true.
However, the MSC talks GSM 08.08 to the BSC. So are you proposing of having a 08.08 interface between APP and MSC, or to have a BSC with multiple 08.08 interfaces? After all, in almost all the use cases we still want the regular MSC around for things like location updating, authentication, etc.
The other question then is: Why 08.08? Wouldn't the logical consequence be to implement actual MAP (like the E interface between MSC and MSC in a real gsm network)?
Regards, Harald
On Thursday 15 April 2010 15:24:47 Harald Welte wrote:
Mahlzeit LaF0rge,
Let me answer to your question from the bottom. If our only goal is to send malformed packets to the MS I think this interface is way too low level and for now all requirements can be handled by basic GSM08.08 messages.
what do you mean by 'low level'? Their intent really is to send arbitrary L3 messages in L2, even on strange SAPIs or on an unexpected logical channel (SACCH vs. SDCCH).
When looking at your proposed RSL like messages I was able (at least I thought/think so) to map it 1:1 to GSM0808 primitives and then had the feeling to implement most of GSM0808 at a lower level.
However, the MSC talks GSM 08.08 to the BSC. So are you proposing of having a 08.08 interface between APP and MSC, or to have a BSC with multiple 08.08 interfaces? After all, in almost all the use cases we still want the regular MSC around for things like location updating, authentication, etc.
I had a bypass on the MSC in mind. E.g. one would send a PAGING REQUEST messages to the MSC, it would be forwarded to the BSC, then we would get a Complete Layer3 Information with the CM Service Request and then we could decide that for the type of XYZ, we want to hand out this communication to another app (okay, I made the CM Service Request up and didn't have that in mind today morning).
The other question then is: Why 08.08? Wouldn't the logical consequence be to implement actual MAP (like the E interface between MSC and MSC in a real gsm network)?
Good point, I have no idea about the protocol and the way it is working. My reason to propose GSM0808 as interface was twofold. We do have code to create and parse messages right now, and I think we can handle the use cases you have described with it (including using a custom link id and requesting weird channels) which would lead to a fast result for one of the primary use cases of OpenBSC (enable research).
regards holger
On Thu, Apr 15, 2010 at 03:43:18PM +0200, Holger Freyther wrote:
what do you mean by 'low level'? Their intent really is to send arbitrary L3 messages in L2, even on strange SAPIs or on an unexpected logical channel (SACCH vs. SDCCH).
When looking at your proposed RSL like messages I was able (at least I thought/think so) to map it 1:1 to GSM0808 primitives and then had the feeling to implement most of GSM0808 at a lower level.
I agree it's a lower level in the network hierarchy, but not really a lower level in the protocol stack... both interfaces facilitate the establishment and communication via layer2.
It might be the case that since paging / response is included in 08.08, we have a little bit less extra (non-standard) work than with the RSL approach.
I had a bypass on the MSC in mind. E.g. one would send a PAGING REQUEST messages to the MSC, it would be forwarded to the BSC, then we would get a Complete Layer3 Information with the CM Service Request and then we could decide that for the type of XYZ, we want to hand out this communication to another app (okay, I made the CM Service Request up and didn't have that in mind today morning).
What I'm wondering about is: Do we really get the full power/control if we want it? Isn't the RR always handled in the BSC with no way around and only MM/CC/SMS/SS forwarded to the MSC on 08.08?
The other question then is: Why 08.08? Wouldn't the logical consequence be to implement actual MAP (like the E interface between MSC and MSC in a real gsm network)?
Good point, I have no idea about the protocol and the way it is working.
I've done a careful peek at 09.01 and 09.02. While it might be flexible enough to do what we want, implementing MAP only partially is more than an entire project in itself. So I'd rather not open pandora's box as of now.
Which leaves us with the RSL or the 08.08 based approach. I'm still undecided :/
On 04/17/2010 06:23 PM, Harald Welte wrote:
What I'm wondering about is: Do we really get the full power/control if we want it? Isn't the RR always handled in the BSC with no way around and only MM/CC/SMS/SS forwarded to the MSC on 08.08?
No, we do not have the full power. There is one thing we can not do with the 08.08 approach unless we add something non standard. Right now we would not be able to submit on a SAPI that was not established yet. It might be more easy to add IEs for custom behavior than implementing everything.
Which leaves us with the RSL or the 08.08 based approach. I'm still undecided :/
You know it is your call. :)
PS: First mail with thunderbird, I hope it is not HTML...
Some more thoughts on that old topic:
A custom protocol seems to make more and more sense. Neither original RSL nor 08.08 seem to be a close match.
Some more specification of the original protocol idea:
On Wed, Apr 14, 2010 at 11:48:22PM +0200, Harald Welte wrote:
- ESTABLISH REQUEST -- app requests a channel be established to MS (by IMSI)
Parameters: * mobile identity (tmsi/imsi) (can re-use 04.08 mobile identity IE) * channel type (sdcch/tch) (can reuse RSL information element) * which parts of the protocol shall openbsc handle (RR/MM/CC) * unique reference identifying this 'call/radio channel'
- ESTABLISH CONFIRM -- network confirms a channel has been established
(confirmation that the radio channel has been established) Parameters: * unique reference identifying this call/radio channel * exact arfcn/timeslot/sub-slot that was established (can be RSL or 04.08 channel description)
- ESTABLISH INDICATION -- network tells app connection was made by MS
(confirmation that a LAPDm connection was established) Parameters: * unique reference identifying this call/radio channel * SAPI (RSL Link ID)
- [UNIT] DATA REQUEST -- app requests data to be sent to MS
- [UNIT] DATA INDICATION -- network indicates data was received from MS
Parameters: * unique reference identifying this call/radio channel * SAPI (RSL Link ID)
- ERROR INDICATION -- network tells app something went wrong
Parameters: * unique reference identifying this call/radio channel * error code / reason
- RELEASE REQUEST -- app asks network to release channel
Parameters: * unique reference identifying this call/radio channel
- RELEASE CONFIRM -- net tells app that channel was released (as rqd)
Parameters: * unique reference identifying this call/radio channel
- RELEASE INDICATION -- net tells app that channel was released (by MS)
Parameters: * unique reference identifying this call/radio channel
On 02/15/2011 12:20 PM, Harald Welte wrote:
Some more thoughts on that old topic:
A custom protocol seems to make more and more sense. Neither original RSL nor 08.08 seem to be a close match.
The question is still what we want to fuzz. The strong point of GSM 08.08 is that it is 'connection' based. We do have a connection (maybe over multiple lchan's) to a MS and GSM 08.08 is quite good at sending messages to the MS.
On the other hand if we have something closer to RSL we are on the assembler level, this way we either need to have something else in the system to bring the MS into the state where someone wants to start fuzzing (which i think will complicate the test setup), or one is using the assembler commands to get the system into the state.
But then again it all depends on what one wants to test and how complicated it is to get the MS into this mode. So I might be missing the point. :)
regards holger
Hi Holger,
On Tue, Feb 15, 2011 at 12:55:52PM +0100, Holger Hans Peter Freyther wrote:
The question is still what we want to fuzz. The strong point of GSM 08.08 is that it is 'connection' based. We do have a connection (maybe over multiple lchan's) to a MS and GSM 08.08 is quite good at sending messages to the MS.
But we only have 08.08 support if you run osmo-bsc, at which point you loose all the MM common procedures,etc. The requirement seems to be flexibility, i.e. being able to use any or all of the bsc_hack features and configure flexibly what you want.
Tobias and I have now discussed an alternative approach: Filtering. Something similar to NF_QUEUE, where all incoming/outgoing RSL(RLL) messages are routed through an external application first. The app can then simply allow them to pass, filter them, modify or replace them with something completely different.
This has the advantage that you can benefit from the existing MM and CC state machines in OpenBSC, but can simply modify individual messages or IEs inside messages, without having to care about much else.
It would then be a per-subscriber property if messages from/to him are to be relayed through that external filter app or not. The per-subscriber property then propagates down into a per-lchan property.
Regards, Harald.
On 02/15/2011 03:04 PM, Harald Welte wrote:
Hi Holger,
But we only have 08.08 support if you run osmo-bsc, at which point you loose all the MM common procedures,etc. The requirement seems to be flexibility, i.e. being able to use any or all of the bsc_hack features and configure flexibly what you want.
The adaption to make bsc_hack connect to osmo-bsc would be small and actually osmo-bsc is (almost) able to handle a connection locally and then move it to the external interface.
Tobias and I have now discussed an alternative approach: Filtering. Something similar to NF_QUEUE, where all incoming/outgoing RSL(RLL) messages are routed through an external application first. The app can then simply allow them to pass, filter them, modify or replace them with something completely different.
Again, I don't know all the usecases and just have the approach I would take in mind. One (the only) issue I see is timers. E.g. we have timers for CC, SMS, etc. We want to stop, release the resources without releasing the connection. I assume leaking is a an allowed option for the fuzzing.
-
Harald Welte -
Holger Freyther -
Holger Hans Peter Freyther