New glibc vulnerability- is mint affected?

[sylvain1_]

New linux glibc flaw lets attackers get root on major distros.

https://www.bleepingcomputer.com/news/s ... r-distros/

Has mint been patched for this vulnerability? If so, how do I check to make sure that my version of glibc is not vulnerable?

According to https://www.qualys.com/2024/01/30/cve-2 ... syslog.txt, this vulnerability had been discovered and an advisory sent to Red Hat as early as 2023-11-07. The glibc developers only sent a final version of their patch on 2024-01-15. Why did it take so long to patch such a serious vulnerability?

And why are they communicating through an insecure communication method like email? There is no indication that they are all emailing with end-to-end PGP encryption, and even if they are, the subject lines would still be unencrypted. People like this are no doubt under surveillance by the NSA / GCHQ, who are very interested in learning and stockpiling and deploying zero-day vulnerabilities (rather than disclosing and fixing them) in order to hack people and infringe on our right to privacy. See https://youtu.be/U_7CGl6VWaQ

It is possible that these agencies knew of the vulnerability in 2022, when it was introduced, or that they managed to introduce it themselves. But if they did not know, and if the communication channel between all these people over email was in the least bit insecure, then the NSA knew of the vulnerability for at least 2 months before it was patched. This gave them a zero-day vulnerability that they could use against all of us. In a way, it would have been better if the vulnerability was released publicly in November instead of being secretly disclosed in November. In that case,

1. There would be more urgency to fix it in a timely manner.
2. Everyone, including nation-states, would have access to the vulnerability, which would at least ensure that there is a sort of balance of power between them, keeping each other in check. By contrast, if only the NSA knew about the vulnerability, they could exploit it without limit before the vulnerability was publicly disclosed, over 2 months of time to attack any of us that they wanted to attack.

For more information, pick up Permanent Record by Edward Snowden at your local bookstore or library.

[Pjotr]

High-profile stuff like that, with a lot of publicity surrounding it, usually gets fixed pretty quickly by the Ubuntu Security Team. That's been my experience over the last two decades.

Linux security issues, big ones and small ones, are being discovered on an almost daily basis. Nothing is 100 % safe, and that will never change. Life on this planet is a risky affair. C'est la vie.

No need for alarm, as long as we don't have to wait too long for the redeeming fixes for the truly dangerous issues. So for the time being:

[Hoser Rob]

Mint should have gotten the update by now, glibc in my Debian 12 system was updated yesterday.

[Pjotr]

Mint should have gotten the update by now, glibc in my Debian 12 system was updated yesterday.

I'm smelling an upcoming cherry-pick.

[t42]

Regular "breaking news" on the Forum from bleepingcomputer and similar sources already became quite boring.
I understand that each 'local attacker' vulnerability adds significance to the person having said local attacker. Regretfully I never managed to obtain my own Local Attacker despite how hard I'd try.

Please note that this vulnerability has nothing to do with Linux Mint - it was introduced in glibc later and focal and jammy are not vulnerable.

[karlchen]

Hello, sylvain1_. Hello, folks.

I will restrict my reply to the relevant questions asked in the initial post.

New linux glibc flaw lets attackers get root on major distros.
https://www.bleepingcomputer.com/news/s ... r-distros/
Has mint been patched for this vulnerability? If so, how do I check to make sure that my version of glibc is not vulnerable?

The Bleeping Computer article makes clear that the security flaw, CVE-2023-6246, has been introduced into glibc 2.37 and it has been backported to glibc 2.36. So here we have the scope of affected glibc versions: 2.36 and 2.37.

• Short answer to find out whether the installed glibc is vulnerable:
  Source: https://www.xmodulo.com/check-glibc-version-linux.html
  Users of all Linux Mint versions can check which glibc version their systems use by executing the terminal command

  Code: Select all

  ldd --version

  The output will look like this:

  Code: Select all

  $ ldd --version
  ldd (Debian GLIBC 2.31-13+deb11u7) 2.31
  Copyright (C) 2020 Free Software Foundation, Inc.
  [...]

  The found glibc version here is 2.31, i.e. not vulnerable. (Debian 11 based)
  Remember: any glibc below 2.36 should not be vulnerable.
  .
