358
Root access vulnerability in glibc library impacts many Linux distros
(securityaffairs.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 31 Jan 2024
358 points (98.6% liked)
Linux
46611 readers
856 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
Security-critical C and memory safety bugs. Name a more iconic duo...
I'd have kinda preferred for public disclosure to have happened after the fix propagated to distros. Now we get to hurry the patch to end-users which isn't always easily possible. Could we at least have a coordinated disclosure time each month? That'd be great.
Public disclosure is typically done 90 days after Deva are privately notified. That should be enough time for security-critical bugs.
They did follow that. You can read their disclosure timeline in their report.
Problem is that the devs of glibc aren't the only people interested in getting glibc patched but us distro maintainers too.
What I would have preferred would be an early private disclosure to the upstream maintainers and then a public but intentionally unspecific disclosure with just the severity to give us distro people some time to prepare a swift rollout when the full disclosure happens and the patch becomes public.
Alternatively, what would be even better would have been to actually ship the patch in a release but not disclose its severity (or even try to hide it by making it seem like a refactor or non-security relevant bugfix) until a week or two later; ensuring that any half-decent distro release process and user upgrade cycle will have the patch before its severity is disclosed. That's how the Linux kernel does it AFAIK and it's the most reasonable approach I've seen.
I'm afraid I don't understand what you're trying to say.
I am not sure as well, but maybe they meant "maybe an early and public disclosure increases the urgency of the fix for the developers"?
There have been cases [1] where vulnerabilities in software have been found, and the researcher that found it will contact the relevant party and nothing comes of it.
What they're suggesting is that the researcher who discovered this might have already disclosed this in private, but felt that it wasn't being patched fast enough, so they went public.
The solution here generally afaik is to give a specific deadline before you go public. It forces the other party to either patch it, or see the problem happen when they go live. 90 days is the standard timeframe for that since it's enough time to patch and rollout, but still puts pressure on making it happen.