Vulnerable dependencies

[lcaoppit]

Hi everyone,

We really liked this lib that has been helping us to automate some tasks.
Nonetheless, we found out some dependencies that contain some vulnerabilities.

Where we found those vulnerabilities:

src/IntegrationTests/AutoMapper.IntegrationTests.csproj
src/UnitTests/AutoMapper.UnitTests.csproj
src/AutoMapper.Extensions.Microsoft.DependencyInjection.Tests/AutoMapper.DI.Tests.csproj

Type of vulnerabilities:

• System.Drawing.Common - Remote Code Execution (RCE)

• Newtonsoft.Json - Insecure Defaults

• System.Net.Http - Denial of Service (DoS)

• System.Net.Http - Improper Certificate Validation

• System.Net.Http - Information Exposure

• System.Net.Http - Privilege Escalation

• System.Net.Http - Authentication Bypass

• System.Text.RegularExpressions - Regular Expression Denial of Service (ReDoS)

Which dependencies are vulnerable and how to fix those:

1. Shouldly@4.0.3
   Can be fixed using:
   System.DirectoryServices.Protocols@5.0.1.1
   System.Security.Cryptography.Xml@4.7.1
   System.Drawing.Common@4.7.2, @5.0.3

2. Microsoft.NET.Test.Sdk@17.1.0
   Can be fixed using:
   Newtonsoft.Json@13.0.1

3. xunit@2.4.1
   Can be fixed using:
   System.Net.Http@4.1.2, @4.3.2

Could the team please check if is possible to change those libs without broken the lib?

Best Regards

P.S.: We've made a fork to test the upgrade, but in our environment we didn't found any issue after that.

[jbogard]

These are unit test projects. They're not published in any way shape or form. Whatever you used to find these "vulnerabilities" seems broken.

Regular expression Denial of Service attack on my unit tests??? How will I sleep at night 🤣

[lcaoppit]

@jbogard ,

I've just kindly advised you about it because some vulnerabilities can leverage the application structure in general to, for example, make a lateral movement and access other components of your application.

As a security engineer, I am only try to help to improve your app (that my team has been using) and make it more secure. That's it, no big deal.

If you don't care about, ok, how I said, I just wanted to help. Don´t need make jokes about it.

[jbogard]

This isn't an application. It's a single library that's shipped in a package.

But yes, I do find the notion of vulnerabilities in unit tests that never ship to be pretty funny. When this comes up on my teams I just have the security engineers exclude test projects from the security scans (and anything else that never ships), it just produces noise.

Now if you found vulnerabilities in my packages, well THAT would be interesting and worth investigating.

[lcaoppit]

Ok, got.

Because since we use your lib within our code/app its introduce a security issue that an attacker can take advantage and make a mess.

Although its is just a test class, its will call some part of your lib or our code to validate a behavior that the result could be a tool to an attacker to know how your lib or our code works and try to use it to attack the application that has been using this lib. Then it's the reason about our concern and try to help to eliminate any breach.

Furthermore, if this ones is not use in main component of the lib, I agree with you, do not have any problem to take care.

[jbogard]

I guess I'm super confused. Your team is referencing the AutoMapper package that includes a single library, AutoMapper.dll. That doesn't reference any of the libraries with the "vulnerabilities". Instead someone would have to reference the test libraries, which aren't published anywhere.

Which means your team would have to download or clone the AutoMapper code, then build all of the solutions, THEN reference the test assemblies along with the core AutoMapper assembly and THEN they

At that point, it would be up to your team to add the correct explicit references. None of my application code references or uses any of the libraries mentioned. They're all transitive dependencies, and I don't (nor does any other library author I know of) update transitive dependencies because of security vulnerabilities.

If there are security vulnerabilities with DIRECT dependencies, which are:

• Microsoft.CSharp (4.7.0)
• Microsoft.Extensions.Options (6.0.0)
  Then I would work quickly to update them.

If that was an immediate issue for your team, the fix is easy for your team - have them reference the updated package (say version 6.0.1). Direct package references "win" over transitive package references during a build, so I'm not technically required to update a dependency for any consumer to be able to adopt a fix.

All of this is why I only let my security teams scan published application artifacts. Anything beyond that is false positives and noise.