https://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092020-08-19T06:26:14ZOpen Source Mobile CommunicationsOsmoMSC - Bug #4721: osmo-msc creates evil-twin entries in the VLR when an already attached IMSI does a LU by an unknown TMSI (was: MSC_Tests.TC_lu_by_tmsi_noauth_unknown fails sporadically locally)https://projects.osmocom.org/issues/4721?journal_id=194202020-08-19T06:26:14Zlaforge
<ul></ul><p>actually it seems that it always fails when executed the second (and any subsequent) time after an osmo-msc start. It only passes once after MSC start. So some state appears to be leaking?</p> OsmoMSC - Bug #4721: osmo-msc creates evil-twin entries in the VLR when an already attached IMSI does a LU by an unknown TMSI (was: MSC_Tests.TC_lu_by_tmsi_noauth_unknown fails sporadically locally)https://projects.osmocom.org/issues/4721?journal_id=194272020-08-19T11:33:48Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>I added some pointer value logging, and apparently the vlr_subscr from the first test run sticks around in the VLR.<br />The second test run creates a duplicate vlr_subscr for the same IMSI.<br />When the second test run sends the GSUP subscriber update, it gets directed to the first vlr_subscr, while the active connection is associated with the second vlr_subscr.</p>
<p>There should be all sorts of provisions to avoid duplicate vlr_subscr.<br />I am now trying to figure out how this evil twin vlr_subscr is possible at all.</p>
<p>Test suite wise the question is whether we should clear the state of osmo-msc, i.e. issue some vty command to clear the entire VLR at the start of each test.</p>
<p>osmo-msc stability wise we should still figure out how this can happen and fix it.</p> OsmoMSC - Bug #4721: osmo-msc creates evil-twin entries in the VLR when an already attached IMSI does a LU by an unknown TMSI (was: MSC_Tests.TC_lu_by_tmsi_noauth_unknown fails sporadically locally)https://projects.osmocom.org/issues/4721?journal_id=194282020-08-19T11:48:19Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>Looking at the code there apparently is a gaping hole in osmo-msc's implementation, and the case that an already attached IMSI does a LU with an unknown TMSI is not covered.</p>
<p>Upon LU by TMSI, a new vlr_subscr gets created with that (so far unknown) TMSI.<br />The VLR asks for the IMSI identity.<br />When the response comes back, osmo-msc should in fact look up whether this IMSI is already attached in the VLR, which it fails to do.<br />Instead the new vlr_subscr also gets assigned that IMSI, and hence we have an evil twin in the VLR.</p>
<p>This occurs because the TC_lu_by_tmsi_noauth_unknown does not do an IMSI-Detach in the end,<br />but it still acks the TMSI-Reallocation, after which the initial TMSI is no longer kept in the VLR.<br />The second test run starts with the initial TMSI again, which is then regarded as unknown...</p>
<p>We need a separate test case playing through this scenario: attached subscr does LU with an unknown TMSI.</p>
<p>(btw, the failure is not at all related to the invalid TMSI that is also sent in this test case.)</p> OsmoMSC - Bug #4721: osmo-msc creates evil-twin entries in the VLR when an already attached IMSI does a LU by an unknown TMSI (was: MSC_Tests.TC_lu_by_tmsi_noauth_unknown fails sporadically locally)https://projects.osmocom.org/issues/4721?journal_id=194292020-08-19T12:28:15Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Assignee</strong> changed from <i>neels</i> to <i>laforge</i></li></ul><p>it's not that trivial though: at the time of the ID Response, the subscriber may not yet be authenticated.<br />So anyone could come along, send an arbitrary IMSI in the ID Response, and essentially DoS on the VLR state of an already attached authentic subscriber.<br />The pre-existing VLR state must not be affected by an unauthenticated request.</p>
<p>It seems that osmo-msc must keep an unvalidated duplicate vlr_subscr entry, and only ensure a single validated vlr_subscr entry at the time of successful auth.</p>
<p>This potentially goes pretty deep into the VLR design: so far the assumption is that at most one vlr_subscr per IMSI exists.<br />The GSUP response is identified by IMSI, hence it potentially has to update multiple vlr_subscr entries.<br />Are there other code paths that need to deal with multiple vlr_subscr for the same IMSI?</p>
<p>Idea: make the current vlr_subscr_find_by_imsi() return only the one entry that has passed authentication.<br />Code paths that deal with unauthenticated vlr_subscr could use a separate vlr_subscr_find_by_imsi2() (or so) API.</p>
<p>A quick solution for now could remove the previous vlr_subscr from the VLR and add the new one, in the hope that it will also authenticate later...<br />(considering that the new vlr_subscr already may have lu_fsm, auth_fsm etc associated on it)</p>
<p>So, how important is this aspect at this point in time?</p> OsmoMSC - Bug #4721: osmo-msc creates evil-twin entries in the VLR when an already attached IMSI does a LU by an unknown TMSI (was: MSC_Tests.TC_lu_by_tmsi_noauth_unknown fails sporadically locally)https://projects.osmocom.org/issues/4721?journal_id=194302020-08-19T12:51:22Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Subject</strong> changed from <i>MSC_Tests.TC_lu_by_tmsi_noauth_unknown fails sporadically locally</i> to <i>osmo-msc creates evil-twin entries in the VLR when an already attached IMSI does a LU by an unknown TMSI (was: MSC_Tests.TC_lu_by_tmsi_noauth_unknown fails sporadically locally)</i></li></ul><p>all of this seemed vaguely familiar, and now I found this patch from about a year ago:<br /><a class="external" href="http://git.osmocom.org/osmo-msc/commit/?h=neels/vlr_evil_twin3&id=be707bf7c7e30e4b1943fe7487d84e7ed70eb1cb">http://git.osmocom.org/osmo-msc/commit/?h=neels/vlr_evil_twin3&id=be707bf7c7e30e4b1943fe7487d84e7ed70eb1cb</a><br />That patch does not cover the DoS aspect, I guess that is why I did not submit it for review.</p> OsmoMSC - Bug #4721: osmo-msc creates evil-twin entries in the VLR when an already attached IMSI does a LU by an unknown TMSI (was: MSC_Tests.TC_lu_by_tmsi_noauth_unknown fails sporadically locally)https://projects.osmocom.org/issues/4721?journal_id=194312020-08-19T12:57:09Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>test case for LU: <a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19718">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19718</a></p> OsmoMSC - Bug #4721: osmo-msc creates evil-twin entries in the VLR when an already attached IMSI does a LU by an unknown TMSI (was: MSC_Tests.TC_lu_by_tmsi_noauth_unknown fails sporadically locally)https://projects.osmocom.org/issues/4721?journal_id=194332020-08-19T13:55:24Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>In above mentioned patch from a year ago, I made provision to also handle ID Responses during CM Service Request and Paging Response.<br />Adding ttcn3 tests I realize that a CM Service Request for an unknown TMSI gets rejected immediately (pending a LU from the MS).</p>
<p>Tests for those were still missing:</p>
<p>CM-Service: <a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19719">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19719</a></p>
<p>Paging Response: <a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19721">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19721</a><br />actually uncovers a crash in osmo-msc, see <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: crash when a Paging Response contains an unknown mobile identity (Resolved)" href="https://projects.osmocom.org/issues/4724">#4724</a></p> OsmoMSC - Bug #4721: osmo-msc creates evil-twin entries in the VLR when an already attached IMSI does a LU by an unknown TMSI (was: MSC_Tests.TC_lu_by_tmsi_noauth_unknown fails sporadically locally)https://projects.osmocom.org/issues/4721?journal_id=201762020-10-28T20:28:40Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-3 priority-2 priority-default closed" href="/issues/4191">Bug #4191</a>: vlr.c:762 Trying to dispatch event 1 to non-existent FSM instance!</i> added</li></ul> OsmoMSC - Bug #4721: osmo-msc creates evil-twin entries in the VLR when an already attached IMSI does a LU by an unknown TMSI (was: MSC_Tests.TC_lu_by_tmsi_noauth_unknown fails sporadically locally)https://projects.osmocom.org/issues/4721?journal_id=211222021-02-06T09:46:17Zlaforge
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Stalled</i></li><li><strong>Assignee</strong> changed from <i>laforge</i> to <i>neels</i></li></ul><p>neels wrote:</p>
<blockquote>
<p>So, how important is this aspect at this point in time?</p>
</blockquote>
<p>I think we care most about consistency of our internal state (and passing the existing test suite) than to care about a DoS possibility at this point. OsmoMSC is primarily used in lab / test environments, for small/private networks etc.</p>
<p>Probably best to separate that second part out as a separate issue?</p> OsmoMSC - Bug #4721: osmo-msc creates evil-twin entries in the VLR when an already attached IMSI does a LU by an unknown TMSI (was: MSC_Tests.TC_lu_by_tmsi_noauth_unknown fails sporadically locally)https://projects.osmocom.org/issues/4721?journal_id=296962024-03-26T03:02:18Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Status</strong> changed from <i>Stalled</i> to <i>In Progress</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>90</i></li></ul><p>I have hit this same problem again, when testing LU by TMSI identity when 'no assign-tmsi' is configured, for a customer.</p>
<p>This time I have implemented a solution that discards a previous evil twin VLR entry, adopting any pending paging from it.</p>
<p>This fix also makes the long-failing MSC_Tests.TC_attached_imsi_lu_unknown_tmsi finally pass.<br />It's been three and a half years! Nice to finally catch up with this one.</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-msc/+/36452">https://gerrit.osmocom.org/c/osmo-msc/+/36452</a></p>