Multiple security issues

[Nhoya]

Hi, I'm listing here some security problems that need to be fixed ASAP

• [ ] Remove ws and add wss + auth
• [ ] Updates shipped on the device should be signed by Mycroft CA
• [ ] A confirmation request should be sent to the user before core update (if the updates server got compromise a malicious update can be installed silently in Mycroft devices)
• [x] Skills should release tagging for updates, not git-pull from the repo
• [ ] A confirmation request should be sent to the user before a skill update (if the skill repository got compromise, or a maintainer wakes up on the wrong side of the bed, a malicious update can be installed silently in Mycroft devices)

[forslund]

We've addressed some (one) of these concerns in #1560, msm will be locked to the commit set by the submodule in the mycroft-skills repo. So for the skill to be updated the skill maintainer need to send a PR to mycroft-skills updating the submodule reference.

[tlc]

I wonder about the websockets server open on '0.0.0.0'. There are some fun uses for external access. But someone could send events and make mycroft misbehave. If your mycroft is doing household control, you could fake an utterance to unlock your doors or turn your furnace up to 99.

I'm sending utterances now from a command line utility that uses

    send("recognizer_loop:utterance", {'utterances': [phrase]})

[Nhoya]

@tlc It's even worse than that, I already filled a bug report (almost 60 days ago) about that privately, I'll release a full PoC on 09/06/18 (since 90 days for the responsible disclosure will pass) or earlier if they fix the problem

[forslund]

The devices has the port closed in the firewall but for desktop installs this is still an issue (depending on firewall settings). A fix is in the works but in the meantime maybe we should just close the port and users wanting to use it can change it to 0.0.0.0 and regulating access themselves.

[tlc]

I am using a desktop install and the open port doesn't bother me that much in that scenario.

It's good to know the devices have it closed. What firewall do the devices use? ufw? I peeked in mycroft-core_18.2.5_armhf.deb and didn't spot anything. But I don't really know firewalls.

[forslund]

Yes, it's ufw that's used and it's set on the base image not by the package.

(Sorry for the delay, I completely missed the follow up)

[danielquinn]

Surely simply adding auth to the websocket would be simple enough and go a long way toward reducing the risks. As @tlc mentioned, there's a lot of potential to making use of a websocket (I've built a remote control for my phone!) but further development in this area is hindered by the fact that the socket isn't encrypted (browsers will often refuse to connect to a ws:// server, and mobile apps are similarly hesitant).

The current "fix" that recommends people firewall this service off isn't very helpful as it limits the expandability of the project. Instead, I suggest you (a) require auth to listen on 0.0.0.0, and (b) make wss the default.

Another decent alternative might be disabling the installation of skills when Mycroft is invoked via the websocket and instead only permit it when the physical button has been pushed. That'd prevent people from doing (some) remote evil, but without wss, you still tie the hands of would-be developers for add-ons.

[clusterfudge]

Hey @danielquinn , I actually wrote about this topic at length a couple months ago. TL/DR; version: yup, there's work to do. Building something that supports the full ecosystem (in a backwards compatible way while still pushing towards meaningfully secure systems) is a bit tricky. Aside from the implementation, a rollout strategy that doesn't disconnect all the devices in the wild is necessary.

I'm sure that proposals that address these concerns are welcome!

[ChanceNCounter]

FWIW, HiveMind is exploring - and we're pretty much settled on it, at this point - segregating bus clients. That we can do this straightforwardly is one of my favorite side effects of all time.

HiveMind was designed to provide thin clients to a central instance, using an encrypted-by-default connection, and to be nest-able. The side effect is that you can turn anything that would've been a bus listener into a thin client instead.

Properly implemented, this means that external listeners will either have to register for the bus events they want to emit and receive, or they'll need to be whitelisted as a "universal" bus listener (like a GUI.)

Put differently, we are layering the bus. Each device's HiveMind client is the arbiter of what The Programs Formerly Known As Listeners are allowed to do, and they are each connected to the HiveMind client on their own, discrete, encrypted socket that looks, to the program, like a MessageBus client.

[ChanceNCounter]

Put a third way, your device is running a HiveMind client, and the apps on your device that want to connect to Mycroft will each connect to the HiveMind client, separately. The HiveMind client will talk to Mycroft, and route messages to and from their intended recipient apps, just like the Hive itself routes messages to and from their intended devices.

The bus changes could probably be upstreamed.