[Ovmsdev] Registered phone / password security issue
Michael Balzer
dexter at expeedo.de
Thu Jul 23 06:58:24 HKT 2015
OK, here's my fix:
https://github.com/openvehicles/Open-Vehicle-Monitoring-System/commit/5647537fa893e4fc3f44eb07293b4bed34d27bdb
- denies regphone / password access if resp. params are empty
- forbids par_write() on params 0 & 1 with empty values
- checks arguments of SMS PASS command and MSG command 4 to provide
error messages to user
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...
Please check.
Regards,
Michael
Am 23.07.2015 um 00:12 schrieb Michael Balzer:
> Tom, Mark,
>
> FYI: I can now confirm both security issues.
>
> Setting the registered phone empty will allow access from any mobile
> phone, and setting the password empty will allow using any password.
>
> 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*
>
> Regards,
> Michael
>
>
> Am 22.07.2015 um 13:18 schrieb Michael Balzer:
>> Tom, Mark,
>>
>> I haven't tried myself, but the code is quite clear:
>>
>> https://github.com/openvehicles/Open-Vehicle-Monitoring-System/blob/master/vehicle/OVMS.X/net_sms.c#L237
>>
>> 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.
>>
>> The acc module is not included in the Twizy firmware (due to ROM space).
>>
>> 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.
>>
>> 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.
>>
>> If I can confirm the problem I will include both the par_write()
>> securing and the auth fail-close change into the fix.
>>
>> Regards,
>> Michael
>>
>>
>>
>> Am 22.07.2015 um 04:02 schrieb Mark Webb-Johnson:
>>> Michael, Tom,
>>>
>>> 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.
>>>
>>> I did fix an error in the acc code, December last year, that caused
>>> an off-by-one parameter to be set:
>>>
>>> commit 5269c870b1858f58098b16b39d10beb2b0e3b330
>>> Author: Mark Webb-Johnson <mark at webb-johnson.net
>>> <mailto:mark at webb-johnson.net>>
>>> Date: Mon Dec 8 13:11:32 2014 +0800
>>>
>>> Setting acc params, without location, when not in a
>>> location, leads to off-by-one index parameter write
>>>
>>> diff --git a/vehicle/OVMS.X/acc.c b/vehicle/OVMS.X/acc.c
>>> index 4935590..1bf430c 100644
>>> --- a/vehicle/OVMS.X/acc.c
>>> +++ b/vehicle/OVMS.X/acc.c
>>> @@ -948,7 +948,7 @@ BOOL acc_cmd_params(BOOL sms, char* caller,
>>> char *arguments)
>>> }
>>>
>>> net_send_sms_start(caller);
>>> - if (k<0)
>>> + if (k<=0)
>>> {
>>> s = stp_rom(net_scratchpad,ACC_NOTHERE);
>>> }
>>>
>>>
>>> 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).
>>>
>>> It seems to be that params.c sets the default values to be:
>>>
>>> #0 PARAM_REGPHONE = NOPHONE
>>> #1 PARAM_MODULEPASS = OVMS
>>> #2 PARAM_MILESKM = K
>>>
>>>
>>> My only concern with removing the fail-open to both PARAM_REGPHONE
>>> (net_sms_checkcaller) */and/* 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.
>>>
>>> Another option would be to hard-code change par_write() to *refuse*
>>> 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, *all* writes to EEPROM go through par_write()
>>> in params.c.
>>>
>>> Regards, Mark.
>>>
>>>> On 22 Jul, 2015, at 8:39 am, Tom Saxton <tom at idleloop.com
>>>> <mailto:tom at idleloop.com>> wrote:
>>>>
>>>> Hi Michael,
>>>>
>>>> Have you confirmed the security problem? I've had time when the
>>>> EEPROM got
>>>> zeroed out and I couldn't access the module via SMS at all. I had to
>>>> reflash with a valid EEPROM image in order to re-register my cell
>>>> number.
>>>>
>>>> I'm pretty careful not to share my OVMS phone number with anyone. If
>>>> someone unfriendly had it, they could send it a bunch of SMS
>>>> messages each
>>>> of which costs me a penny. Do that 1,000 times, and they've disabled my
>>>> box until I refill my H2O account.
>>>>
>>>> Tom
>>>>
>>>> -----Original Message-----
>>>> From: Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>>
>>>> Reply-To: OVMS Developers <ovmsdev at lists.teslaclub.hk
>>>> <mailto:ovmsdev at lists.teslaclub.hk>>
>>>> Date: Tuesday, July 21, 2015 at 9:23 AM
>>>> To: OVMS Developers <ovmsdev at lists.teslaclub.hk
>>>> <mailto:ovmsdev at lists.teslaclub.hk>>
>>>> Subject: [Ovmsdev] Registered phone / password security issue
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> some users including me experienced loss or garbling of eeprom
>>>>> parameters. I once saw by chance that my registered phone number had
>>>>> turned empty -- I seldom need to use SMS, so I only saw this when
>>>>> checking the parameter list on the App for another config.
>>>>>
>>>>> The same now also occured to another user I'm in contact with, and it
>>>>> now turned out that's not only annoying but a security issue:
>>>>>
>>>>> The current logic of net_sms_checkcaller() allows access to any phone
>>>>> number if the parameter is empty. The same applies to
>>>>> net_sms_checkpassarg(), which will allow any password to be used if no
>>>>> password is stored.
>>>>>
>>>>> As this kind of data loss can only be detected by checking the
>>>>> parameters, it's possible to check for "open" modules by just
>>>>> trying to
>>>>> access them from time to time -- you only need to know the SIM card
>>>>> number.
>>>>>
>>>>> I'm about to submit a change for both functions to NOT allow access if
>>>>> their respective param slots are empty.
>>>>>
>>>>> As the initial flash contents has the "OVMS" standard password, a
>>>>> completely lost module should still be restorable by re-flashing.
>>>>>
>>>>> Do I miss something? Is there any reason for the "empty=wildcard"
>>>>> behaviour?
>>>>>
>>>>> Regards,
>>>>> Michael
>>
>> --
>> Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
>> Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
>>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
> --
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20150723/a5d0174a/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dexter.vcf
Type: text/x-vcard
Size: 206 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20150723/a5d0174a/attachment-0002.vcf>
More information about the OvmsDev
mailing list