Project

General

Profile

Bug #3178

gbproxy: failed to parse invalid BSSGP-UNITDATA message

Added by pespin 3 months ago. Updated 27 days ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
04/16/2018
Due date:
% Done:

0%

Estimated time:
Spec Reference:

Description

Today while checking log output (debug all) of osmo-gbproxy 8343b4adbbe9afd4294232429696ee9736ec1004 in a testing/production set up:

<000f> gb_proxy_patch.c:154 Patching TLLIs: Replacing e5225438 -> da1d5ada
<000f> gb_proxy.c:767 NSEI=110 proxying BTS->SGSN (NS_BVCI=9108, NSEI=9108)
<0012> gprs_llc_parse.c:82 LLC SAPI=9 C   U GEA? IOV-UI=0x000000 FCS=0x62a1a7 CMD=UI DATA
<0012> gprs_gb_parse.c:408 Got LLC message, CRC: 62a1a7 (computed 62a1a7)
<000f> gprs_gb_parse.c:535 LLC: Got TLLI e5225438, BSSGP RAID 274-8-4120-0
<000f> gb_proxy_tlli.c:317 gbproxy_validate_tlli({current = e5225438, assigned = 00000000, net_vld = 1, bss_vld = 1}, e5225438)
<000f> gb_proxy_tlli.c:317 gbproxy_validate_tlli({current = da1d5ada, assigned = 00000000, net_vld = 1, bss_vld = 1}, da1d5ada)
<000f> gb_proxy_patch.c:154 Patching TLLIs: Replacing e5225438 -> da1d5ada
<000f> gb_proxy.c:767 NSEI=110 proxying BTS->SGSN (NS_BVCI=9108, NSEI=9108)
<000f> gprs_gb_parse.c:535 BSSGP: Got BSSGP RAID 274-8-4120-0, BSSGP PTMSI f3687732, IMSI 274080000004803
<000f> gb_proxy_patch.c:184 Patching BSSGP P-TMSIs: Replacing f3687732 -> e155cfea
<000f> gb_proxy.c:1080 NSEI=9108(SGSN) BSSGP PAGING routing by RAI to peer BVCI=9108
<000f> gb_proxy.c:791 NSEI=9108 proxying SGSN->BSS (NS_BVCI=0, NSEI=110)
<0012> gprs_llc_parse.c:82 LLC SAPI=1 C   U GEA? IOV-UI=0x000000 FCS=0x38436c CMD=UI DATA
<0012> gprs_gb_parse.c:408 Got LLC message, CRC: 38436c (computed 38436c)
<000f> gb_proxy.c:575 NSEI=110(BSS) patching: failed to parse invalid BSSGP-UNITDATA message
<000f> gprs_gb_parse.c:535 BSSGP-UNITDATA: Got TLLI 00000000, BSSGP RAID 274-8-4120-0
<000f> gb_proxy.c:579 NSEI=110(BSS) invalid message was: [L2]> 00 00 23 94 01 e1 55 cf ea 00 00 04 08 88 72 f4 80 10 18 00 9c 40 00 80 0e 00 06 01 c0 41 6c 43 38
<0012> gprs_llc_parse.c:82 LLC SAPI=9 C   U GEA? IOV-UI=0x000000 FCS=0xa65d4d CMD=UI DATA
<0012> gprs_gb_parse.c:408 Got LLC message, CRC: a65d4d (computed a65d4d)
<000f> gprs_gb_parse.c:535 LLC: Got TLLI e5225438, BSSGP RAID 274-8-4120-0
<000f> gb_proxy_tlli.c:317 gbproxy_validate_tlli({current = e5225438, assigned = 00000000, net_vld = 1, bss_vld = 1}, e5225438)
<000f> gb_proxy_tlli.c:317 gbproxy_validate_tlli({current = da1d5ada, assigned = 00000000, net_vld = 1, bss_vld = 1}, da1d5ada)
<000f> gb_proxy_patch.c:154 Patching TLLIs: Replacing e5225438 -> da1d5ada
<000f> gb_proxy.c:767 NSEI=110 proxying BTS->SGSN (NS_BVCI=9108, NSEI=9108)
<0012> gprs_llc_parse.c:82 LLC SAPI=9 C   U GEA? IOV-UI=0x000000 FCS=0x2bbfe2 CMD=UI DATA
<0012> gprs_gb_parse.c:408 Got LLC message, CRC: 2bbfe2 (computed 2bbfe2)
<000f> gprs_gb_parse.c:535 LLC: Got TLLI e5225438, BSSGP RAID 274-8-4120-0
<000f> gb_proxy_tlli.c:317 gbproxy_validate_tlli({current = e5225438, assigned = 00000000, net_vld = 1, bss_vld = 1}, e5225438)
<000f> gb_proxy_tlli.c:317 gbproxy_validate_tlli({current = da1d5ada, assigned = 00000000, net_vld = 1, bss_vld = 1}, da1d5ada)
<000f> gb_proxy_patch.c:154 Patching TLLIs: Replacing e5225438 -> da1d5ada
<000f> gb_proxy.c:767 NSEI=110 proxying BTS->SGSN (NS_BVCI=9108, NSEI=9108)
<0012> gprs_llc_parse.c:82 LLC SAPI=9 R   U GEA? IOV-UI=0x000000 FCS=0x376834 CMD=UI DATA
<0012> gprs_gb_parse.c:408 Got LLC message, CRC: 376834 (computed 376834)
<000f> gprs_gb_parse.c:535 LLC: Got TLLI da1d5ada, IMSI 274085000030459
<000f> gb_proxy_tlli.c:317 gbproxy_validate_tlli({current = da1d5ada, assigned = 00000000, net_vld = 1, bss_vld = 1}, da1d5ada)
<000f> gb_proxy_tlli.c:317 gbproxy_validate_tlli({current = e5225438, assigned = 00000000, net_vld = 1, bss_vld = 1}, e5225438)
<000f> gb_proxy_patch.c:154 Patching TLLIs: Replacing da1d5ada -> e5225438