• Detailled answer:
  
  Let us check what the Ubuntu Security page lists as affected Ubuntu versions.
  As we all know, the Linux Mint main edition is based on Ubuntu. (LM 20.x - Ubuntu 20.4, LM 21.x - Ubuntu 22.04)
  In order to get the overview table we use the search function on the CVE tab and search for CVE-2023-6246.
  The results can be inspected by following this link: CVE search results CVE-2024-6246
  Scroll down till you spot the list of Ubuntu versions and their vulnerability statuses.
  For all Ubuntu versions, including 20.04 and 22.04, the status is "Not vulnerable".
  Currently only Ubuntu 23.10 is affected and needs glibc patching.
  
  This means that no Linux Mint release, 20x and 21.x, is affected. So there is no need to be worried.
  
  Users of LMDE 5 and 6 will have to check which Debian releases bring along which glibc version in order to find out whether their LMDE might be affected.
  
  Users of all Linux Mint versions can check which glibc version their systems use by executing the terminal command

  Code: Select all

  ldd --version

  The output will look like this:

  Code: Select all

  $ ldd --version
  ldd (Debian GLIBC 2.31-13+deb11u7) 2.31
  Copyright (C) 2020 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.  There is NO
  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
  Written by Roland McGrath and Ulrich Drepper.

  The found glibc version here is 2.31, i.e. not vulnerable. (Debian 11 based)
  Remember: any glibc below 2.36 should not be vulnerable.

Karl

[Pjotr]

Good to hear. Needless alarmism; much ado about nothing.

[karlchen]

CVE-2023-6246 is more than nothing.
But no Linux Mint release, which is based on Ubuntu, is affected by it.
LMDE 5 is not affected by default (glibc 2.31)
I cannot check LMDE 6 myself, because I do not use it.
ldd --version will reveal whether glibc 2.36 or 2.37 is used on a system.


What can a user do, if ldd --version displays version 2.36 or 2.37?

In this case, you should launch Synaptic package manager and locate the software package libc6. Then check the changelog of the software package.
In case it mentions the CVE-2023-6246, then your glibc is an already bugfixed version.
In case it does not mention the CVE-2023-6246, chances are that you have got one of the still vulnerable glibc versions. In this case, before doing anything drastic and hence disruptive, open a new forum thread and ask.
(Do not forget to share your LM System Information and the complete output, displayed by ldd --version.)

[vimes666]

I just received an update for glibc on lmde6 (2.36-9deb12u3 -> 2.36-9deb12u4).

[MiZoG]

LMDE6 is affected but already patched

Code: Select all

glibc (2.36-9+deb12u4) bookworm-security; urgency=medium

  * debian/patches/any/local-CVE-2023-6246.patch: Fix a heap buffer overflow
    in __vsyslog_internal (CVE-2023-6246).
  * debian/patches/any/local-CVE-2023-6779.patch: Fix an off-by-one heap
    buffer overflow in __vsyslog_internal (CVE-2023-6779).
  * debian/patches/any/local-CVE-2023-6780.patch: Fix an integer overflow in
    __vsyslog_internal (CVE-2023-6780).
  * debian/patches/any/local-qsort-memory-corruption.patch: Fix a memory
    corruption in qsort() when using nontransitive comparison functions.

 -- Aurelien Jarno <aurel32@debian.org>  Tue, 23 Jan 2024 21:57:06 +0100

[Dullard du Jour]

I am on 2.35, I take it I will stay on 2.35 unless I jump a major release. Is that correct?

[sylvain1_]

Thank you, this is very good.

Linux Mint 21.3 Cinnamon.

Code: Select all

~$ ldd --version
ldd (Ubuntu GLIBC 2.35-0ubuntu3.6) 2.35
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

[karlchen]

I am on 2.35, I take it I will stay on 2.35 unless I jump a major release. Is that correct?

Right.
Linux Mint 22, which will be based on Ubuntu 24.04, will ship with a higher glibc version, the version, which Ubuntu 22.04 will bring along.
At the moment, however, there is no higher major Mint release than LM 21.x.

[t42]

Still don't understand why so much excitement for another buffer overflow vulnerability which requires local access. Indeed exploit would be successful if performed by competent enough person having access to your keyboard but the same person may perform so many other harmful things as well... I have one Debian 12 not updated system and indeed there is a segmentation fault:

Code: Select all

