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 * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
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@expeedo.de> Reply-To: OVMS Developers <ovmsdev@lists.teslaclub.hk> Date: Tuesday, July 21, 2015 at 9:23 AM To: OVMS Developers <ovmsdev@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 * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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@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@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@expeedo.de> Reply-To: OVMS Developers <ovmsdev@lists.teslaclub.hk> Date: Tuesday, July 21, 2015 at 9:23 AM To: OVMS Developers <ovmsdev@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 * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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. Tom On 7/21/15, 7:02 PM, "Mark Webb-Johnson" <mark@webb-johnson.net> wrote: 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@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@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@expeedo.de> Reply-To: OVMS Developers <ovmsdev@lists.teslaclub.hk> Date: Tuesday, July 21, 2015 at 9:23 AM To: OVMS Developers <ovmsdev@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 * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Tom, Mark, I haven't tried myself, but the code is quite clear: https://github.com/openvehicles/Open-Vehicle-Monitoring-System/blob/master/v... 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@webb-johnson.net <mailto:mark@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@idleloop.com <mailto:tom@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@expeedo.de <mailto:dexter@expeedo.de>> Reply-To: OVMS Developers <ovmsdev@lists.teslaclub.hk <mailto:ovmsdev@lists.teslaclub.hk>> Date: Tuesday, July 21, 2015 at 9:23 AM To: OVMS Developers <ovmsdev@lists.teslaclub.hk <mailto:ovmsdev@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
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/v...
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@webb-johnson.net <mailto:mark@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@idleloop.com <mailto:tom@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@expeedo.de <mailto:dexter@expeedo.de>> Reply-To: OVMS Developers <ovmsdev@lists.teslaclub.hk <mailto:ovmsdev@lists.teslaclub.hk>> Date: Tuesday, July 21, 2015 at 9:23 AM To: OVMS Developers <ovmsdev@lists.teslaclub.hk <mailto:ovmsdev@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@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
OK, here's my fix: https://github.com/openvehicles/Open-Vehicle-Monitoring-System/commit/564753... - 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/v...
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@webb-johnson.net <mailto:mark@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@idleloop.com <mailto:tom@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@expeedo.de <mailto:dexter@expeedo.de>> Reply-To: OVMS Developers <ovmsdev@lists.teslaclub.hk <mailto:ovmsdev@lists.teslaclub.hk>> Date: Tuesday, July 21, 2015 at 9:23 AM To: OVMS Developers <ovmsdev@lists.teslaclub.hk <mailto:ovmsdev@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@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@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
participants (3)
-
Mark Webb-Johnson -
Michael Balzer -
Tom Saxton