Ok, lets look at them.
CVE-2023-6246:
Quote:
|
A heap-based buffer overflow was found in the __vsyslog_internal function of the glibc library. This function is called by the syslog and vsyslog functions. This issue occurs when the openlog function was not called, or called with the ident argument set to NULL, and the program name (the basename of argv[0]) is bigger than 1024 bytes, resulting in an application crash or local privilege escalation. This issue affects glibc 2.36 and newer.
|
Yeah, I'm not going to worry about that one then. The claim of privilege escalation also seems a stretch as you'd need a program running as a privileged user that has a argv[0] greater than 1024, and I'm not convinced you'd find that in the wild.
CVE-2023-6779:
Quote:
|
An off-by-one heap-based buffer overflow was found in the __vsyslog_internal function of the glibc library. This function is called by the syslog and vsyslog functions. This issue occurs when these functions are called with a message bigger than INT_MAX bytes, leading to an incorrect calculation of the buffer size to store the message, resulting in an application crash. This issue affects glibc 2.37 and newer.
|
So, if someone tried to write a message greater than 2GB to the syslog, it might crash.... Yeah, I'm not going to worry about that one either as any program that would allow you to write that much data to the syslog is already "faulty" IMHO.
CVE-2023-6780:
Quote:
|
An integer overflow was found in the __vsyslog_internal function of the glibc library. This function is called by the syslog and vsyslog functions. This issue occurs when these functions are called with a very long message, leading to an incorrect calculation of the buffer size to store the message, resulting in undefined behavior. This issue affects glibc 2.37 and newer.
|
Basically the same as above. Needs a 2GB syslog message to trigger it.
The final one is a qsort issue, however:
Quote:
|
The glibc security team clarified that the vulnerability arises from applications using non-transitive comparison functions, which are not compliant with POSIX and ISO C standards.
|
So, you have to have written non-compliant code in the first place.
They've found some bugs; that's great; thank you. newer versions of glibc will be better for it.
However, lets not have all "the sky is falling" security hysteria. sysadmin time is too precious to spend chasing down these nothing-burgers.
