The device that we’re working on has the requirement that artifacts with lower serial numbers than the current one cannot be allowed to be installed. This is designed to prevent attackers from managing to install an old build with security vulnerabilities via the online update mechanism. We’re on mender client 1.7 and server 2.0.1. Does anyone have any suggestions how to accomplish this?
I suppose the only way to achieve this today would be using a state-script, e.g in ArtifactInstall_Enter you could do an inspection of the downloaded artifact and abort install if inspection shows that it does not meet a certain success criteria.
That wouldn’t be secure, since the script comes with the artifact. But more or less the same thing can be achieved with an update module. For example take a look at the example rootfs-image-v2 update module. In the Download state you could add some logic to do that kind of checking (see the update module API). You should also remove the “RootfsPartA” and “RootfsPartB” entries from /etc/mender/mender.conf to prevent the processing of normal rootfs-image artifacts.
The difference from the state script approach is that the update module has to preexist on the device, so it can’t be attacked that way.
Can you describe the threat case?
If your client and server are mutually authenticating, and further, the artifact is signed, Im not seeing the client as the attack vector. It feels like this should be an access control issue at the deployment configuration interface, as it would be at the server UI or API’s that an actor would maliciously configure a deployment for a stale artifact.
SLR-
Hi SLR,
Thanks for the question. The threat case includes local attackers with physical access to the IOT device in question. I believe it was written assuming attackers downgrading a device via a local update mechanism like a usb port. Our device doesn’t have a local update mechanism as it just does mender OTA’s so I think that your reasoning about signed artifacts is pretty solid.
Unfortunately, preventing the installation of older software versions on a device is listed as a SHALL in the security requirements for a widely used voice assistant made by a company named after a large river. Unless our team can get a clarification that the requirement doesn’t apply to our system, we have to make the client reject updates with lower serial numbers.
1 Like
Plus, at the moment, I don’t believe the state script actually has access to the version numbers to be able to make the determination. At least not in a controlled/well defined way. @kacf please correct me if I’m mistaken because that would be a nice feature.
You are correct, only Update Modules have access to the artifact content, not state scripts.