Re: [PLUG] memory corruption sec hole

[Rich Freeman via plug <plug@lists.phillylinux.org>]

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