So it seems there are some messages we are not handling correctly.

History

#1 Updated by laforge about 2 months ago

  • Assignee set to stsp

#2 Updated by stsp about 1 month ago

#3 Updated by stsp about 1 month ago

I have written a small test to reproduce the problem: https://gerrit.osmocom.org/#/c/osmo-sgsn/+/9500

The parsing failure happens when this part of the message is parsed as TLV type TLV_TYPE_TvLV:

ea 00 00 04 08 88 72 f4 80 10 18 00 9c 40 00 80 0e 00 06 01 c0 41 6c 43 38

libosmocore's TLV parser (src/gsm/tlv_parser.c) ends up "return -2" in line 214 at the end of this block of code:

194         case TLV_TYPE_TvLV:
195                 if (*(buf+1) & 0x80) {
196                         /* like TLV, but without highest bit of len */
197                         if (buf + 1 > buf + buf_len)
198                                 return -1;
199                         *o_val = buf+2;
200                         *o_len = *(buf+1) & 0x7f;
201                         len = *o_len + 2;
202                         if (len > buf_len)
203                                 return -2;
204                         break;
205                 }
206                 /* like TL16V, fallthrough */
207         case TLV_TYPE_TL16V:
208                 if (2 > buf_len)
209                         return -1;
210                 *o_val = buf+3;
211                 *o_len = *(buf+1) << 8 | *(buf+2);
212                 len = *o_len + 3;
213                 if (len > buf_len)
214                         return -2;

In gdb, we see:

(gdb) p len
$14 = 2187
(gdb) p buf_len
$15 = 22

#4 Updated by stsp about 1 month ago

  • Status changed from New to In Progress

#5 Updated by stsp 29 days ago

Manually decoded message according to:

ETSI TS 148 018 V10.6.0 (2012 07) 96
3GPP TS 48.018 version 10.6.0 Release 10
Table 10.2.2: UL-UNITDATA PDU content

    00    - PDU type UL-UNITDATA (ok)

        11.3.35 Temporary logical link Identity (TLLI)
    00    - TLLI[0]
    23    - TLLI[1]
    94    - TLLI[2]
    01    - TLLI[3]
          TLLI == "00239401" 

    e1    - QOS[0] (bit rate MSB)
    55    - QOS[1] (bit rate LSB)
          bit rate = "57685" (57685*100000 bit/s per PBRG)
    cf    - QOS[2] PBRG = 11 (bit rate is expressed in 100000 bit/s increments),
            C/R 0 (contains LLC ACK/SACK),
            T 0 (contains signalling),
            A 1 (radio if uses MAC/UNITDATA,
            Precedence 111 (reserved value)

    ea    - CELL_ID[0] (TLV IEI: wrong, should be 0x08)
    00    - CELL_ID[1] (length 1)
    00    - CELL_ID[2] (length 2)
        lenth == 0
    04    -- CELL_ID[3]
    08    -- CELL_ID[4]
    88    -- CELL_ID[5]
    72    -- CELL_ID[6]
    f4    -- CELL_ID[7]
    80    -- CELL_ID[8]
    10    -- CELL_DI[9]

    18    -- QOSP[0] OoS Profile IEI
        not allowed in BSSGP Userdata
    00    -- QOSP[1]
    9c    -- QOSP[2]
    40    -- QOSP[3]
    00    -- QOSP[4]

    80    -- IEI for "E-UTRAN Inter RAT Handover Info" 
        not allowed in BSSGP Userdata
    0e    -- length (14 bytes -- only 8 bytes remain)
    00
    06
    01
    c0
    41
    6c
    43
    38

EDIT: typos

#6 Updated by stsp 29 days ago

As best as I can tell this message is invalid.
Apart from tne first byte (and perhaps the TLLI) none of the data makes sense.

It would be nice to get a live pcap of such a message with lower-layer headers so we can tell where it originated. Would it be possible to reproduce this problem and record a pcap file?

#8 Updated by pespin 27 days ago

We can most probably reproduce it by connecting to any machine currently using osmo-gbproxy in production.

Once we know if this message is uplink or downlink, I guess it's worth looking at related code generating this kind of message in osmo-pcu or osmo-sgsn to see if we can find some code malforming the packet there.

#9 Updated by stsp 27 days ago

We already know that the message is uplink, based on where it was logged.

EDIT: To be clearer: The message processing failure was logged in gb_proxy.c:575 which is processing BSSGP uplink messages.

#10 Updated by stsp 27 days ago

Invalid BSSGP messages could slip through Rx in osmo-pcu and libosmocore as well.

See https://gerrit.osmocom.org/#/c/osmo-pcu/+/9728/
and https://gerrit.osmocom.org/#/c/libosmocore/+/9729

#11 Updated by stsp 27 days ago

I suggest we run another test with the above patches applied and see if more invalid messages show up.

I don't have a test setup ready. Can someone either test this on my behalf or guide me through the process of getting a test setup going, with my patches?

#12 Updated by stsp 27 days ago

We could also return an error notification to the sender if parsing fails:
https://gerrit.osmocom.org/#/c/libosmocore/+/9730/

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)