I checked in the code, and it looks like the correct macro for enabling this feature only on Linux will be: __UCLIBC_LINUX_SPECIFIC__. Before I send an additional commit for correctly wrapping up this feature, I just wanted to check with you, is this the correct flag to be used?
I thought of setting the configuration as follows: * A global configurable disable flag, that is off by default (I don't know how to set one, and I will need your assistance) * if __UCLIBC_LINUX_SPECIFIC__ is not defined, the disable flag will be automatically defined (in the code level)
This way, the feature will be on by default only on Linux, and it could be manually turned off by developers. In the future, if it will be applicable to other environments as well, it will be easier to modify the second condition accordingly.
Will be happy to hear what you think about this. Eyal Itkin.
On Sun, Feb 16, 2020 at 10:18 AM Eyal Itkin eyal.itkin@gmail.com wrote:
We benchmarked it on glibc and the overhead wasn't even measurable. In addition, the average overhead on TCMalloc's testsuite was 0.02%, so the impact is quite negligible.
We've just finished a research when uClibc was used on a Linux OS and there was ASLR for the heap. This protection would have blocked our exploit completely, if it was already deployed.
I agree that on operating systems without ASLR, there isn't any added value for this protection. If there is some way do automatically enable it for ASLR enabled OSes it would be the preferred method. From my experience when security is not opt-in by default, it never gets activated.
On Sun, 16 Feb 2020, 10:10 Kjetil Oftedal, oftedal@gmail.com wrote:
Hi,
Shouldn't this be a config option, since there is a performance hit? On most embedded architectures the heap is in a fixed position, so the there is no randomness to extract from ASLR, thus they are only left with the performance overhead.
Best regards, Kjetil Oftedal
On Sun, 16 Feb 2020 at 07:02, Eyal Itkin eyal.itkin@gmail.com wrote:
Hi,
Sorry for the formatting problem, I'm having trouble sending each open source project the patch in their own format, and I probably mixed up something. The patch is now attached to this email.
In addition, I also attached the White Paper that describes this new security mitigation.
Just as a side note: the patch is signed by eyalit@checkpoint.com but I'm sending this from eyal.itkin@gmail.com due to mail issues with my work e-mail (which is connected to my GitHub account).
Thanks again for your cooperation, Eyal.
On Fri, Feb 14, 2020 at 11:40 AM Waldemar Brodkorb wbx@uclibc-ng.org wrote:
Hi, Eyal Itkin wrote,
Safe-Linking is a security mechanism that protects single-linked lists (such as the fastbins) from being tampered by attackers. The mechanism makes use of randomness from ASLR (mmap_base), and when combined with chunk alignment integrity checks, it protects the pointers from being hijacked by an attacker.
The patch does not apply with git am ontop of uClibc-ng master. What mail client do you use and could you try to use git format-patch -s origin and send an e-Mail with the patch as attachment so it does not get corrupted somehow.
best regards Waldemar
devel mailing list devel@uclibc-ng.org https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel