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. Now, the security company, Check Point, has issued an open-source patch, which will make it much more difficult to exploit this memory allocation (malloc) problem. Check Point re-encountered this known problem when it discovered that so-called smart light bulbs could be used to hack into networks by exploiting unprotected single-linked-lists. The double-linked-list version of this problem had been fixed back in 2005 with Safe-Unlinking. But, the single-linked-list version, which is present in the memory primitive functions Fast-Bins and Thread Cache (TCache), remained vulnerable.

Now, the fix is in for this problem. This new built-in security mechanism is called Safe-Linking. It protects malloc by signing its single-linked-list pointers with random numbers derived from Linux's Address Space Layout Randomization (ASLR) functionality. Combined with memory chunk alignment integrity checks, it protects the memory pointers from hijacking attempts and thus the system itself. The patch is now being integrated with the most common standard C library implementation, glibc. Safe-Linking will be released in glibc 2.32 in August 2020. It's already up and running in glibc's popular embedded counterpart: uClibc-NG.

Where is that alleged "security hole"?

[ffkom]

From the linked patch I understand Checkpoint proposed additional code to make it harder for adversaries to exploit whatever security issue allows them to overwrite pointers of memory management lists. While that may be not a bad idea to do, the absence of such a measure is not a "security hole" per se. There is no bug or such referenced in glibc that would introduce security holes into software if there isn't already one.

Re:Where is that alleged "security hole"?

[skids]

I think this might be a mitigation for rowhammer attacks. (?)

That would put the "security hole" in the hardware. Really we should be chucking old defective silicon or at least assigning it to only run trusted code with trusted content... but at this point I don't think anyone has confidence that the newer stuff coming off the line is watertight either, and we've come to rely so much on performance gains from insecure optimizations that that's an impossibility in the real world, so it's all an exercise in sacrificing small amounts of performance to make attacks much more expensive.

Re:Where is that alleged "security hole"?

[phantomfive]

The referenced explanation [dhavalkapil.com] suggests that you need to have some kind of unbound write, like strcpy() or similar. But strcpy has been deprecated for over 15 years, so if it's still being used, then you have bigger security problems guaranteed.

Right, requires arbitrary memory write

[raymorris]

That's my understanding too.
If the attacker has some other means to write their choice of bytes into memory locations they aren't suppose to have access to, then they can mess up a linked list.

Which is kinda like saying "the hand lotion bottle is insecure f a burglar is in your house and you're not home, he can switch your hand lotion for Nair". Well of the attacker has access to do whatever they want ... well they can do whatever they want. A burglar can do a lot more than switch your lotion for depilatory cream if they already have free run of your house.

Having said that, I may have a security safe in my house.
That way, even if a burglar has free reign of my house, he can't get to certain valuables. The same approach CAN make sense in software. There is a performance cost, just as it's inconvenient to store your watch I a safe when you aren't wearing it.

Re: Where is that alleged "security hole"?

[eyalitki]

Sorry, I can't control what the media writes about my research. Safe-Linking aims to solve a non-robust design in malloc (ptmalloc/dlmalloc/tcmalloc). Calling it a vulnerability is a bit bombastic. Attackers were focusing their exploits on single-linked lists (fastbins, tcache) once they had an initial heap-based buffer overflow. This protection protects the pointers of the list, forcing an attacker to need a leak before he could start his attack. More info in our technical blog: https://research.checkpoint.co... [checkpoint.com]

Re:

[Simon Rowe]

You don't mention https://musl.libc.org/ [libc.org] has any work been done for that?

Re: Where is that alleged "security hole"?

[eyalitki]

Working with glibc, uClibc-NG, and Google (gperftools and later on TCMalloc) was quite intensive. We hoped that musl and others will integrate it as well after they will see it was adopted by glibc and uClibc-NG. We will gladly help them integrate it if they need any assistance.

Re:Where is that alleged "security hole"?

[DamnOregonian]

You're correct. It's not a security hole at all.
The patch proposes making malloc list structures more resilient against accidental or purposeful corruption.
I've used a similar strategy with my own code to track down bugs in C- structure canaries with preprocessor accessors (so they can be compiled out) that verifies the canary isn't dead (structure hasn't been modified outside of intended programming)

This patch brought to you by...

[Fly Swatter]

And so it begins.



:(

Hypocritical much?

[alexo]

When its an article about NSO Group breaking into cellular phones, the summary prominently states that it's an "Israeli surveillance company", but when writing about Checkpoint submitting security patches to open source, they are just a "security company".

Either the nationality matters or it doesn't.