$ ldd --version
ldd (Debian GLIBC 2.36-9+deb12u3) 2.36
$ (exec -a "`printf '%0128000x' 1`" /usr/bin/su < /dev/null)
Password: Segmentation fault

But the point is the exploit can't be triggered remotely as it requires argv[0], the pointer to the array containing the name of the program which is being run from the command line.

[Pjotr]

Still don't understand why so much excitement for another buffer overflow vulnerability which requires local access. Indeed exploit would be successful if performed by competent enough person having access to your keyboard but the same person may perform so many other harmful things as well...

Well said. Local access vulnerabilities, as opposed to the truly dangerous remote access vulnerabilities, are usually not worth making a fuss about. But news media need to stir up hysteria; it's part of their business model....

Of course local access vulnerabilities need to be patched as well (blah blah blah), but they're rather trivial by nature. Because for exploiting them, a criminal needs to have physical access to the computer he wishes to hack. Hands-on, literally. Now, how big is the risk that such a criminal literally puts his hands on (the keyboard of) your machine?

Much ado about nothing very little.

[vimes666]

Local access vulnerabilities, as opposed to the truly dangerous remote access vulnerabilities, are usually not worth making a fuss about.

Well there is always the risk that the local vulnerability will be used in combination with a (unknown) remote access vulnerability.

[sylvain1_]

Local access vulnerabilities, as opposed to the truly dangerous remote access vulnerabilities, are usually not worth making a fuss about.

Well there is always the risk that the local vulnerability will be used in combination with a (unknown) remote access vulnerability.

+1

Also, as my original post talks about, lone cybercriminals who are on the other side of the world are not the only threats to deal with. Your government could also go to your house and tamper with your computer, while knowing your exact location at all times due to you carrying a cell phone. Your government may or may not require a warrant, but even if they do require a warrant, these agencies never get any serious consequences when they break the law and can even hide that they are breaking the law from legislators.

But also, even if you are not targeted, a 2 month time period between disclosure and patch is more than enough time for nation-states to use the vulnerability against corporations and other nation-states. Stuxnet was not a remote access vulnerability, for example. There is also the "evil maid attack" https://en.wikipedia.org/wiki/Evil_maid_attack. For example, we know that the Chinese do this to important Americans who visit China if they get the opportunity to do so, allowing them to steal intellectual property at the very least https://www.youtube.com/watch?v=ikh3ncJZPTU.

i am glad that Linux Mint 21.3 is safe and that LDME 6 is safe NOW. Being able to escalate to root privileges is very serious, like making an attacker a GOD over your linux machine. Linux may be more private than Windows and Apple, and Linux may be more secure than them (at least if you consider Windows and MacOS themselves to be malware), but it is perhaps not as secure as it appears to be. Here are a few posts about the deficiencies of the linux security model.

https://madaidans-insecurities.github.io/linux.html

https://madaidans-insecurities.github.i ... ening.html

https://madaidans-insecurities.github.i ... hones.html

[t42]

Your government could also go to your house and tamper with your computer, while knowing your exact location at all times due to you carrying a cell phone. Your government may or may not require a warrant, but even if they do require a warrant, these agencies never get any serious consequences when they break the law and can even hide that they are breaking the law from legislators.

Can this topic be moved from Chat about Linux Mint forum to the Propaganda forum?

[Dullard du Jour]

Your government could also go to your house and tamper with your computer, while knowing your exact location at all times due to you carrying a cell phone. Your government may or may not require a warrant, but even if they do require a warrant, these agencies never get any serious consequences when they break the law and can even hide that they are breaking the law from legislators.

Can this topic be moved from Chat about Linux Mint forum to the Propaganda forum?

Sounds like a good idea. He seems to be on a drive to save the internet world by 'fixing' Mozilla and Mint. It has gotten old.

[xenopeek]

New linux glibc flaw lets attackers get root on major distros.

Has mint been patched for this vulnerability? If so, how do I check to make sure that my version of glibc is not vulnerable?

You have the CVE numbers so you could have answered this yourself without the need for a topic.

• For Ubuntu based Linux Mint you can search the CVEs here https://ubuntu.com/security/cves to check the status for your package base. The security notices https://ubuntu.com/security/notices also give you this information.
• For LMDE you can search the CVEs here https://security-tracker.debian.org/tracker/ to check the status for your package base.

If you don't know your package base you can find it in System Reports > System Information (the package base is under 'System', the first section).