GNU C Library 2.39 Released With New Tunables, stdbit.h For ISO C2X

[phoronix]

Phoronix: GNU C Library 2.39 Released With New Tunables, stdbit.h For ISO C2X

In addition to this week's release of GNU Binutils 2.42, ending out January is the release of the GNU C Library 2.39. This C library "libc" update comes with several new features, security fixes, and other enhancements...

https://www.phoronix.com/news/GNU-C-Library-glibc-2.39

[qarium]

.

Sophisticles you asked me how you and your cronies did go from a Firefox 119 CVE to the LogoFail UEFI/BIOS hack

Its a user-right escalation vulnerability in glibc to give a task run as user root rights.

well here is the answer its CVE-2023-6246, CVE-2023-6779 and CVE-2023-6780 :

"glibc vulnerability allows root access on Linux In addition, further vulnerabilities were discovered in the Gnu C library. One of them has probably existed for over 30 years. Four vulnerabilities in glibc endanger countless Linux systems. Security researchers at Qualys have discovered several vulnerabilities in the widely used Gnu C library (glibc). One of them, registered as CVE-2023-6246, relates to the __vsyslog_internal() function and allows attackers to gain root access by triggering a heap buffer overflow in the default configuration of several popular Linux distributions. The attack is carried out via the frequently used logging functions syslog() and vsyslog(). According to the researchers' report, this security hole was introduced in version 2.37 of glibc, which was published in August 2022. However, the vulnerable code was later backported to version 2.36 in order to patch another, less serious vulnerability. At least the Linux distributions Debian 12 and 13, Ubuntu 23.04 and 23.10 and Fedora 37 to 39 are proven to be vulnerable. However, CVE-2023-6246 can only be exploited under certain conditions, for example through an unusually long argv[0] or openlog() argument with more than 1,024 bytes. Due to the widespread distribution of the vulnerable library, the effects are still significant. Other, less serious vulnerabilities Less serious are two other buffer overflow vulnerabilities discovered by Qualys (CVE-2023-6779 and CVE-2023-6780), which also relate to glibc's __vsyslog_internal() function. However, according to the researchers, triggering this would be more difficult and effective exploitation would probably be more complex. The researchers published technical details about all three security holes in a separate security note. Patches are probably now available, as a look at the disclosure timeline at the end of the document shows. Advertisement In addition, the Qualys researchers found a memory corruption vulnerability in the glibc sorting function qsort(), which affects all versions of the library released since September 1992, i.e. within the last 32 years - from version 1.04 to the most recent version 2.38. However, for an application to be vulnerable, it must meet certain criteria when calling the qsort() function. The researchers have not yet been able to find any real examples of vulnerable programs. "The glibc security team clarified that the vulnerability arises from applications that use non-transitive comparison functions that are not compliant with the Posix and Iso-C standards," the researchers said. The problem has been fixed by a recently released update - as part of a refactoring of qsort() that was carried out due to an independent discovery."

https://www.golem.de/news/debian-ubuntu-und-mehr-glibc-schwachstelle-ermoeglicht-root-zugriff-unter-linux-2401-181724.amp.html

now you have the complete pathway Firefox 119 CVE ---> glibc CVE ---> LogoFail UEFI/BIOS

[qarium]

How to detect the Trojan the Sophisticles RICO gang installed on phoronix.com forum member Victims computers.

https://www-heise-de.translate.goog/hintergrund/Studiere-deinen-Feind-IoCs-als-Bausteine-einer-effektiven-IT-Verteidigung-9606508.html?seite=3&_x_tr_sl=de&_x_tr_tl=en&_x_tr _hl=de&_x_tr_pto=wapp

https://en.wikipedia.org/wiki/YARA

there are filters to use with YARA who can detect it.

one should inspect the hash number of \EFI\OEM\Logo.jpg with the orginal UEFI/BIOS logo of the main board manufacturer.

if the mainboard does not have the LogoFail bug like Dell computers there are other hacks of UEFI/Secure-boot to like BlackLotus

