Rich Freeman via plug on 22 May 2020 06:40:45 -0700 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: [PLUG] memory corruption sec hole |
On Fri, May 22, 2020 at 9:26 AM jeff via plug <plug@lists.phillylinux.org> wrote: > > http://rss.slashdot.org/~r/Slashdot/slashdot/~3/oRgpExD1FEY/check-point-releases-open-source-fix-for-common-linux-memory-corruption-security-hole > > An anonymous reader quotes a report from ZDNet: For years, there's been > a known security vulnerability hiding in the GNU C Library (glibc). This > library, which is critical for Linux and many other operating systems > and programs, had a dynamic memory management security hole that could > be used for denial of service (DoS) attacks The links in the post are a bit vague as there is nothing specific to the "vulnerability" itself, but based on what I'm seeing so far this isn't really a "vulnerability" per se but an additional layer of protection for other vulnerabilities. This is like address space randomization or stack smashing protection. Those enhancements to compilers/etc don't actually fix vulnerabilities in the original code, so much as adding additional protections to make it harder to exploit other vulnerabilities. Basically the new patch makes it harder to tamper with linked lists, assuming that an attacker has the ability to write to a processes memory. Obviously if an attacker can write data to process memory there is already something really wrong. So, just like stack canaries and so on this patch helps to detect if somebody is playing games with memory and stop these attacks. I think the word "vulnerability" is sensational here. If you turn off stack smashing protection on gcc you aren't introducing a vulnerability - you're removing a mitigation that protects you against vulnerabilities that may or may not exist in your code. It can only introduce a vulnerability to the degree that the vulnerability was already there and is just no longer mitigated. To confuse things they link to an ACTUAL vulnerability in Hue light bulbs. I couldn't find details on what the actual vulnerability was, but no doubt it involved some kind of failure to do bounds-checking and so on, and perhaps this enhancement to glibc has helped them to further improve things. One of the slashdot comments brings up rowhammer and that might be another situation where this could add protection. If I missed something please let me know, but this seems like a new feature to make things more secure, not an actual vulnerability that exists in glibc. No doubt like stack-smashing and so on turning this on may have side-effects (which is why it took years for that to become more of a default in gcc in distros). -- Rich -- Rich ___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug