Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vulnerability report (CVE-2021-36159) #193

Open
guidiego opened this issue Jul 30, 2021 · 6 comments
Open

Vulnerability report (CVE-2021-36159) #193

guidiego opened this issue Jul 30, 2021 · 6 comments

Comments

@guidiego
Copy link

Ref: https://snyk.io/test/docker/alpine:3.11.11

Vulnerable module: apk-tools/apk-tools
Introduced through: apk-tools/apk-tools@2.10.6-r0
Fixed in: 2.10.7-r0
@Bhushanb333
Copy link

++ Request to provide some help around the resolution of the same

@realHorst
Copy link

++ Request to provide some help around the resolution of the same

You can always update the packages in question manually as the issue was resolved in the alpine repositories.

Alternatively use RUN apk --no-cache upgrade to update all critical packages.

@MartinFalatic
Copy link

MartinFalatic commented Aug 13, 2021

Likewise in alpine 3.12 - this is a fundamental problem that ought to be resolved at the release level, in the alpine base image (doing a bulk upgrade is an anti-pattern, especially given it's apk itself).

@realHorst
Copy link

Likewise in alpine 3.12 - this is a fundamental problem that ought to be resolved at the release level, in the alpine base image (doing a bulk upgrade is an anti-pattern, especially given it's apk itself).

The CVE is no longer present in the alpine:latest (3.14.1) image and should be used.

Also letting you know that the "anti-pattern" of not upgrading your packages is no longer a recommedation in neither the docker docs nor the OWASP CheatSheet.

@MartinFalatic
Copy link

We await the upcoming release of this critical fix in the other supported lines (particularly 3.12).

And yes, it seems odd to use a package with a critical vulnerability to perform an upgrade of itself. That's not usually the situation when it comes to security updates.

I'll concede the point on upgrades as an anti-pattern, as long as it's guaranteed that apk -U upgrade will only pull in security upgrades and won't introduce instabilities. Can I presume then that a new release of a given branch of Alpine always includes all of the same upgrades one would get themselves via apk -U upgrade at that point in time, and not a select subset of critical fixes only?

If that's not the case, then what is the appropriate command to get only the fixes that will be part of the next given release?

@realHorst
Copy link

Well you get all the updates that are available for your branch. Which with v3.12 would only be apk-tools 2.10.6-r0 -> 2.10.8-r0 (at the time of writing). Which packages are added to which branch is up to the maintainers and i am not fully aware of the alpine ways.

I also don't see a way to differentiate between 'regular' and security updates other than manually. You could pin every package to the version that is needed and then check every new update for importance and re-pin if necessary. This strategy is also valid and what i referred to in my initial comment. But for me personally it seems too much work to update the Dockerfiles with a certain version or upgrade command often, just to avoid having to wait a few days/weeks/months? for the image to catch up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants