Yaml3.0.0 vulnerability via objx v0.5.0

[rohanthewiz]

testify@v1.8.1 includes objx v0.5.0 which includes testify@v1.8.0 which eventually includes yaml.v3@v3.0.0 which has a Denial of Service CWE 400 and a Null Pointer deference CWE 476 vulnerability.

go mod graph (excerpts):

github.com/stretchr/testify@v1.8.1 github.com/stretchr/objx@v0.5.0

github.com/stretchr/objx@v0.5.0 github.com/stretchr/testify@v1.8.0

github.com/stretchr/testify@v1.8.0 github.com/stretchr/objx@v0.4.0

github.com/stretchr/objx@v0.4.0 github.com/stretchr/testify@v1.7.1

github.com/stretchr/testify@v1.7.1 gopkg.in/yaml.v3@v3.0.0-20200313102051-9f266ea9e77c

Perhaps a fix would be to tag the latest objx to say 0.5.1, update testify to point to that version and cut a new tag for testify that everyone can include.

Thanks.

[joaocbarbosa]

I'm wondering if we really can fix this problem without changing the objx library or breaking the circular dependency somehow.
Even if we increase the testify version, pointing to a new objx tag (0.5.1 as example), the dependency tree will be like this:

github.com/stretchr/objx@v0.5.0 github.com/stretchr/testify@v1.8.2

github.com/stretchr/testify@v1.8.1 github.com/stretchr/objx@v0.5.1

github.com/stretchr/objx@v0.5.0 github.com/stretchr/testify@v1.8.1

github.com/stretchr/testify@v1.8.1 github.com/stretchr/objx@v0.5.0

github.com/stretchr/objx@v0.5.0 github.com/stretchr/testify@v1.8.0

github.com/stretchr/testify@v1.8.0 github.com/stretchr/objx@v0.4.0

github.com/stretchr/objx@v0.4.0 github.com/stretchr/testify@v1.7.1

It will be inside this loop until the vulnerable version.

[rohanthewiz]

I am seeing the same issue. Because of the circular dependency, updating one package will still leave a reference to respective dependency, and so we go down the stairs back to the older versions with the vulnerabilities.
We would somehow have to update both at once...

[brackendawson]

The vulnerable gopkg.in/yaml.v3 v3.0.0 is not used:

% go list -m all
github.com/stretchr/testify
github.com/davecgh/go-spew v1.1.1
github.com/pmezard/go-difflib v1.0.0
github.com/stretchr/objx v0.5.0
gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405
gopkg.in/yaml.v3 v3.0.1

go mod graph will still show it because it's still part of the graph used to resolve dependencies, and it will still appear in your go.sum so that Go can guarantee the integrity of that graph, but testify will not cause it to be compiled into your unit test or program binaries.

[mgibson-r7]

You might be able to solve this using an exclude in go.mod. So like in testify 1.8.2, have:

exclude github.com/stretchr/testify 1.8.1

Exact details may vary.

[rohanthewiz]

Thank you @mgibson-r7. This absolutely solved the old dependencies issue!
General note to clear up some of the above: any package's dependencies always forms a tree.
Golang does purely source-level compilation, so I must gather the entire dependency tree before I can build.
Features like exclude are a wonderful way of redirecting old references in an older package to newer versions.
All of our Snyk dependencies are gone, except for one license issue.
Thanks all!

[westy92]

Adding this to my go.mod worked for me:

exclude github.com/stretchr/testify v1.7.1