Bug #3806
OsmoBSC accepts BSSAP with wrong length field
40%
Description
As seen in #3805, OsmoBSC would happily accept BSSMAP CLEAR COMMAND messages with IEs that extend beyond the length field of the BSSAP header.
This is definitely wrong. We should
- parse the length field
- ensure we have a minimum of that number of bytes of payload as specified by the length field
- truncate the msgb to a payload length as specified
This way any additional garbage at the end of a message would simply be ignored, with us only parsing the specified "length" number of bytes.
Let's also make sure to add TTCN-3 tests for this, intentionally sending length field values too large and too short.
Once implemented in OsmoBSC, we should also implement it on the MSC side.
Related issues
History
#2 Updated by dexter 10 months ago
- Status changed from New to In Progress
- % Done changed from 0 to 40
I have now integrated checking+truncating of the bssmap message length, there is no TTCN3 test yet.
https://gerrit.osmocom.org/#/c/osmo-bsc/+/13306 osmo_bsc_bssap: check bssamp length field
https://gerrit.osmocom.org/#/c/osmo-msc/+/13307 a_iface_bssap: check bssamp length field
#3 Updated by dexter 10 months ago
The two patches for the length check, which I proposed look good in review. However, I have problems creating with TTCN3 for this since TTCN3 seems to let me only generate valid CLEAR COMMANDs. The best would be if I could somehow send a hand crafted SCCP payload, however, I do not know if this is possible.
#4 Updated by laforge 10 months ago
- File bssap_adapter.diff bssap_adapter.diff added
On Tue, Mar 26, 2019 at 08:40:40AM +0000, dexter [REDMINE] wrote:
The two patches for the length check, which I proposed look good in review. However, I have problems creating with TTCN3 for this since TTCN3 seems to let me only generate valid CLEAR COMMANDs. The best would be if I could somehow send a hand crafted SCCP payload, however, I do not know if this is possible.
1) Normal option
Normally, You'd need to use the SCCP_Emulation directly, without the BSSMAP_Emulation on top.
2) Hackish option
Alternatively, you could extend the BSSAP_Conn_PT (port betwene BSSMAP_Emulation and ConnHdlr)
to accept something like 'octetstring' (in addition to PDU_BSSAP, etc.) and extend the
BSSMAP_Emulation.main() function with a
[] CLIENT.receive(octetstring:?) -> value oct {
BSSAP.send(oct);
}
you'd also have to extend BSSAP_CODEC_PT similarly, implementing somethin like a
"type record BSSAP_N_DATA_RAW_req" which uses "octetstring" instead of PDU_BSSAP.
However, I guess at that point it all becomes too complex. So I'd suggest to simply
go for yet another way:
3) BSSAP_Adapter without "ops"
When you call f_bssmap_init with an "omit" argument as BssmapOps, then you basically
get the entire SIGTRAN stack up to SCCP, but without any BSSAP/BSSMAP on top.
You would then have something like a
modulepar {
BSSAP_Configuration mp_bssap_cfg := { ... }; /* like BSC_Tests.ttcn */
}
component RAW_SCCP_CT {
BSSAP_Adapter g_ba;
port SCCPasp_PT SCCP;
}
function f_init() runs on RAW_SCCP_CT {
f_bssap_init(g_ba, mp_cfg, "RAW_SCCP", omit);
connect(self:SCCP, g_ba.vc_SCCP:SCCP_SP_PORT);
}
from that point onwards, you can then use things like
testcase TC_foo() runs on RAW_SCCP_CT {
f_init();
SCCP.send(t_ASP_N_CONNECT_req(called, calling, omit, omit, '01020304'O, conn_id, omit));
SCCP.receive(tr_ASP_N_CONNECT_res ....
You may need the attached patch to fix a bug in BSSAP_Adapter.ttcn
