# Need Client to Reject Earlier Artifacts

**URL:** https://hub.mender.io/t/need-client-to-reject-earlier-artifacts/1524
**Category:** General Discussions
**Created:** [February 10, 2020, 10:27pm UTC](https://hub.mender.io/t/need-client-to-reject-earlier-artifacts/1524 "2020-02-10T22:27:44Z")
**Posts on this page:** 7
**Page:** 1

<div class="post-metadata">

### Author: ![ckelloug2](https://avatars.discourse-cdn.com/v4/letter/c/c6cbf5/32.png) [@ckelloug2](https://hub.mender.io/u/ckelloug2)
#### Post date: [February 10, 2020, 10:27pm UTC](https://hub.mender.io/t/need-client-to-reject-earlier-artifacts/1524/1 "2020-02-10T22:27:44Z")

</div>

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?

---

<div class="post-metadata">

### Author: ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)
#### Post date: [February 11, 2020, 9:17am UTC](https://hub.mender.io/t/need-client-to-reject-earlier-artifacts/1524/2 "2020-02-11T09:17:36Z")

</div>

I suppose the only way to achieve this today would be using a [state-script](https://docs.mender.io/2.2/artifacts/state-scripts), 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.

---

<div class="post-metadata">

### Author: ![kacf](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/kacf/32/146_2.png) [@kacf](https://hub.mender.io/u/kacf)
#### Post date: [February 11, 2020, 11:54am UTC](https://hub.mender.io/t/need-client-to-reject-earlier-artifacts/1524/3 "2020-02-11T11:54:59Z")

</div>

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](https://github.com/mendersoftware/mender/blob/master/tests/rootfs-image-v2). In the Download state you could add some logic to do that kind of checking (see [the update module API](https://github.com/mendersoftware/mender/blob/master/Documentation/update-modules-v3-file-api.md#download-state)). 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.

---

<div class="post-metadata">

### Author: ![SuicidalLabRat](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/suicidallabrat/32/311_2.png) [@SuicidalLabRat](https://hub.mender.io/u/SuicidalLabRat)
#### Post date: [February 13, 2020, 11:11pm UTC](https://hub.mender.io/t/need-client-to-reject-earlier-artifacts/1524/4 "2020-02-13T23:11:13Z")

</div>

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-

---

<div class="post-metadata">

### Author: ![ckelloug2](https://avatars.discourse-cdn.com/v4/letter/c/c6cbf5/32.png) [@ckelloug2](https://hub.mender.io/u/ckelloug2)
#### Post date: [February 14, 2020, 1:44am UTC](https://hub.mender.io/t/need-client-to-reject-earlier-artifacts/1524/5 "2020-02-14T01:44:27Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![drewmoseley](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/drewmoseley/32/47_2.png) [@drewmoseley](https://hub.mender.io/u/drewmoseley)
#### Post date: [February 14, 2020, 3:25pm UTC](https://hub.mender.io/t/need-client-to-reject-earlier-artifacts/1524/6 "2020-02-14T15:25:50Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![kacf](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/kacf/32/146_2.png) [@kacf](https://hub.mender.io/u/kacf)
#### Post date: [February 17, 2020, 8:32am UTC](https://hub.mender.io/t/need-client-to-reject-earlier-artifacts/1524/7 "2020-02-17T08:32:54Z")

</div>

You are correct, only Update Modules have access to the artifact content, not state scripts.
