Browsing /hotspot endpoint bricks device

[mrampersad]

Problem

I accidentally browsed to /hotspot from a remote computer and Screenly wiped its wireless network configuration and created a Screenly-RANDOM SSID. This happens instantly and before my computer receives any response. Since the response contains the security key, it is lost.

After rebooting, the Screenly did not enter first-boot mode because the /home/pi/.screenly/wifi_set file still exists on the disk.

I also tested using http://127.0.0.1/hotspot and http://127.0.0.1:8080/hotspot as an asset. This also bricks the device. Thankfully these URLs are not persisted to the asset database for some reason that I was not able to identify.

Based on the way the hotspot endpoint works, I do not believe it's possible to add HTTP authentication to it, and so this may be a DoS vector as well.

Analysis

It appears that the /hotspot endpoint is only intended for consumption by viewer.py, and should only be active if wifi is unconfigured. Here are two possible fixes for this issue:

• Have the /hotspot endpoint abort if /home/pi/.screenly/wifi_set exists.
• Move the /hotspot endpoint logic out of server.py and into viewer.py so that it cannot be run by anyone else.

[vpetersson]

Very good analysis and catch, @mrampersad. Adding this to the sprint.

[vpetersson]

I spent some time thinking about this today. Here are my current thoughts.

• We create a file on disk called something like ~/.screenly/not-initialized
• We introduce a new systemd service. The service will launch a bash script that checks if the above file exist. If it does, it will fire off a sequence of events:
  • Check if there is any internet connection available over Ethernet. If so, clean up and exit.
  • If not, launch resin-wifi-connect on something like locahost:8888.
  • When done, delete the file and exit gracefully.
• Moreover, we also configure Nginx to check if the file exist using an if statement. If, and only if the file exist, it will take activate the reverse proxy to the captive portal.

We can also add a functionality in the UI to allow to 'reset wifi config' by creating the file again.

Perhaps more importantly, we can start decommission the use of sudo in both server and viewer to start improving security and start moving towards a container based structure.

[mrampersad]

This sounds like a reasonable solution. I have one note. The systemd service has a path which can delete the not-initialized file without launching resin-wifi-connect (in the event an internet connection is detected). This is fine for an out-of-the-box-experience, but not for a button called "reset wifi config". It might confuse the user to click a button with this name and for no wifi configuration to come up. I recommend something like "re-run network detection".

The network reset button should present a big red warning since it may require the user to look at the TV screen to get back online. A message should be presented instructing the user that is not recommended to proceed if the TV screen cannot be seen.

[vpetersson]

@mrampersad Yeah those are good pointers. We should definitely have a big warning sign for that.

[vpetersson]

Solved in #812.