From owner-freebsd-current@freebsd.org Sun Feb 28 11:27:05 2021 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 38CEB568A96 for ; Sun, 28 Feb 2021 11:27:05 +0000 (UTC) (envelope-from dmilith@gmail.com) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DpLhT0m4fz3jlj; Sun, 28 Feb 2021 11:27:04 +0000 (UTC) (envelope-from dmilith@gmail.com) Received: by mail-qk1-x733.google.com with SMTP id f17so13864093qkl.5; Sun, 28 Feb 2021 03:27:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=CMynhqs5q4v/9c7T0dVz5qSjKLjNNz0MBu+9q02OZMs=; b=NYP0hH3PqGQe/xEGP8bBndl0zTrk5E5noyFSF2DfKFS1chvfPZQJ2qzWZplT20Q6IO /g20Q6LxHA42vTBpzqdUX+rcPcJJhXA1e5hQ+SF5kZv5ZQBvWWYdmwpiPU5nYUhp5Vez AAngKfbAvuGLASacI0/JpD1QJpwXPMyXLx4YqEtzYwtmHNw2bTWUMBO2g8sJXF9XBzuf FCnjRFnUaTF5KbhScH+TJUK5STPJvwNXjdoSFO2wIKKJGGYmilmaLm9EHhlRwV9+UxKd MX9qixiBtR5S3MuF1a7vzn9N1+lgD9eMrK5lqcypPC4MVU46WyhExU4XYPq/bmkM5bq8 x5ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=CMynhqs5q4v/9c7T0dVz5qSjKLjNNz0MBu+9q02OZMs=; b=NFGDAZ1lALit2acG25J4v54xKbjSfY4vXzTLDC5r+2hjwdq5EZyDfDKPnplIWMa2j/ ETVv0gUbu2jHQ0wbWJALGdK5cwgoNP+1wtC2LY2XfcXv7aevHYB8R+JiTvo+8Zs6sIuk AbsVmn9xTNpKEDDHXaDPe+MX4ogAuZ8Z42O7RjkN4Od4SYVxacVTyUGAlRAXkvJTwQ1s r6gtFZ2lp+cjMG7DVAFlyQY9CZ+q3lznSKpQ1TxkBsPQCZSSfmw9MvnvoPoaLYPsbKki eR1IrYf5o8oLeqR4pcXdV5aIrOKca084Vo6XtfrGM/rsVOQ0a/6Xx0KmbYUzuNkzDo5T nM/g== X-Gm-Message-State: AOAM531puWXsdvW0b9jFqirHAHjcj5APMFIXSeDzkRKSJ/Y6KR+h4WFx h9hUpBagSogm6uppRVccwAFNlvpTA+BxpcV08K5ke1gRp1Q= X-Google-Smtp-Source: ABdhPJzXE7suGctpppkvwbVeTqUV/AlhlLOHZ4Gi15ynmO//tsEDdJuOh0mDbE9123oTvkBbbCfQEjxmFMu1Ovw7Ab8= X-Received: by 2002:a37:7747:: with SMTP id s68mr10520415qkc.198.1614511623813; Sun, 28 Feb 2021 03:27:03 -0800 (PST) MIME-Version: 1.0 Received: by 2002:ac8:b0f:0:0:0:0:0 with HTTP; Sun, 28 Feb 2021 03:27:02 -0800 (PST) In-Reply-To: <20210228062442.qk5nkzxt4msw2cgm@localhost> References: <20210228043411.mj7l5wkwj46neurv@localhost> <20210228062442.qk5nkzxt4msw2cgm@localhost> From: "dmilith ." Date: Sun, 28 Feb 2021 12:27:02 +0100 Message-ID: Subject: Re: HEADS-UP: PIE enabled by default on main To: Ihor Antonov Cc: Warner Losh , FreeBSD Current , Gordon Bergling , Ed Maste Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4DpLhT0m4fz3jlj X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2021 11:27:05 -0000 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=E2=80=A6 On 28/02/2021, Ihor Antonov wrote: > On 2021-02-27 22:29, Warner Losh wrote: >> On Sat, Feb 27, 2021 at 9:34 PM Ihor Antonov >> 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 whol= e >> > 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? Doe= s >> > 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 i= s >> 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 tick= ed > 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) bu= t > it does not look good form the outside. You are sending mixed signals to > your auditory. > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > --=20 -- Daniel Dettlaff Versatile Knowledge Systems verknowsys.com