<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><div>My unit's EEPROM got zeroed when I flashed in a new program and forgot to uncheck the EEPROM, so not a user scenario. That just made me think that if there were a bug that zeroed on the EEPROM, it would lock the device, not make it open to intruders.</div><div><br></div><div> Tom</div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div><div>On 7/21/15, 7:02 PM, "Mark Webb-Johnson" <<a href="mailto:mark@webb-johnson.net">mark@webb-johnson.net</a>> wrote:</div></div><div><br></div><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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 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 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 href="mailto:dexter@expeedo.de" class="">dexter@expeedo.de</a>><br class="">Reply-To: OVMS Developers <<a 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 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 class=""><br class="">-- <br class="">Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal<br class="">Fon 02333 / 833 5735 * Handy 0176 / 206 989 26<br class=""><br class="">_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.teslaclub.hk" class="">OvmsDev@lists.teslaclub.hk</a><br class=""><a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br class=""></blockquote><br class=""><br class="">_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.teslaclub.hk" class="">OvmsDev@lists.teslaclub.hk</a><br class=""><a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br class=""></div></blockquote></div><br class=""></div></div></div>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</span></body></html>