[BUG] Dependency vulnerabilities

[matheus-inacio]

APM Agent version

Higher than 1.9.0

Environment

.NET 5 :

Describe the bug

In our company we make use of a tool called DotNetRetire (https://github.com/RetireNet/dotnet-retire) in our CI pipeline.

Since version 1.9.0 of the Elastic.Apm.NetCoreAll we have not been able to upgrade the dependency packges because of the following security issues:

PS.: I have sended an email about this to [email protected] a while back, but got no response. 😞

fail: RetireNet.Packages.Tool.Services.RetireLogger[0]
111      Found use of 3 vulnerable libs in 5 dependency paths.
112     
113      * Microsoft Security Advisory CVE-2018-8416: .NET Core Tampering Vulnerability in System.IO.Compression.ZipFile/4.0.1
114      https://github.com/dotnet/announcements/issues/95
115     
116          Elastic.Apm.NetCoreAll/1.11.0
117          ╚ Elastic.Apm.MongoDb/1.11.0
118           ╚ MongoDB.Driver.Core/2.4.4
119            ╚ MongoDB.Bson/2.4.4
120             ╚ NETStandard.Library/1.6.0
121              ╚ System.IO.Compression.ZipFile/4.0.1
122     
123          Elastic.Apm.NetCoreAll/1.11.0
124          ╚ Elastic.Apm.MongoDb/1.11.0
125           ╚ MongoDB.Driver.Core/2.4.4
126            ╚ NETStandard.Library/1.6.0
127             ╚ System.IO.Compression.ZipFile/4.0.1
128     
129      * Microsoft Security Advisory CVE-2018-8292: .NET Core Information Disclosure Vulnerability in System.Net.Http/4.1.0
130      https://github.com/dotnet/announcements/issues/88
131     
132          Elastic.Apm.NetCoreAll/1.11.0
133          ╚ Elastic.Apm.MongoDb/1.11.0
134           ╚ MongoDB.Driver.Core/2.4.4
135            ╚ MongoDB.Bson/2.4.4
136             ╚ NETStandard.Library/1.6.0
137              ╚ System.Net.Http/4.1.0
138     
139          Elastic.Apm.NetCoreAll/1.11.0
140          ╚ Elastic.Apm.MongoDb/1.11.0
141           ╚ MongoDB.Driver.Core/2.4.4
142            ╚ NETStandard.Library/1.6.0
143             ╚ System.Net.Http/4.1.0
144     
145      * Microsoft Security Advisory 4021279: Vulnerabilities in .NET Core, ASP.NET Core Could Allow Elevation of Privilege in System.Net.Security/4.0.0
146      https://github.com/dotnet/corefx/issues/19535
147     
148          Elastic.Apm.NetCoreAll/1.11.0
149          ╚ Elastic.Apm.MongoDb/1.11.0
150           ╚ MongoDB.Driver.Core/2.4.4
151            ╚ System.Net.Security/4.0.0

To Reproduce

Runing the C.I. with the use of the DotNetRetire

[gregkalapos]

@matheus-inacio thanks for reporting.

As an immediate workaround: I see it's caused by the MondoDb driver - have you considered referencing the Elastic.Apm package and other packages you need manually, leaving out MondoDb? Or is this not an option? It's not a lot of work - you'll need to manually reference packages and during initialization you'll need to enable what you use, leaving out MondoDb. Some docs on this here.

This above is just a quick idea as a workaround - we'll look int the specific issue as well.

[russcam]

On the surface, it seems like this issue might be better directed to MongoDB, since it is the driver that has the dependency?

[matheus-inacio]

On the surface, it seems like this issue might be better directed to MongoDB, since it is the driver that has the dependency?

It seems that the latest stable version of the MongoDB .net driver is 2.13.1 and the APM project seem to be using version 2.4.4 (that apparently is a 2017 version).

https://github.com/mongodb/mongo-csharp-driver/releases

I think that the dependencies are probably already up-to date in a more recent version of the driver.

[russcam]

Good point @matheus-inacio.

This one's a little awkward with how Elastic.Apm.NetCoreAll is intended to work. Elastic.Apm.NetCoreAll takes dependencies on all other packages that can subscribe diagnostic listeners, which includes Elastic.Apm.MongoDb, and subscribes listeners, so that if an application uses one of the services for which a listener is subscribed, then traces will be captured automatically for them.

If a user is using MongoDb in their application, I think it's reasonable to expect that the package would be kept up to date, and be a newer version than ones which reference a dependency with a reported vulnerability. In this case, binding redirects will allow the integration to simply work with the new version, assuming compatibility (binary, API, etc). If a user is not using MongoDb in their application, then the version with the reported vulnerability will be pulled in, which is undesirable.

I see a few approaches to address:

1. bump the version of MongoDB.Driver.Core to one that does not contain the vulnerability. We would want to keep the version as low as possible to provide the most compatibility for users.
2. provide an agent configuration option to be able to disable certain integrations. This might be generally useful.
3. introduce a Profiler auto instrumentation (Profiler auto instrumentation #1522 ) for MongoDb. This would remove a direct dependency on a specific MongoDb driver version, and would also allow the integration to work with .NET Framework, which it cannot right now because the MongoDb assembly is not strongly named.

These approaches aren't mutually exclusive 🙂 Option 1 looks to me to be the most immediate action we can take to address this.

[russcam]

With dotnet retire deprecated, I thought I'd see what dotnet list package --vulnerable --include-transitive listed for Elastic.Apm.MongoDb:

> dotnet list package --vulnerable --include-transitive

The following sources were used:
   https://api.nuget.org/v3/index.json
   C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\
   https://f.feedz.io/elastic/all/nuget/index.json

The given project `Elastic.Apm.MongoDb` has no vulnerable packages given the current sources.

[gregkalapos]

Short summary:

In the agent we always target the lowest possible version of a given library, but that does not mean that specific version must be loaded at runtime. Typically, user code can depend on a newer version and the agent will be happy with it, it won't force the older version (the specific one the agent depends on) to be loaded.

So I feel these reports are false positive and the solution is to just update the application to a newer version (in this case MongoDb) and then the version with the vulnerability won't get loaded.

At the same time with this approach the agent can target the oldest possible version and maximize the list of supported versions.