Seriously, I don’t know what is going on here. yesterday out of the blue, Vera replaced my modified sPhone plugin with the original version by itsself.
I didn’t do anything with those files. When I switched on my iPhone this mornig, my vera was back to the brocken/original plugin.
Could anyone please try to explain what might be going on here??? Maybe I should cut off Veras internet connection once and for all.
TIA
Umtauscher
Which firmware version and what’s the uptime?
Firmware 1.0.985
What do you mean by uptime?
see MCV’s post at the bottom of this thread:
http://forum.micasaverde.com/index.php?topic=3103.msg14160#new
apparently they can and DID push an updated smartphone plugin.
@michaelk, I don’t think that post is related to this issue.
@umtauscher , 985 seems to be severely broken - Vera reboots quite often for me w/o any activity. The list of Luup files is empty, while the modified Smartphone plugin is still there in /etc/cmh-ludl. The Plugin gallery shows some “Not found” errors…
Ya, I hadn’t noticed Vera rebooting, but I just checked by uptime and it is only 8 minutes.
Oh, that’s just great!
I am feeling I’m in the hands of hobby programmers!
Who on earth allowed MCV to mess with my installation? I even disabled all findvera.com and remote access.
THIS IS A SERIOUS SECURITY BREACH!!! unbelieveable!
I will Try to disable all access for Vera to all sites that have anything to do with MCV. I wonder if it will work then. (and doubt it)
BTW my uptime is in evarage about 10 mins with 985. Great job! But now I know why my z-wave network is so unreliable.
Thanks for your input
Umtauscher
We found the issue, and pushed an update to the plugin.
Within 24 hours your Vera should automatically update the
plugin, and then try it again.
@MCV:
Really great! Thanks for downgrading my plugin to a non-functional state
When will motion, temperature and brightness be fixed?
Assuming you have auto backup left on, you can log in to findvera.com and you’ll have 7 days of backup files, and your prior version will be in /etc/cmh-lu or /etc/cmh-ludl.
Also, the code will always look for a plugin [whatever].lua first, and, only if it doesn’t exist, it will uncompress [whatever].lua.lzo. So, if you’re making local changes, say to L_sPhone.lua (the smartphone plugin), then an auto update of the plugin shouldn’t have any effect because it will only download the .lzo, but will not remove your uncompressed .lua file, which takes precedence.
I’m not sure it’s really a security risk per se. We don’t have access to your box, and we can’t force a firmware upgrade. It is true that Vera will check if it has the latest version of the plugins and auto-update. Windows, for example, does this by default. I agree though that if a user is going to make local changes or for some reason doesn’t want the update to occur, so I created a mantis for it: http://bugs.micasaverde.com/view.php?id=915
More importantly, though, the smartphone and wap plugins were supposed to fix a minor issue, not break anything. Several people tested the plugin updates before they were published and said they work fine. Would someone who is having a problem with the new plugin mind turning on verbose logging, reproducing the problem, and then submitting a trouble ticket explaining exactly what’s going wrong?
When you say your plugin was “downgraded”, did you find some problem and fix it yourself? If so, do you want to share what fix you made and we can test it and put in the main branch so everybody gets it?
Here is the thread with several Smartphone plugin modifications, pointing to the last version:
http://forum.micasaverde.com/index.php?topic=3134.msg13378#msg13378
I’m surprised you are not aware of those modifications, discussed on the forum…
Also, Ap15e updated 2 mantis reports to point back to the modifications.
BTW, regarding users experiencing reboots/uptime issues, we definitely want to fix this problem right away. Would somebody who is experiencing this mind opening the tech support back door to let us look at the system logs and dmesgs to see what’s causing the box to reboot? If so, you can submit a trouble ticket and put ‘for aaron’ in the subject.
got it. I don’t do the lua coding, but I’ll talk to Javier about it.
@MCV, use trouble ticket 1871 for mine. It’s on 1.0.985, and I did two samples tonight, the first reported 50 mins uptime, the second reported 39 mins, so something’s screwy.
Can you mod the “phone home” thing you use for FindVera.com enabled boxes to periodically report their uptime? That might also give you a better correlation between uptime and version.
You’d have to look at the data in aggregate, to avoid the folks that are manually rebooting, but it would work reasonably well for these situations.
Why would you assume that? I am concered about the saftey of this thing and so I most certainly don’t want to backup any settings on an external webserver that I have no contol of.
That may have been the concept once, but this is certainly not true any more. I modified the lua code and uploaded it to my Vera. The new/old plugin was installed without my consent. Even if the functionality would not have been broken. I want to install updates based on my decision and not anyones else!
Well, if you are not sure, I am! You being able to install whatever plugin you want in my internal network poses a major security risk to my house. Anyone at MCW could install a trojan/backdoor or whatever on any Vera. If that’s no security concern, I don’t know what is.
Yes and I have disabled “findvera.com” and I don’t want any autoupdates!
Yes, are you like M$? And BTW you can turn that off in any Windows installation.
To state the obvious again, please see to it, that you respect the whishes of the owner of the Vera, if he/she wants automatic updates, backups or anything else that involves external servers. Otherwise I must see Vera as hostile device in my network.
For now I have blocked all relevant traffic to and from MCW servers to MY Vera. I still don’t know if that will cause any troubles, but I am not willing to expose my internal network to anyone on the Internet.
Sincerly
Umtauscher
umtauscher, I appreciate your security concerns. I agreed with you that users should have the choice of allowing auto-updates. Keep in mind, the binary code (firmware) does not auto-update. The only thing that auto-updates is the Lua plugins, which come in source code form. We can’t, of course, install a plugin on your box, we can only post an update to one you already installed and have it update. And, if we did include a trojan horse or other malware in a plugin update, you’d have the source code, you’d post the source code in the forum, and it would create a devastating fire storm. So, I’m not disagreeing with you, only saying that we (MCV) has a very high incentive to be sure you don’t get a trojan horse or other malware. And, to be honest, if there were a crazy programmer on the staff who wanted to slip in malware and figured out how to get it past QA, you know he’d do it to one of the binaries (ie in a firmware upgrade), where it’d be easier to hide, than in a plugin, where you’d have all the source code and immediately see what’s going on. Also, it’d be almost impossible to sneak malware in through a Luup plugin. The source code for them is shown to the public and not only tested, but reviewed, before it gets into a plugin. So, I just don’t see how it would be possible to slip malware in a Luup plugin. Regardless, we’ll make the change.
Thanks!
I really appreciate your comment on this and taking my concerns seriously.
Sincerely
Umtauscher
BTW MCV, could it be that that “update” process also is responsible for my gc100 plugin reinstalling itsself from time to time.
I have uninstalled it about 10 times and it keeps coming back again and again.
Thanks for listening to your users’ security concerns. You are probably right
that an attacker from within MCV would use the firmware to inject malware -
but an attacker from outside would use the plugin auto-update mechanism to
distribute her/his code to your users.
an attacker from outside would use the plugin auto-update mechanism to distribute her/his code to your users.
How would that be possible? I mean Vera goes to a pre-defined server (the Luup plugin download server) to request the plugin, and only we have access to that server and what goes on it, and any 3rd party Luup code is reviewed by us before posting.
So, the only way I can see this happening is that a 3rd party hacker is able to hyjack an ISP and take over the DNS records and force the findvera.com requests to go to another server, which looks and acts like ours, but feeds malware instead. Now, if a hyjacker was able to take over an ISP and emulate ‘fake’ copies of web sites, what web sites would they put the effort into faking? FindVera, so they can remotely take over a handful of lights and door locks? Or Bank Of America so they can capture all your details and wire billions of dollars out of millions of accounts? Understand if a hyjacker was able to do take over FindVera like that, he could take over any web site the same way. And since we don’t hear of that ever happening, my guess is it’s nearly impossible to do, and if it did happen, it would bring down the whole financial services industry and remote control of lights and locks.
regarding the gc100, no, the update process can’t reinstall a plugin. Once you delete it, it won’t update it. Something else must be going on. We’d need to logs to know for sure.
It’s called man-in-the-middle attack. The way to defend against it is to use proper authentication techniques. The reason you don’t see this sorts of attack happening to banks very often (they do happen, BTW) is because they use “strong” authentication and channel encryption of SSL with 128/256 bit keys…
Definitely, you can make Lua plugins updateable over SSL/SSH connection as well, that would ensure they come from trusted a source, like real FindVera server. But the question still remains - should the plugins be updated automatically or not?
Best Home Automation shopping experience. Shop at Ezlo!
© 2024 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules