HEADS-UP: PIE enabled by default on main

Toomas Soome tsoome at me.com
Sun Feb 28 12:23:41 UTC 2021



> On 28. Feb 2021, at 13:27, dmilith . <dmilith at gmail.com> wrote:
> 
> First of all - ALSR is designed as mitigation for external attacks,
> not internal ones (logged in user).
> Second - Linux and FreeBSD both have weak implementations in
> comparison to PAX-driven ones. Try attacking the system with
> Grsecurity or HardenedBSD (both use the strongest ASLR available
> AFAIK).
> 
> Saying that security mitigation features that affect no performance
> are "meaningless", is just ridiculous or at least just irresponsible.
> It's like telling C programmers that stack protection or out of bounds
> checks are bad, cause there's nothing wrong with random SEGFAULTS from
> time to time…
> 


You seem to forget that those mechanisms are there exactly because programmers are not caring about random faults from time to time:D With correct code, one would not need mechanisms like ALSR. 

rgds,
toomas

> 
> On 28/02/2021, Ihor Antonov <ihor at antonovs.family> wrote:
>> On 2021-02-27 22:29, Warner Losh wrote:
>>> On Sat, Feb 27, 2021 at 9:34 PM Ihor Antonov <ihor at antonovs.family>
>>> wrote:
>>> 
>>>>> 
>>>>> But isn't it well-known that ASLR/ASR/any-related-buzzwork does not
>>>>> add
>>>>> any security, except imaginary?  The only purpose of it is to have a
>>>>> check-list item ticked green.
>>>> 
>>>> I don't know if I should parse this as sarcasm (or any other form of
>>>> "humor") or is a serious statement? But this does leave me with a whole
>>>> bunch of questions..
>>>> 
>>>> If this is really how Konstantin is describing it then is it OK to say
>>>> about this to the whole Internet? Why FreeBSD Foundation is paying for
>>>> meaningless work then? Why members of the Core team do this work?  Does
>>>> this mean that FreeBSD is working to satisfy the silly needs of some
>>>> fat
>>>> customer? What about project independence and not being controlled by
>>>> big money?
>>>> 
>>>> Where can I read about ASLR and security myths?
>>> 
>>> Why not spend time and explain why this does not work?
>>>> 
>>> 
>>> Not to rise to the baitiness of all these leading questions (they really
>>> are quite contrary to how our community usually comports itself, but for
>>> the sake of civil discourse, I'll ignore)....
>>> 
>>> I'll bet it has something to do with the many known ASLR attacks.  One is
>>> chronicled in https://www.vusec.net/projects/anc/ and elsewhere, which
>>> show
>>> how MMU side channels can defeat ASLR. Or maybe he's familiar with the
>>> offset2lib attack against Linux 64-bit ASLR documented in this paper
>>> https://cybersecurity.upv.es/attacks/offset2lib/offset2lib-paper.pdf.
>>> There's many others as well that show the shortcomings of ASLR and
>>> disclose
>>> ways to defeat it using various clever means.
>> 
>> Warner, thanks for the links. They are indeed interesting.
>> 
>>>> You clearly should mean something useful and much more important than
>>>> that,
>>> 
>>> Maybe he'd like to understand how PIE accomplishes better security give
>>> the
>>> known ASLR weaknesses. And rather than take a sarcastic tone, he asked
>>> for
>>> more details that back up the earlier claims of improved security so we
>>> could all learn something.
>> 
>> The conclusion of the paper in the second link clearly says:
>> 
>>    We present a new weakness on the current implementationof the ASLR
>>    Linux systems which affects PIE compiled ex-ecutables.  Applications
>>    compiled with PIE are consideredto be more robust since it makes
>>    attacks more difficult.
>> 
>> Which I read as ASLR and PIE work better together. This is the same what
>> Gordon was saying.
>> 
>> The whole situation is wrong on 2 different levels.
>> 
>> First: saying that ASLR is not perfect and can be broken is not the same
>> thing as saying "The only purpose of it is to have a check-list item ticked
>> green"
>> 
>> There are no perfect security measures, and you guys (kernel and OS
>> developers) should know that better than us (users). Hackers find new
>> exploits, developers find ways to mitigate them and cycle repeats. Just
>> the fact that ASLR can be broken is not the reason to not have it.
>> 
>> Second: look at this exchange from a distance
>> 
>> Ed: we are enabling security feature X, please rebuild your worlds..
>> Godron: great progress! go team!
>> Konstantin: why do you think this is great progress? (implying it is
>> not)
>> Gordon: well, I heard feature X works best with feature Y
>> Konstantin: feature Y is useless checkbox, next time you speak make sure
>> you say something useful!
>> 
>> Considering the fact that Konstantin himself worked on ASLR this is at
>> least confusing.. Also does this also mean that feature X (PIE) is also
>> useless checkbox?
>> 
>> Konstantin, Ed, Warner - I dunno what is going on in your house (Core) but
>> it does not look good form the outside. You are sending mixed signals to
>> your auditory.
>> 
>> 
>> _______________________________________________
>> freebsd-current at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>> 
> 
> 
> -- 
> --
> Daniel Dettlaff
> Versatile Knowledge Systems
> verknowsys.com
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"



More information about the freebsd-current mailing list