https://github.com/ldpreload/BlackLotus

[sophisticles]

Michael

I am formally requesting you put a stop to this user's accusations of criminal activity by me.

I request that you ban his account and delete all his posts.

Please let me know if you will be able to handle this matter.

Thank you.

[oleid]

Sophisticles you asked me how you and your cronies did go from a Firefox 119 CVE to the LogoFail UEFI/BIOS hack

What's the story behind this?

[clippy]

What's the story behind this?

quarium claims to be the victim of a cyberattack by sophisticles to backdoor their computer, via a Firefox/glibc/UEFI exploit chain. They claim that the Phoronix forums are being infiltrated in a coordinated effort to harm FOSS. Quarium needs professional help.

[rene]

Isn't it surprising and ironic how this T2 Linux ships that glibc with ia-64 support restored on the same day? https://www.youtube.com/watch?v=xmG8XCqstD8 Duno, maybe they are on to something? ;-)

[sdack]

It is a bit surprising to me how in the year 2024 the GNU C Library still contains bugs such as these:

GLIBC-SA-2023-0002:
getaddrinfo: Stack read overflow in no-aaaa mode (CVE-2023-4527)

GLIBC-SA-2023-0003:
getaddrinfo: Potential use-after-free (CVE-2023-4806)

GLIBC-SA-2023-0004:
tunables: local privilege escalation through buffer overflow
(CVE-2023-4911)

GLIBC-SA-2024-0001:
syslog: Heap buffer overflow in __vsyslog_internal (CVE-2023-6246)

GLIBC-SA-2024-0002:
syslog: Heap buffer overflow in __vsyslog_internal (CVE-2023-6779)

GLIBC-SA-2024-0003:
syslog: Integer overflow in __vsyslog_internal (CVE-2023-6780)

It is one of the most essential libraries on a system and as such has to be checked rigorously before every release against such bugs. Whoever is at the head of the project should resign.

[aviallon]

It is a bit surprising to me how in the year 2024 the GNU C Library still contains bugs such as these:

GLIBC-SA-2023-0002:
getaddrinfo: Stack read overflow in no-aaaa mode (CVE-2023-4527)

GLIBC-SA-2023-0003:
getaddrinfo: Potential use-after-free (CVE-2023-4806)

GLIBC-SA-2023-0004:
tunables: local privilege escalation through buffer overflow
(CVE-2023-4911)

GLIBC-SA-2024-0001:
syslog: Heap buffer overflow in __vsyslog_internal (CVE-2023-6246)

GLIBC-SA-2024-0002:
syslog: Heap buffer overflow in __vsyslog_internal (CVE-2023-6779)

GLIBC-SA-2024-0003:
syslog: Integer overflow in __vsyslog_internal (CVE-2023-6780)

It is one of the most essential libraries on a system and as such has to be checked rigorously before every release against such bugs. Whoever is at the head of the project should resign.

Actually, I think that suid programs should link against a formally verified libc, which could be done with relibc + prustli for instance.
Code that sees that much reuse everywhere really needs formal proof.

[sophisticles]

What's the story behind this?

This goes back to the article Michael published about the 96C/192T Threadripper.

I offered the opinion that AMD's TR's were effectively a scam with regards to most users needs and that a desktop Intel offering was the better choice. I posted a link to an article with benchmarks by Puget Systems that showed an i7 beating the 32C/64T TR and matching the 64C/128T TR.

This user lost his mind and could not handle the benchmark results and accused me of infecting his computer that was running a fresh install of Fedora 39 with a virus that survived one reformat but not a second one.

His claims morphed from there to include that I am a member of Israeli Intelligence targeting him because he is a "dissenter", then it became i had accomplices that had decided to "attack" the FOSS community, then it became we were targeting Phoronix members.

If you go back and read his posts, you will see his claims morphing, the more i gave technical explanations as to why his claims do not stand up to scrutiny they more layers he added until we ended up here.

I hope he or she gets the help they need.