<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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 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>