x/vulndb: suggestion regarding <GO-2022-0646>

[gantlord]

Report ID

GO-2022-0646

Suggestion/Comment

It seems that this was fixed in 1.34.0?

However I get:

Use of risky cryptographic algorithm in 'github.com/aws/aws-sdk-go'. Current version is vulnerable: 1.48.3. (Trunk)osv-scannerGHSA-7f33-f4f5-xwgw

For the record, I am not using the deprecated interface, or indeed accessing S3 at all, and the version of the sdk I'm using was released yesterday.

I notice that the advisory has it only at the package level and is marked as fixed in 1.34:

https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2022/02/GHSA-7f33-f4f5-xwgw/GHSA-7f33-f4f5-xwgw.json

In the vulndb version (https://github.com/golang/vulndb/blob/master/data/osv/GO-2022-0646.json) I see

  "ecosystem_specific": {
    "imports": [
      {
        "path": "github.com/aws/aws-sdk-go/service/s3/s3crypto",
        "symbols": [
          "NewDecryptionClient",
          "NewEncryptionClient"
        ]
      }
    ]
  }
}

],

I went to the length of looking into my compiled binary and can confirm nothing is using the s3 service and certainly not the NewDecryptionClient or NewEncryptionClient

Either there is something wrong in the metadata for https://github.com/golang/vulndb/blob/master/data/osv/GO-2022-0646.json or osv-scanner isn't limiting itself to the ecosystem_specific

The net outcome is that osv-scanner marks as vulnerable the entirety of github.com/aws/aws-sdk-go (which is still maintained by AWS), and the only way to deal with it seems to be to either stop using osv-scanner or github.com/aws/aws-sdk-go

In my case I can port away from aws-sdk-go to v2 relatively easily, and will do so I can move on, but I don't think this behaviour is desirable - those who are using osv-scanner are presumably also using a linter that would alert them to their use of deprecated functionality - for a <6 score vuln I think it's proportionate to lean on linting for those who are past version 1.34 - otherwise people who can't port away from aws-sdk-go will just stop using osv-scanner

[neild]

I think this is something you need to raise with osv-scanner.

The govulncheck tool performs symbol analysis, which allows it to identify that a program which imports github.com/aws/aws-sdk-go/service/s3/s3crypto but does not use NewDecryptionClient or NewEncryptionClient is not vulnerable. In contrast, osv-scanner doesn't do symbol analysis and can only report that the imported version of the package contains a vulnerability.

There isn't much we can do about this in the vulnerability database; the v1 AWS EncryptionClient is vulnerable by design, and so any code which uses it is affected. v1.34.0 does not, so far as I know, fix the vulnerability.

[gantlord]

I see the reasoning, it does seem that the db should enable the detection of a vulnerability that still exists where it is still being used. it's disappointing that osv-scanner doesn't dig deeper than the top-level package import - aws-sdk is a colossal library and it basically can't be used at all in conjunction with osv-scanner unless I'm missing something.

I support you closing the ticket, I don't think I will try to talk the maintainers of osv-scanner into structural changes. I'll keep an eye on govulncheck as it seems a better design if there are no major drawbacks to it. I've ported to aws sdk v2 in the meantime, so will soldier on with osv-scanner for now since my projects are clean again now.