29 Feb
2020
29 Feb
'20
11:50 a.m.
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(a)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(a)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(a)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(a)checkpoint.com but
>> I'm sending this from eyal.itkin(a)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(a)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(a)uclibc-ng.org
>> https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel