<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    OK, here's my fix:<br>
    <br>
<a class="moz-txt-link-freetext" href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System/commit/5647537fa893e4fc3f44eb07293b4bed34d27bdb">https://github.com/openvehicles/Open-Vehicle-Monitoring-System/commit/5647537fa893e4fc3f44eb07293b4bed34d27bdb</a><br>
    <br>
    - denies regphone / password access if resp. params are empty<br>
    - forbids par_write() on params 0 & 1 with empty values<br>
    - checks arguments of SMS PASS command and MSG command 4 to provide
    error messages to user<br>
    <br>
    This does not yet cover the auto provisioning and the SMS command
    "PARAMS" -- I'm now at 100% fully used ROM again, after excluding
    the charge control commands...<br>
    <br>
    Please check.<br>
    <br>
    Regards,<br>
    Michael<br>
    <br>
    <br>
    <br>
    <div class="moz-cite-prefix">Am 23.07.2015 um 00:12 schrieb Michael
      Balzer:<br>
    </div>
    <blockquote cite="mid:55B0155B.2060103@expeedo.de" type="cite">
      <meta content="text/html; charset=windows-1252"
        http-equiv="Content-Type">
      Tom, Mark,<br>
      <br>
      FYI: I can now confirm both security issues.<br>
      <br>
      Setting the registered phone empty will allow access from any
      mobile phone, and setting the password empty will allow using any
      password.<br>
      <br>
      I've already included the fix, but now need to exclude some more
      functions to make the Twizy build fit into the ROM space once
      again... *sigh*<br>
      <br>
      Regards,<br>
      Michael<br>
      <br>
      <br>
      <div class="moz-cite-prefix">Am 22.07.2015 um 13:18 schrieb
        Michael Balzer:<br>
      </div>
      <blockquote cite="mid:55AF7C23.8060909@expeedo.de" type="cite">
        <meta content="text/html; charset=windows-1252"
          http-equiv="Content-Type">
        <div class="moz-cite-prefix">Tom, Mark,<br>
          <br>
          I haven't tried myself, but the code is quite clear:<br>
          <br>
          <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System/blob/master/vehicle/OVMS.X/net_sms.c#L237">https://github.com/openvehicles/Open-Vehicle-Monitoring-System/blob/master/vehicle/OVMS.X/net_sms.c#L237</a><br>
          <br>
          strlen(p) is 0 on an empty REGPHONE, so the result is true.
          Only "REGISTER" and "AP" need the password, all other commands
          should succeed from any phone with an empty REGPHONE.<br>
          <br>
          The acc module is not included in the Twizy firmware (due to
          ROM space).<br>
          <br>
          Securing par_write() is a good idea, but the data loss need
          not have been caused by a par_write() operation. I know of at
          least one user module that loses and garbles EEPROM contents
          frequently. There may be some general hardware issue, at least
          with the modules delivered during the last 6-9 months or so.<br>
          <br>
          I'm also having single byte EEPROM errors occasionally after
          flashing. These mostly affect the first byte of some parameter
          slot, only bit flips up to now but a change to 0 would empty
          that slot.<br>
          <br>
          If I can confirm the problem I will include both the
          par_write() securing and the auth fail-close change into the
          fix.<br>
          <br>
          Regards,<br>
          Michael<br>
          <br>
          <br>
          <br>
          Am 22.07.2015 um 04:02 schrieb Mark Webb-Johnson:<br>
        </div>
        <blockquote
          cite="mid:E29E01FE-5673-45E8-B48F-63ED37029FC1@webb-johnson.net"
          type="cite">
          <meta http-equiv="Content-Type" content="text/html;
            charset=windows-1252">
          Michael, Tom,
          <div class=""><br class="">
          </div>
          <div class="">Not sure how the entire EEPROM can be erased.
            The code in par_write(), par_set() and par_setbin() seems to
            limit the write to PARAM_MAX_LENGTH. The EEPROM can’t be
            overwritten by normal code and it takes quite a bit of
            register mashing to write to it. Can someone have a look
            over the params.c functions and see if you have any guesses
            as to the cause? I think it is important to identify the
            root cause.</div>
          <div class=""><br class="">
          </div>
          <div class="">I did fix an error in the acc code, December
            last year, that caused an off-by-one parameter to be set:</div>
          <div class=""><br class="">
          </div>
          <blockquote style="margin: 0 0 0 40px; border: none; padding:
            0px;" class="">
            <div class="">
              <div class="">commit
                5269c870b1858f58098b16b39d10beb2b0e3b330</div>
              <div class="">Author: Mark Webb-Johnson <<a
                  moz-do-not-send="true"
                  href="mailto:mark@webb-johnson.net" class="">mark@webb-johnson.net</a>></div>
              <div class="">Date:   Mon Dec 8 13:11:32 2014 +0800</div>
              <div class=""><br class="">
              </div>
              <div class="">    Setting acc params, without location,
                when not in a location, leads to off-by-one index
                parameter write</div>
            </div>
            <div class=""><br class="">
            </div>
            <div class="">
              <div class="">diff --git a/vehicle/OVMS.X/acc.c
                b/vehicle/OVMS.X/acc.c</div>
              <div class="">index 4935590..1bf430c 100644</div>
              <div class="">--- a/vehicle/OVMS.X/acc.c</div>
              <div class="">+++ b/vehicle/OVMS.X/acc.c</div>
              <div class="">@@ -948,7 +948,7 @@ BOOL acc_cmd_params(BOOL
                sms, char* caller, char *arguments)</div>
              <div class="">     }</div>
              <div class=""><br class="">
              </div>
              <div class="">   net_send_sms_start(caller);</div>
              <div class="">-  if (k<0)</div>
              <div class="">+  if (k<=0)</div>
              <div class="">     {</div>
              <div class="">     s =
                stp_rom(net_scratchpad,ACC_NOTHERE);</div>
              <div class="">     }</div>
            </div>
          </blockquote>
          <div class=""><br class="">
          </div>
          <div class="">That is in the development branch, but is not in
            the standard firmware. But, the worst affect of that would
            be to overwrite PARAM_COOLDOWN (#15) (and easy to see as the
            overwritten value is base64).</div>
          <div class=""><br class="">
          </div>
          <div class="">It seems to be that params.c sets the default
            values to be:</div>
          <div class=""><br class="">
          </div>
          <blockquote style="margin: 0 0 0 40px; border: none; padding:
            0px;" class="">
            <div class="">#0 PARAM_REGPHONE = NOPHONE</div>
            <div class="">#1 PARAM_MODULEPASS = OVMS</div>
            <div class="">#2 PARAM_MILESKM = K</div>
          </blockquote>
          <div class=""><br class="">
          </div>
          <div class="">My only concern with removing the fail-open to
            both PARAM_REGPHONE (net_sms_checkcaller) <b class=""><i
                class="">and</i></b> PARAM_MODULEPASS
            (net_sms_checkpassarg) is that if they were both blank then
            the user would be completely locked out of the module. Only
            solution would be a complete re-flash and reset to default
            parameters.</div>
          <div class=""><br class="">
          </div>
          <div class="">Another option would be to hard-code change
            par_write() to <b class="">refuse</b> to write a blank
            password to #1. Then, we could go ahead and change
            net_sms_checkcaller() to not fail open for registered phone
            number. From what I can see, <b class="">all</b> writes to
            EEPROM go through par_write() in params.c.</div>
          <div class=""><br class="">
          </div>
          <div class="">Regards, Mark.</div>
          <div class=""><br class="">
            <div>
              <blockquote type="cite" class="">
                <div class="">On 22 Jul, 2015, at 8:39 am, Tom Saxton
                  <<a moz-do-not-send="true"
                    href="mailto:tom@idleloop.com" class="">tom@idleloop.com</a>>
                  wrote:</div>
                <br class="Apple-interchange-newline">
                <div class="">Hi Michael,<br class="">
                  <br class="">
                  Have you confirmed the security problem? I've had time
                  when the EEPROM got<br class="">
                  zeroed out and I couldn't access the module via SMS at
                  all. I had to<br class="">
                  reflash with a valid EEPROM image in order to
                  re-register my cell number.<br class="">
                  <br class="">
                  I'm pretty careful not to share my OVMS phone number
                  with anyone. If<br class="">
                  someone unfriendly had it, they could send it a bunch
                  of SMS messages each<br class="">
                  of which costs me a penny. Do that 1,000 times, and
                  they've disabled my<br class="">
                  box until I refill my H2O account.<br class="">
                  <br class="">
                    Tom<br class="">
                  <br class="">
                  -----Original Message-----<br class="">
                  From: Michael Balzer <<a moz-do-not-send="true"
                    href="mailto:dexter@expeedo.de" class="">dexter@expeedo.de</a>><br
                    class="">
                  Reply-To: OVMS Developers <<a
                    moz-do-not-send="true"
                    href="mailto:ovmsdev@lists.teslaclub.hk" class="">ovmsdev@lists.teslaclub.hk</a>><br
                    class="">
                  Date: Tuesday, July 21, 2015 at 9:23 AM<br class="">
                  To: OVMS Developers <<a moz-do-not-send="true"
                    href="mailto:ovmsdev@lists.teslaclub.hk" class="">ovmsdev@lists.teslaclub.hk</a>><br
                    class="">
                  Subject: [Ovmsdev] Registered phone / password
                  security issue<br class="">
                  <br class="">
                  <blockquote type="cite" class="">Hi everyone,<br
                      class="">
                    <br class="">
                    some users including me experienced loss or garbling
                    of eeprom<br class="">
                    parameters. I once saw by chance that my registered
                    phone number had<br class="">
                    turned empty -- I seldom need to use SMS, so I only
                    saw this when<br class="">
                    checking the parameter list on the App for another
                    config.<br class="">
                    <br class="">
                    The same now also occured to another user I'm in
                    contact with, and it<br class="">
                    now turned out that's not only annoying but a
                    security issue:<br class="">
                    <br class="">
                    The current logic of net_sms_checkcaller() allows
                    access to any phone<br class="">
                    number if the parameter is empty. The same applies
                    to<br class="">
                    net_sms_checkpassarg(), which will allow any
                    password to be used if no<br class="">
                    password is stored.<br class="">
                    <br class="">
                    As this kind of data loss can only be detected by
                    checking the<br class="">
                    parameters, it's possible to check for "open"
                    modules by just trying to<br class="">
                    access them from time to time -- you only need to
                    know the SIM card<br class="">
                    number.<br class="">
                    <br class="">
                    I'm about to submit a change for both functions to
                    NOT allow access if<br class="">
                    their respective param slots are empty.<br class="">
                    <br class="">
                    As the initial flash contents has the "OVMS"
                    standard password, a<br class="">
                    completely lost module should still be restorable by
                    re-flashing.<br class="">
                    <br class="">
                    Do I miss something? Is there any reason for the
                    "empty=wildcard"<br class="">
                    behaviour?<br class="">
                    <br class="">
                    Regards,<br class="">
                    Michael<br>
                  </blockquote>
                </div>
              </blockquote>
            </div>
          </div>
        </blockquote>
        <br>
        <pre class="moz-signature" cols="50">-- 
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
</pre>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
OvmsDev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
      </blockquote>
      <br>
      <pre class="moz-signature" cols="72">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
  </body>
</html>