Summary

Missing Authorization vulnerability in the device and deployment group pages in nerves-hub nerveshubweb allows an authenticated organization member with the view role to change devices and deployment groups via LiveView events reserved for the manage role. The event handlers that add and delete device certificates, add and remove tags, overwrite or clear a device's manual location, remove a device from its deployment group, move matched devices into a deployment group or remove unmatched ones, import devices from a CSV, and start, retry or delete firmware delta builds carry out the change without calling authorized!/2, and the pages render the controls to every member.

A view member can add a certificate that lets whoever holds its key connect as the device, delete a certificate so the device can no longer authenticate with it, and change which deployment group, and so which firmware release, a device receives. Everything stays within the organizations the member belongs to.

This issue affects nerveshub: from 1.0.0 before 2.5.3.

Details

The dashboard reads the member's role into currentscope when a page mounts, and each privileged event handler is expected to call authorized!/2 with the permission it needs, all of which resolve to the manage role in lib/nerveshubweb/helpers/authorization.ex. These handlers never do:

Device settings tab (NervesHubWeb.Components.DevicePage.SettingsTab): hookedevent/3 for delete-certificate, and handleprogress/3 for the certificate upload, which should require device:update.

Device details tab (NervesHubWeb.Components.DevicePage.DetailsTab): hookedevent/3 for add-tag, remove-tag, save-location-changes and clear-manual-location-information (device:update), and remove-from-deployment-group (device:set-deployment-group).

Deployment group page (NervesHubWeb.Live.DeploymentGroups.Show and NervesHubWeb.Components.DeploymentGroupPage.Summary): handleevent/3 for move-matched-devices-to-deployment-group and remove-unmatched-devices-from-deployment-group, and handleprogress/3 for the devicecsv upload (device:set-deployment-group), plus generate-firmware-deltas, retrydelta and deletedelta (deploymentgroup:update).

The pages show every one of these controls to view members, so each change takes a click, and a client can send the events directly over the LiveView socket regardless.

Proof of concept

1. Create deployment group canary with conditions matching tag beta. 2. Create deviceoutsidematch in the same product with tag beta and no deployment group, and deviceinsidemismatch in deployment group canary with tag foo. 3. Sign in as a member of the organization with the view role and open /org/<org>/<product>/deploymentgroups/canary. 4. Click Move device(s): deviceoutsidematch is now in canary. Click Remove device(s): deviceinsidemismatch no longer has a deployment group. 5. As the same member, open a device in the product and add a tag. The tag is saved. 6. On the device's settings tab, delete a certificate, or upload a self-signed one. The change is saved, and a client presenting the uploaded certificate connects as the device.

Impact

An organization member with the view role can add or delete a device's certificates, change its tags and location, and move devices into or out of deployment groups, which changes the firmware release they receive. An added certificate lets whoever holds its key connect as the device and persists after the member leaves. Everything stays within the organizations the member belongs to.

Workarounds

No configuration closes the hole. Until the upgrade, give the view role only to people you would trust with the manage role on that organization's devices.

Solutions

Upgrading does not remove a certificate that a view member already added. After upgrading, review each device's certificates and delete any you do not recognize.

Summary

Missing Authorization vulnerability in the device and deployment group pages in nerves-hub nerveshubweb allows an authenticated organization member with the view role to change devices and deployment groups via LiveView events reserved for the manage role. The event handlers that add and delete device certificates, add and remove tags, overwrite or clear a device's manual location, remove a device from its deployment group, move matched devices into a deployment group or remove unmatched ones, import devices from a CSV, and start, retry or delete firmware delta builds carry out the change without calling authorized!/2, and the pages render the controls to every member.

A view member can add a certificate that lets whoever holds its key connect as the device, delete a certificate so the device can no longer authenticate with it, and change which deployment group, and so which firmware release, a device receives. Everything stays within the organizations the member belongs to.

This issue affects nerveshub: from 1.0.0 before 2.5.3.

Details

The dashboard reads the member's role into currentscope when a page mounts, and each privileged event handler is expected to call authorized!/2 with the permission it needs, all of which resolve to the manage role in lib/nerveshubweb/helpers/authorization.ex. These handlers never do:

Device settings tab (NervesHubWeb.Components.DevicePage.SettingsTab): hookedevent/3 for delete-certificate, and handleprogress/3 for the certificate upload, which should require device:update.

Device details tab (NervesHubWeb.Components.DevicePage.DetailsTab): hookedevent/3 for add-tag, remove-tag, save-location-changes and clear-manual-location-information (device:update), and remove-from-deployment-group (device:set-deployment-group).

Deployment group page (NervesHubWeb.Live.DeploymentGroups.Show and NervesHubWeb.Components.DeploymentGroupPage.Summary): handleevent/3 for move-matched-devices-to-deployment-group and remove-unmatched-devices-from-deployment-group, and handleprogress/3 for the devicecsv upload (device:set-deployment-group), plus generate-firmware-deltas, retrydelta and deletedelta (deploymentgroup:update).

The pages show every one of these controls to view members, so each change takes a click, and a client can send the events directly over the LiveView socket regardless.

Proof of concept

1. Create deployment group canary with conditions matching tag beta. 2. Create deviceoutsidematch in the same product with tag beta and no deployment group, and deviceinsidemismatch in deployment group canary with tag foo. 3. Sign in as a member of the organization with the view role and open /org/<org>/<product>/deploymentgroups/canary. 4. Click Move device(s): deviceoutsidematch is now in canary. Click Remove device(s): deviceinsidemismatch no longer has a deployment group. 5. As the same member, open a device in the product and add a tag. The tag is saved. 6. On the device's settings tab, delete a certificate, or upload a self-signed one. The change is saved, and a client presenting the uploaded certificate connects as the device.

Impact

An organization member with the view role can add or delete a device's certificates, change its tags and location, and move devices into or out of deployment groups, which changes the firmware release they receive. An added certificate lets whoever holds its key connect as the device and persists after the member leaves. Everything stays within the organizations the member belongs to.

Workarounds

No configuration closes the hole. Until the upgrade, give the view role only to people you would trust with the manage role on that organization's devices.

Solutions

Upgrading does not remove a certificate that a view member already added. After upgrading, review each device's certificates and delete any you do not recognize.