Open oaljoundi opened 3 months ago
jperrin
commented
2 months ago 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
commented
2 months ago 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 <mingheren@microsoft.com> - 2.35-6
- Add patches for CVE-2023-4806 and CVE-2023-5156Looking 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.
I'll share to our security dev the information about your glibc advisory publishing. Thanks !
codonell
commented
2 months ago @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
commented
2 months ago @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
commented
2 months ago @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.
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 https://github.com/microsoft/azurelinux/blob/59ce246f224f282b3e199d9a2dacaa8011b75a06/SPECS/glibc/glibc.spec#L326 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?