Docker Community Forums

Share and learn in the Docker community.

Is the Docker DTR Image Scanning RHEL-aware?


(Anthony Alcamo) #1

Docker Trusted Registry 2.2.3

Docker Version:
Client:
Version: 17.03.1-ee-3
API version: 1.27
Go version: go1.7.5
Git commit: 3fcee33
Built: Thu Mar 30 20:03:25 2017
OS/Arch: linux/amd64

Server:
Version: 17.03.1-ee-3
API version: 1.27 (minimum version 1.12)
Go version: go1.7.5
Git commit: 3fcee33
Built: Thu Mar 30 20:03:25 2017
OS/Arch: linux/amd64
Experimental: false


When I pull down the latest base version of Docker 7.3, tag it and push it to my local DTR and perform an image scan, I get 80 critical errors, 125 major errors, etc. I’m wondering if the scan recognizes all the patches put out by RedHat because as I drill down into the vulnerabilities (bash 4.2.46 has 7 criticals for example), and click on the first vulnerability (CVE-2014-7186), I can see that a patch by RedHat has already been released back in 2014. I perform a RUN yum -y update within my Dockerfile.

• REDHAT:RHSA-2014:1311
• URL:http://rhn.redhat.com/errata/RHSA-2014-1311.html
• REDHAT:RHSA-2014:1312
• URL:http://rhn.redhat.com/errata/RHSA-2014-1312.html
• REDHAT:RHSA-2014:1354
• URL:http://rhn.redhat.com/errata/RHSA-2014-1354.html

Thanks,
Anthony


(Patrick Devine) #2

Hi Anthony,

It’s definitely a problem, and we’re actively working on cleaning up the false positives. I’ll try and keep people aware on the progress here in the forums.

Thanks,
–Patrick.


(Anthony Alcamo) #3

OK thank you for getting back to me Patrick!


(Patrick Devine) #4

Hey Anthony,

A quick update post-dockercon. We’ve been sorting through the RedHat OVAL repository and trying to pin down where the false positives are coming from. It seems like a number of them are because we’re misidentifying certain package versions, so we’re working to shore that up.

More to come soon…

–Patrick.


(Anthony Alcamo) #5

Great news Patrick and thank you for following up!!


(Anthony Alcamo) #6

Patrick,
Would you happen to yet have an ETA on this one?
Thanks,
Anthony


(Patrick Devine) #7

Hey Anthony,

We’re actively working on it. Unfortunately it looks like we’ll have to release a patch to get it working correctly instead of just sending out a new database. I’ll have more details soon.


(Anthony Alcamo) #8

Just checking in Patrick - wondering if this will be in a patch prior to the 17.06 release.
Thank you!


(Patrick Devine) #9

Hey Anthony,

I realize I sound like a broken record, but I’ll have details soon. The team has been working hard to get it working properly.


(Patrick Devine) #10

Hey Anthony,

So finally a bit of news. The 17.06 release (DTR 2.3) has already been fixed to cut down the RHEL false positives significantly, so if you’re part of the upcoming beta program you’ll be able to test that out really soon. We’re still working on getting an update out for 17.03 (DTR 2.2), but it shouldn’t (in theory) require having to patch. Behind the scenes we changed the vulnerability db format for 2.3 and now we’re just trying to get things back into shape for 2.2. I should be able to get a more concrete date for 2.2 soon.


(Anthony Alcamo) #11

Fantastic! I’ll be looking for the 17.06 release or 17.03 update.
Thanks for keeping us in the loop Patrick.

Anthony


(Jamie Thompson) #12

Just to chime in, I just deployed the 2.2.6 release and there are still a significant amount of vulnerabilities found within RHEL based containers. I grabbed the very latest rhel7 image that Red Hat lists no known vulnerabilities against it, and the security scanner in DTR found 19 critical, 44 major, 17 minor…


(Patrick Devine) #13

Hey Jamie,

The 2.2.6 release should address a lot of the false positives that were showing up, however, Red Hat has a large list of unacknowledged CVEs. We need Red Hat to acknowledge them before we stop highlighting them as issues.
There is another set of vulnerabilities which they have acknowledged as “won’t fix”, which we’ve been trying to determine whether those are actually problems. Finally, there are a class of vulnerabilities where we have found a library which has been statically linked into another binary, and it’s sometimes unclear what the version of that library actually is. For those we’re looking at presenting better UI in DTR to show that it may, or may not be a vulnerability.

Thanks everyone for hanging in there…


(Ps20renar) #14

Hallo All, unfortunaly ther’e seems to be there are no better solution in february 2018. We had the same huge list of cve issues with dtr 2.4.1 on rhel/centos 7 images? Are there any News on that behavior?

Regards Renar.


(Patrick Devine) #15

Hey Renar,

Can you update your scanning database and rescan your image? We just caught some CVEs which were false positives and released a new database today, and the list should be cut down slightly. You will still see the problem that I mentioned above with CVEs that Red Hat won’t acknowledge or won’t fix, which it’s unclear whether or not those are issues.

In DTR 2.5, there is an option to hide each of the CVEs that they are comfortable with, however that’s left up to the discretion of the DTR admin. I have also been thinking about a future feature that would also allow you to hide any vendor specific unacknowledged/won’t fix issues, but would love to get some feedback on that.


(Rogerbush) #16

Here’s an example. We’re using CentOS 7.

The actual package name is: bash-4.2.46-29.el7_4.x86_64
The DTR reports this as “bash 4.2.46” with 7 critical vulns.

It should report it as “bash 4.2.46-29” with 0 critical vulns.

Why does the DTR only show 4.2.46 versus 4.2.46-29? Is this simply a problem of the database not having all the patch information?


(Patrick Devine) #17

I believe the patch information is in the database, but the hash didn’t match correctly when it found the package. When it does that it will report all of the vulnerabilities for the bash package.