isra-fel
commented
10 months ago Thanks for reporting! cc @msJinLei @vidai-msft
Closed jorisscheppers closed 7 months ago
isra-fel
commented
10 months ago Thanks for reporting! cc @msJinLei @vidai-msft
msJinLei
commented
10 months ago Az.Accounts actually depends on System.Text.Encodings.Web 4.7.2. But we incorrectly add old version https://github.com/Azure/azure-powershell/blob/main/src/lib/netfx/System.Text.Encodings.Web.dll to our preload dependency list . Will update it to 4.7.2 in the next release.
jorisscheppers
commented
10 months ago @msJinLei would you be able to take a look at the dependency on System.Net.Http as well? Our security scanner indicates that there is another vulnerability in this image but I'm not able to perform the same analysis as with System.Text.Encodings.Web.
This is the CVE that we are warned about: https://github.com/advisories/GHSA-7jgj-8wvc-jh57.
isra-fel
commented
9 months ago @jorisscheppers we don't rely on nor ship System.Net.Http. Where did your security scanner find that?
BTW we double checked that the version of System.Text.Encodings.Web we reference is 4.7.2. It is secure.
jorisscheppers
commented
9 months ago @jorisscheppers we don't rely on nor ship
System.Net.Http. Where did your security scanner find that? BTW we double checked that the version of System.Text.Encodings.Web we reference is 4.7.2. It is secure.
And yet our security scanner (which is included in Microsoft Defender for Azure and uses the Qualys container image scanner tech) keeps indicating that image contains the System.Text.Encodings.Web version that has this vulnerability. I'm not sure how the scanner concludes that a vulnerable version of that dll is present on the image. I imagine that it either checks a manifest file or it uses exif information to determine version numbers. Would it help if I extracted the actual dll from the image for reference?
Regarding System.Net.Http: it might be a dependency created by another step in the image build process. I will check this out.
isra-fel
commented
9 months ago Microsoft Defender for Azure and uses the Qualys container image scanner tech
@msJinLei could you try that out?
Would it help if I extracted the actual dll from the image for reference?
@jorisscheppers thanks but that won't be necessary. I ran ExifTool and got the same results as yours. It is indeed 4.7.2. And we have been using 4.7.2 since at least last December, see https://github.com/Azure/azure-powershell/blob/main/src/lib/netfx/System.Text.Encodings.Web.dll
isra-fel
commented
7 months ago In summary, the version of System.Text.Encodings.Web we ship is absolutely secure. We'll track the issue that Defender detected the CVE internally. Thanks.
Description
For some time now, our container registry vulnerability scanning tool has been flagging one of our pipeline images for a severe CVE (: CVE-2021-26701). The team has flagged this as a false-positive (mainly because of https://github.com/Azure/azure-powershell/issues/21911), but since I have been digging a little deeper I have found that an affected version of the System.Text.Encodings.Web dll is actually being added to the container image, even though we are building a new image with the latest versions of both Powershell and the Az module every week.
Dockerfile for the pipeline-base image: (the CVE is not in this image, but I added it for reference)
Dockerfile for the powershell image (the resulting image which contains the actual CVE):
Searching for the reported dll on the container filesystem gives:
Exiftool output (affected dll):
And for reference, Exiftool output (non-affected dll)
Issue script & Debug output
Environment data
Module versions
Error output
No response