[Azure Linux 3.0] Produce a FIPS compliant, FedRAMP approved image

[oaljoundi]

No description provided.

[codonell]

Just out of curiosity, as an upstream glibc developer, glibc security team member, and glibc CNA member... what is your plan to address CVEs under the SLA required for FedRAMP? For example

azurelinux/SPECS/glibc/glibc.spec

Line 326 in 59ce246

- Add patches for CVE-2023-4806 and CVE-2023-5156

is currently 8 CVEs behind for glibc.

This is an interesting feature... but it has a lot of process requirements. Upstream we're working on publishing our advisories so they can be consumed e.g. https://sourceware.org/cgit/glibc/tree/advisories/GLIBC-SA-2024-0004?id=91695ee4598b39d181ab8df579b888a8863c4cab is this useful to you?

[jperrin]

Carlos! it's been a while!

That actually looks like it could be quite useful, but it's also going to cause a tiny rant because with the NIST/NVD drama, the kernel being its own CNA, this, etc I feel like the industry is moving backwards a bit to individual silos and a little too much decentralization.

@eric-desrochers this might be something for us to plug into our tooling.

[eric-desrochers]

Upstream we're working on publishing our advisories so they can be consumed e.g. https://sourceware.org/cgit/glibc/tree/advisories/GLIBC-SA-2024-0004?id=91695ee4598b39d181ab8df579b888a8863c4cab is this useful to you?

Nice to virtually meeting you @codonell

The SPEC file you are refering to is from our stable release of Mariner 2.0 that contains glibc v2.35.
Version: 2.35

Your are right our last CVE fixes were for:

%changelog
* Wed Oct 04 2023 Minghe Ren <[email protected]> - 2.35-6
- Add patches for CVE-2023-4806 and CVE-2023-5156

Looking at your advisory: https://sourceware.org/cgit/glibc/tree/advisories/
Look like there was 4 more CVEs after CVE-2023-5156 , but you mention we are 8 CVEs behind ? I'd like to understand what are we potentially missing here that we haven't fixed nor analyzed if any.

• https://sourceware.org/cgit/glibc/tree/advisories/GLIBC-SA-2024-0001
  • CVE-2023-6246
    • [NOT AFFECTED] This issue affects glibc 2.36 and newer.
• https://sourceware.org/cgit/glibc/tree/advisories/GLIBC-SA-2024-0002
  • CVE-2023-6779
    • [NOT AFFECTED] This issue affects glibc 2.37 and newer.
• https://sourceware.org/cgit/glibc/tree/advisories/GLIBC-SA-2024-0003
  • CVE-2023-6780
    • [NOT AFFECTED] This issue affects glibc 2.37 and newer https://nvd.nist.gov/vuln/detail/CVE-2023-6780
• https://sourceware.org/cgit/glibc/tree/advisories/GLIBC-SA-2024-0004
  • CVE-2024-2961
    • [NOT AFFECTED] This affects iconv conversion to the ISO-2022-CN-EXT character set, which we do not provide. A dev concluded that we were not affected by this CVE.

I'll share to our security dev the information about your glibc advisory publishing. Thanks !

[codonell]

@eric-desrochers You aren't missing anything. There are 4 reserved CVEs that are public (not under embargo) for which we're about to publish advisories. You can see them here: CVE-2024-33599, CVE-2024-33600, CVE-2024-33601, CVE-2024-33602 If you don't use nscd anywhere for a local cache then you won't be affected, but it's hard to argue that since scanners look at source-level attribution only.

[codonell]

@eric-desrochers The really pertinent question for me, and the reason I commented on this ticket is to determine if the information is valuable and useful to you. Are you able to consume the git repo advisory data as input to tooling? I would like to avoid needing to describe upstream glibc as an OVALv2 endpoint.

[eric-desrochers]

@codonell thanks for the reserved CVEs sharing.
For the advisory, I have shared the information with our CVE detection tool team.

We'll get back to you when I hear back from them.