ariadne
/
ariadne.space
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

blog: vulnerability lifecycle: fix code blocks
ci/woodpecker/push/woodpecker Pipeline was successful Details

main
Ariadne Conill 2022-08-19 09:20:50 -05:00
parent 9be77ba0c0
commit a1714536bf
1 changed files with 39 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

62
content/blog/the-vulnerability-remediation-lifecycle-of-alpine-containers.md
View File

@ -61,17 +61,19 @@ Where do security scanners get their data?  In most cases for Alpine systems, t
In the case of `libgrss`, we know that `0.7.0-r1` and newer have a fix for CVE-2016-20011, but the security fix has already been published.  So, where can we get `0.7.0-r0`?  We can get it from Alpine 3.12 of course.  Accordingly, we make a filesystem with `apk` and install Alpine 3.12 into it:
```
nanabozho:~# apk add --root ~/test-image --initdb --allow-untrusted -X http://dl-cdn.alpinelinux.org/v3.12/main -X http://dl-cdn.alpinelinux.org/v3.12/community alpine-base libgrss-dev=0.7.0-r0
\[...\]
[...]
OK: 126 MiB in 92 packages
nanabozho:~# apk upgrade --root ~/test-image -X http://dl-cdn.alpinelinux.org/v3.13/main -X http://dl-cdn.alpinelinux.org/v3.13/community
\[...\]
[...]
OK: 127 MiB in 98 packages
nanabozho:~# apk info --root ~/test-image libgrss
Installed: Available:
libgrss-0.7.0-r0 ?
nanabozho:~# cat ~/test-image/etc/alpine-release
3.13.5
```
Now that we have our image, lets see what detects the vulnerability, and what doesn't.
@ -83,38 +85,43 @@ I have installed `trivy` to `/usr/local/bin/trivy` on my machine by downloading
To scan a filesystem image with trivy, you do `trivy fs /path/to/filesystem`:
```
nanabozho:~# trivy fs -f json ~/test-image/
2021-06-07T23:48:40.308-0600 INFO Detected OS: alpine
2021-06-07T23:48:40.308-0600 INFO Detecting Alpine vulnerabilities...
2021-06-07T23:48:40.309-0600 INFO Number of PL dependency files: 0
\[
[
{
"Target": "localhost (alpine 3.13.5)",
"Type": "alpine"
}
\]
]
```
Hmm, that's strange.  I wonder why?
```
nanabozho:~# trivy --debug fs ~/test-image/
2021-06-07T23:42:54.036-0600 DEBUG Severities: UNKNOWN,LOW,MEDIUM,HIGH,CRITICAL
2021-06-07T23:42:54.038-0600 DEBUG cache dir: /root/.cache/trivy
2021-06-07T23:42:54.039-0600 DEBUG DB update was skipped because DB is the latest
2021-06-07T23:42:54.039-0600 DEBUG DB Schema: 1, Type: 1, UpdatedAt: 2021-06-08 00:19:21.979880152 +0000 UTC, NextUpdate: **2021-06-08 12:19:21.979879952 +0000 UTC**, DownloadedAt: 2021-06-08 05:23:09.354950757 +0000 UTC
```
Ah, trivy's security database only updates twice per day, so trivy has not become aware of CVE-2016-20011 being mitigated by `libgrss-0.7.0-r1` yet.
I rebuilt trivy's database locally and put it in `~/.cache/trivy/db/trivy.db`:
```
nanabozho:~# trivy fs -f json ~/test-image/
2021-06-08T01:37:20.574-0600 INFO Detected OS: alpine
2021-06-08T01:37:20.574-0600 INFO Detecting Alpine vulnerabilities...
2021-06-08T01:37:20.576-0600 INFO Number of PL dependency files: 0
\[
[
{
"Target": "localhost (alpine 3.13.5)",
"Type": "alpine",
"Vulnerabilities": \[
"Vulnerabilities": [
{
"VulnerabilityID": "CVE-2016-20011",
"PkgName": "libgrss",
@ -127,9 +134,9 @@ nanabozho:~# trivy fs -f json ~/test-image/
"PrimaryURL": "https://avd.aquasec.com/nvd/cve-2016-20011",
"Description": "libgrss through 0.7.0 fails to perform TLS certificate verification when downloading feeds, allowing remote attackers to manipulate the contents of feeds without detection. This occurs because of the default behavior of SoupSessionSync.",
"Severity": "HIGH",
"CweIDs": \[
"CweIDs": [
"CWE-295"
\],
],
"CVSS": {
"nvd": {
"V2Vector": "AV:N/AC:L/Au:N/C:N/I:P/A:N",
@ -138,10 +145,10 @@ nanabozho:~# trivy fs -f json ~/test-image/
"V3Score": 7.5
}
},
"References": \[
"References": [
"https://bugzilla.gnome.org/show\_bug.cgi?id=772647",
"https://gitlab.gnome.org/GNOME/libgrss/-/issues/4"
\],
],
"PublishedDate": "2021-05-25T21:15:00Z",
"LastModifiedDate": "2021-06-01T17:03:00Z"
},
@ -157,9 +164,9 @@ nanabozho:~# trivy fs -f json ~/test-image/
"PrimaryURL": "https://avd.aquasec.com/nvd/cve-2016-20011",
"Description": "libgrss through 0.7.0 fails to perform TLS certificate verification when downloading feeds, allowing remote attackers to manipulate the contents of feeds without detection. This occurs because of the default behavior of SoupSessionSync.",
"Severity": "HIGH",
"CweIDs": \[
"CweIDs": [
"CWE-295"
\],
],
"CVSS": {
"nvd": {
"V2Vector": "AV:N/AC:L/Au:N/C:N/I:P/A:N",
@ -168,16 +175,17 @@ nanabozho:~# trivy fs -f json ~/test-image/
"V3Score": 7.5
}
},
"References": \[
"References": [
"https://bugzilla.gnome.org/show\_bug.cgi?id=772647",
"https://gitlab.gnome.org/GNOME/libgrss/-/issues/4"
\],
],
"PublishedDate": "2021-05-25T21:15:00Z",
"LastModifiedDate": "2021-06-01T17:03:00Z"
}
\]
]
}
\]
]
```
Ah, that's better.
@ -185,16 +193,20 @@ Ah, that's better.
[Clair](https://github.com/quay/clair) is a security scanner previously written by the CoreOS team, and now maintained by Red Hat.  It is considered the gold standard for security scanning of containers.  How does it do with the filesystem we baked?
```
nanabozho:~# clairctl report ~/test-image/
2021-06-08T00:11:04-06:00 ERR error="UNAUTHORIZED: authentication required; \[map\[Action:pull Class: Name:root/test-image Type:repository\]\]"
```
Oh, right, it can't just scan a filesystem.  One second.
```
nanabozho:~$ cd ~/dev-src/clair
nanabozho:~$ make local-dev-up-with-quay
\[a bunch of commands later\]
[a bunch of commands later]
nanabozho:~$ clairctl report test-image:1
test-image:1 found libgrss 0.7.0-r0 CVE-2016-20011 (fixed: 0.7.0-r1)
```
As you can see, clair does succeed in finding the vulnerability, when you bake an actual Docker image and publish it to a local quay instance running on localhost.
@ -204,25 +216,29 @@ But this is really a lot of work to just scan for vulnerabilities, so I wouldn't
[grype](https://github.com/anchore/grype) is a security scanner made by Anchore.  They talk a lot about how Anchore's products can also be used to build a Software Bill of Materials for a given image.  Let's see how it goes with our test image:
```
nanabozho:~# grype dir:~/test-image/
✔ Vulnerability DB \[updated\]
✔ Cataloged packages \[98 packages\]
✔ Scanned image \[3 vulnerabilities\]
✔ Vulnerability DB [updated]
✔ Cataloged packages [98 packages]
✔ Scanned image [3 vulnerabilities]
NAME INSTALLED FIXED-IN VULNERABILITY SEVERITY
libgrss 0.7.0-r0 (fixes indeterminate) CVE-2016-20011 High
libxml2 2.9.10-r7 (fixes indeterminate) CVE-2019-19956 High
openrc 0.42.1-r19 (fixes indeterminate) CVE-2018-21269 Medium
```
grype does detect that a vulnerable `libgrss` is installed, but the `(fixes indeterminate)` seems fishy to me.  There also appear to be some other hits that the other scanners didn't notice.  Lets fact check this against a pure Alpine 3.13 container:
```
nanabozho:~# grype dir:~/test-image-pure/
✔ Vulnerability DB \[no update available\]
✔ Cataloged packages \[98 packages\]
✔ Scanned image \[3 vulnerabilities\]
✔ Vulnerability DB [no update available]
✔ Cataloged packages [98 packages]
✔ Scanned image [3 vulnerabilities]
NAME INSTALLED FIXED-IN VULNERABILITY SEVERITY
libgrss 0.7.0-r1 (fixes indeterminate) CVE-2016-20011 High
libxml2 2.9.10-r7 (fixes indeterminate) CVE-2019-19956 High
openrc 0.42.1-r19 (fixes indeterminate) CVE-2018-21269 Medium
```
Oh no, it detects `0.7.0-r1` as vulnerable too, which I assume is simply because Anchore's database hasn't updated yet.  Researching the other two vulnerabilities, the `openrc` one seems to be a vulnerability we missed, while the `libxml2` one is a false positive.