Vulnerability: Monotonically increasing version numbers not checked for increasing property (from Univ. of Iowa report) #268
Comments
|
Right, so there is also a need in many Uptane installations to be able to
do a rollback to a limited number of versions prior. There are several
ways this can work. One way is for the image repository to only contain
copies of metadata for the versions which should be valid in this way. As
such, the proposed change here would break this workflow...
…On Tue, Nov 5, 2024 at 12:31 PM Yasho Bapat ***@***.***> wrote:
This vulnerability was highlighted in the University of Iowa report
<https://dl.acm.org/doi/10.1145/3678890.3678927> on Uptane's
vulnerabilities.
*Description*
The idea of repositories using monotonically increasing version numbers is
optional according to the Uptane Standard. However, disabling this feature
will result in a degradation of the security advantages offered by Uptane.
Additionally, the standard says
The payload differs depending on the role. However, the payload for all
roles shares a common structure. It SHALL contain the following four
attributes:
- An indicator of the type of role (Root, Targets, Snapshot, or
Timestamp)
- An expiration date and time
- An integer version number, which *SHOULD* be incremented each time
the metadata file is updated
- The role-specific metadata for the role indicated
The SHOULD recommends having an incrementing version number, but doesn't
deem it necessary. As pointed out by the report, this has the potential for
a specific kind of *rollback attack*. If a malicious actor replays an
older Targets metadata file but this file doesn't have a lower version
number then the version number check will pass. This is because Section
5.4.4.4
<https://uptane.org/docs/2.1.0/standard/uptane-standard#5444-how-to-check-timestamp-metadata>
advises
Check that the version number of the previous Timestamp metadata file, if
any, is *less than or equal* to the version number of this Timestamp
metadata file.
*Potential mitigations*
This can potentially be fixed by tightening the requirements around the
metadata version numbers:
- An integer version number, which SHOULD SHALL be incremented each
time the metadata file is updated
- Check that the version number of the previous Timestamp metadata
file, if any, is less than or equal to the version number of this
Timestamp metadata file.
Please provide your thoughts on this below.
—
Reply to this email directly, view it on GitHub
<#268>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGRODZNPLJVU3G62A2OYOLZ7D6HBAVCNFSM6AAAAABRHCCQ6SVHI2DSMVQWIX3LMV43ASLTON2WKOZSGYZTMMBWGY3DGMY>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
I'll also note that this is a good reminder that we need to make this more
visible on the site. We discussed this at length when doing the system
design and of course after the U Iowa report. But apparently this is too
hard to find. (See paragraph 3 of this for more on our thinking:
https://uptane.org/docs/latest/deployment/best-practices#511-receiving-updates-from-tier-1-suppliers
)
…On Tue, Nov 5, 2024 at 8:07 PM Justin Cappos ***@***.***> wrote:
Right, so there is also a need in many Uptane installations to be able to
do a rollback to a limited number of versions prior. There are several
ways this can work. One way is for the image repository to only contain
copies of metadata for the versions which should be valid in this way. As
such, the proposed change here would break this workflow...
On Tue, Nov 5, 2024 at 12:31 PM Yasho Bapat ***@***.***>
wrote:
> This vulnerability was highlighted in the University of Iowa report
> <https://dl.acm.org/doi/10.1145/3678890.3678927> on Uptane's
> vulnerabilities.
>
> *Description*
> The idea of repositories using monotonically increasing version numbers
> is optional according to the Uptane Standard. However, disabling this
> feature will result in a degradation of the security advantages offered by
> Uptane. Additionally, the standard says
>
> The payload differs depending on the role. However, the payload for all
> roles shares a common structure. It SHALL contain the following four
> attributes:
>
> - An indicator of the type of role (Root, Targets, Snapshot, or
> Timestamp)
> - An expiration date and time
> - An integer version number, which *SHOULD* be incremented each time
> the metadata file is updated
> - The role-specific metadata for the role indicated
>
> The SHOULD recommends having an incrementing version number, but doesn't
> deem it necessary. As pointed out by the report, this has the potential for
> a specific kind of *rollback attack*. If a malicious actor replays an
> older Targets metadata file but this file doesn't have a lower version
> number then the version number check will pass. This is because Section
> 5.4.4.4
> <https://uptane.org/docs/2.1.0/standard/uptane-standard#5444-how-to-check-timestamp-metadata>
> advises
>
> Check that the version number of the previous Timestamp metadata file, if
> any, is *less than or equal* to the version number of this Timestamp
> metadata file.
>
> *Potential mitigations*
> This can potentially be fixed by tightening the requirements around the
> metadata version numbers:
>
> - An integer version number, which SHOULD SHALL be incremented each
> time the metadata file is updated
> - Check that the version number of the previous Timestamp metadata
> file, if any, is less than or equal to the version number of this
> Timestamp metadata file.
>
> Please provide your thoughts on this below.
>
> —
> Reply to this email directly, view it on GitHub
> <#268>, or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAGRODZNPLJVU3G62A2OYOLZ7D6HBAVCNFSM6AAAAABRHCCQ6SVHI2DSMVQWIX3LMV43ASLTON2WKOZSGYZTMMBWGY3DGMY>
> .
> You are receiving this because you are subscribed to this thread.Message
> ID: ***@***.***>
>
|
|
Hi Justin,
In ISO 24089 Road Vehicles: Software Update the return to an earlier
version can *only* occur as part of the *fallback* (not rollback) from a
failed two phase commit *during* the current software update operation. In
the rare case that an earlier version is made available (e.g. due to an
unpatched critical vulnerability in a new feature), that older version must
be copied into a new instance (with proper higher version number) in the
Image Repository and include a limited use warning.
This is the same behavior that I encountered already in place in legacy
software update systems at three different OEMs over the last decade. Their
rationale was that update operators should not have the privilege to
initiate a true rollback. Instead, the independent QA department had to
first determine the need and then make the change in the Image Repository.
BTW, strict conformance with ISO 24089 is now mandatory for compliance
certification for UNECE R156 Software Update.
Cheers,
- Ira
…On Tue, Nov 5, 2024, 8:07 PM Justin Cappos ***@***.***> wrote:
Right, so there is also a need in many Uptane installations to be able to
<br> do a rollback to a limited number of versions prior. There are several
<br> ways this can work. One way is for the image repository to only
contain <br> copies of metadata for the versions which should be valid in
this way. As <br> such, the proposed change here would break this
workflow... <br> <br> On Tue, Nov 5, 2024 at 12:31 PM Yasho Bapat
***@***.***> <br> wrote: <br> <br> > This vulnerability was
highlighted in the University of Iowa report <br> > <
https://dl.acm.org/doi/10.1145/3678890.3678927> on Uptane's <br>
> vulnerabilities. <br> > <br> > *Description* <br> > The idea
of repositories using monotonically increasing version numbers is <br> >
optional according to the Uptane Standard. However, disabling this feature
<br> > will result in a degradation of the security advantages offered
by Uptane. <br> > Additionally, the standard says <br> > <br> >
The payload differs depending on the role. However, the payload for all
<br> > roles shares a common structure. It SHALL contain the following
four <br> > attributes: <br> > <br> > - An indicator of the type
of role (Root, Targets, Snapshot, or <br> > Timestamp) <br> > - An
expiration date and time <br> > - An integer version number, which
*SHOULD* be incremented each time <br> > the metadata file is updated
<br> > - The role-specific metadata for the role indicated <br> >
<br> > The SHOULD recommends having an incrementing version number, but
doesn't <br> > deem it necessary. As pointed out by the report, this
has the potential for <br> > a specific kind of *rollback attack*. If a
malicious actor replays an <br> > older Targets metadata file but this
file doesn't have a lower version <br> > number then the version
number check will pass. This is because Section <br> > 5.4.4.4 <br> >
<
https://uptane.org/docs/2.1.0/standard/uptane-standard#5444-how-to-check-timestamp-metadata>
<br> > advises <br> > <br> > Check that the version number of the
previous Timestamp metadata file, if <br> > any, is *less than or equal*
to the version number of this Timestamp <br> > metadata file. <br> >
<br> > *Potential mitigations* <br> > This can potentially be fixed
by tightening the requirements around the <br> > metadata version
numbers: <br> > <br> > - An integer version number, which SHOULD
SHALL be incremented each <br> > time the metadata file is updated <br>
> - Check that the version number of the previous Timestamp metadata
<br> > file, if any, is less than or equal to the version number of this
<br> > Timestamp metadata file. <br> > <br> > Please provide your
thoughts on this below. <br> > <br> > — <br> > Reply to this email
directly, view it on GitHub <br> > <
#268>, or unsubscribe
<br> > <
https://github.com/notifications/unsubscribe-auth/AAGRODZNPLJVU3G62A2OYOLZ7D6HBAVCNFSM6AAAAABRHCCQ6SVHI2DSMVQWIX3LMV43ASLTON2WKOZSGYZTMMBWGY3DGMY>
<br> > . <br> > You are receiving this because you are subscribed to
this thread.Message <br> > ID: ***@***.***> <br> > <br>
—
Reply to this email directly, view it on GitHub
<#268 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AE33UO2FHDTEFW67GYWCRQLZ7FTW7AVCNFSM6AAAAABRHCCQ6SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJYGUYDCOBUHA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
We discussed this in the Standards committee call last week, but I'm also writing it here for posterity. There's no breakage of the workflow described, as the version numbers in question here are the version numbers of the metadata files, not the version numbers of the individual targets. Indeed, it should be emphasized that version numbers (or version strings) are not a property that individual targets necessarily have. In 5.2.3.1 Metadata about images, the only required properties for a target to have are filename, size, and hash. It's certainly quite common for a version field to be included in custom metadata, and for filenames to follow a naming scheme that includes a version string of some sort, but it is explicitly not a requirement. |
|
The broader question about requiring increasing version numbers requires some additional context, I believe. One thing that we need to take into account in Uptane is the realities of the hardware we're expecting to deal with. One of those realities is that flash memory will eventually fail after a certain number of writes, so we need to be judicious with how frequently our update procedures require any data to be written to persistent storage. See this thread from 2019 for more discussion, but the most pertinent conclusion is that writing data once per update check is always unacceptable. That being said, I believe that the only way to fully rectify this vulnerability is to require that Targets, Snapshot, and Timestamp metadata version numbers always be incremented when the contents of any Targets metadata file changes. We could arguably loosen this requirement a little bit, and say that you don't have to increment the version number if the only change is that you've bumped the expiry date of the file. I do think that the description of the vulnerability as only requiring an external MitM is a little shaky, though; it depends on the idea that an external MitM allows you to permanently freeze time, which I'm not entirely convinced about. I'll leave the discussion of that question to the other issue, however. Let's discuss further next meeting. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This vulnerability was highlighted in the University of Iowa report on Uptane's vulnerabilities.
Description
The idea of repositories using monotonically increasing version numbers is optional according to the Uptane Standard. However, disabling this feature will result in a degradation of the security advantages offered by Uptane. Additionally, the standard says
The SHOULD recommends having an incrementing version number, but doesn't deem it necessary. As pointed out by the report, this has the potential for a specific kind of rollback attack. If a malicious actor replays an older Targets metadata file but this file doesn't have a lower version number then the version number check will pass. This is because Section 5.4.4.4 advises
Potential mitigations
This can potentially be fixed by tightening the requirements around the metadata version numbers:
SHOULDSHALL be incremented each time the metadata file is updatedor equal tothe version number of this Timestamp metadata file.Please provide your thoughts on this below.
The text was updated successfully, but these errors were encountered: