top 50 comments

sorted by: hot top controversial new old
[–] 158 points 2 years ago (5 children)

For your convenience:

The researchers pointed out that the vulnerability cannot be exploited remotely. An attacker can trigger the issue by providing crafted inputs to applications that employ these [syslog] logging functions [in apps that allow the user to feed crafted data to those functions].

This is a privilege escalation.

  • source
  • hideshow 5 child comments
  • load more comments (3 replies)
    [–] 95 points 2 years ago (11 children)

    "A qsort vulnerability is due to a missing bounds check and can lead to memory corruption. It has been present in all versions of glibc since 1992. "

    This one amazes me. Imagine how many vulnerabilities future researchers will discover in ancient software that persisted/persist for decades.

  • source
  • hideshow 11 child comments
  • [–] 67 points 2 years ago* (7 children)

    That's not the main part of the article, just a footnote, for anyone wondering.

    The flaw resides in the glibc’s syslog function, an attacker can exploit the flaw to gain root access through a privilege escalation.

    The vulnerability was introduced in glibc 2.37 in August 2022.

  • source
  • parent
  • hideshow 7 child comments
  • load more comments (3 replies)
  • [–] 6 points 2 years ago (1 child)

    According to the link in the article, the qsort() bug can only be triggered with a non-transitive cmp() function. Would such a cmp function ever be useful?

  • source
  • parent
  • hideshow 1 child comment
  • [–] 52 points 2 years ago (7 children)

    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.

  • source
  • hideshow 7 child comments
  • [–] 12 points 2 years ago (1 child)

    Public disclosure is typically done 90 days after Deva are privately notified. That should be enough time for security-critical bugs.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 12 points 2 years ago

    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.

  • source
  • parent
  • [–] 31 points 2 years ago (6 children)

    glibc is great, but holy shit the source code is obscured into oblivion, so hard to understand, with hardcoded optimizations, and compiler optimizations. I understand how difficult is to find vulnerabilities. A bit sad that the only C lib truely free software is so hard to actually read its code or even contribute to it.

  • source
  • hideshow 6 child comments
  • [–] 23 points 2 years ago* (last edited 2 years ago) (1 child)

    For what it's worth, glibc is very much performance-critical, so this shouldn't be a surprise. Any possible optimization is worth it.

    There are a ton of free software libc implementations outside of glibc. I think most implementations of libc are free software at this point. There's Bionic, the BSD libcs, musl, the Haiku libc, the OpenSolaris/OpenIndiana libc, Newlib, relibc, the ToaruOS libc, the SerenityOS libc and a bunch more. Pretty sure Wine/ReactOS also have free implementations of the Windows libc.

  • source
  • parent
  • hideshow 1 child comment
  • load more comments (1 reply)
  • [–] 5 points 2 years ago* (3 children)

    Eventually it’ll be easier to create a compatible drop-in replacement than maintain the decades old code, if it isn’t already

  • source
  • parent
  • hideshow 3 child comments
  • load more comments (2 replies)
  • [–] 29 points 2 years ago (3 children)

    Debian (versions 12 and 13), Ubuntu (23.04 and 23.10), and Fedora (37 to 39). Other distributions are probably also impacted.

  • source
  • hideshow 3 child comments
  • [–] 23 points 2 years ago

    Imagine all the vulnerabilities that privative and low reviewed code has...

  • source
  • [–] 18 points 2 years ago (23 children)
  • load more comments (7 replies)
    [–] 16 points 2 years ago (7 children)

    Yikes.

    I'd switch to musl on all of my boxes if it weren't that nearly all precompiled software (closed source, games mainly) are compiled against glibc.

  • source
  • hideshow 7 child comments
  • load more comments (6 replies)
    [–] 16 points 2 years ago (8 children)

    That's why you need to rock and roll

    (Arch btw.)

  • source
  • hideshow 8 child comments
  • [–] 6 points 2 years ago (7 children)

    Try having unattended-upgrades with a rolling distro.

  • source
  • parent
  • hideshow 7 child comments
  • [–] 11 points 2 years ago*

    I replied to another comment with this, but Debian 12(stable, bookworm) and 13(testing, trixie) are affected by this but 12(stable, bookworm) has a patch out in the security repo.

    If you wanna know wether or not you’re affected,

    apt list libc

    will show your version and the one you want is 2.36-9+deb12u4

    If you don’t have that,

    apt update && apt upgrade

    will straighten you out

    13(testing, trixie) has 2.37, but it’s not fixed yet.

    E: Edited to use apt list instead of apt show.

  • source
  • [–] 10 points 2 years ago (1 child)

    RedHat and related: https://access.redhat.com/security/cve/CVE-2023-6246

    Not affected

    Not affected

    Not affected

    etc.

  • source
  • hideshow 1 child comment
  • load more comments (1 reply)
    [–] 9 points 2 years ago

    Local attacker

    Important detail

    as i said on reddit

  • source
  • load more comments
    view more: next ›