From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fout1-smtp.messagingengine.com (fout1-smtp.messagingengine.com [103.168.172.144]) by sourceware.org (Postfix) with ESMTPS id A5021385840D for ; Wed, 24 Apr 2024 13:53:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A5021385840D Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=owlfolio.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=owlfolio.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org A5021385840D Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=103.168.172.144 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713966816; cv=none; b=UNDZ2tcJxmzaiZpVu0BKY7bGRIy/RdZgOiYUh7tPdWtITvf/99ofCP2cELNwRajtBSU8KQAFrbb5hvcEPYPYBOM7qcpIzlLraPEVKEDqBJYSOpMQV7g6a9Rcjg20gT3PqeNFvg8oTT/ucRdKiRI2HLpp3ZSV7UWfMnf89JxZU6U= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713966816; c=relaxed/simple; bh=bD0/JRPqTn/3rEQk7kKRdopG0q9Jt3PrCqEyB9Wrwr8=; h=DKIM-Signature:DKIM-Signature:Mime-Version:Date:Message-Id: Subject:From:To; b=v7MJZLvKDIUvVJyvUtlwrpD9ys1hzgqWvmEeSS6ZmK4c5Wu2YfY9prjx0lGL10wixiJ7CotnSsajb4o7WmPw4e+exL3l+hcIsRuoBk7sYcYNC0aRoju8sZT+BWKQsaIHGyP8M9yyR9MjFQr5PpMqtKjBf71RoT3PjY/xCivHcXo= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfout.nyi.internal (Postfix) with ESMTP id 6F8AF138011B; Wed, 24 Apr 2024 09:53:34 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 24 Apr 2024 09:53:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=owlfolio.org; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1713966814; x=1714053214; bh=52LBbKwJGtthYMdf9qF2JSvvtX0O4V/gK6YAQ9X5VtU=; b= av1DIP6O7uxgeZQI5BT5OEbX2y13Wb/GVPzhdtmSlf59DzvGSGTpzGUMBXNQ1um/ muYCtvfbNY6yZ3VwYxWPyOnEX+C0eWJKnnJTC9QNYjSvmd/zukuCc7kw0dIvXAqc FyCEcFge9+MYoqOPfORxKrZ7KMTIu9DPEQN5aR2rwsPFJ+/Ea2XCHxM8TIq+F9uq TjG4tlLM62RcVn3aDwLxbHk4+EeF0R9T7OmsP+tNkK7guWnOTf+lQrXZkUw+oJ/Q MB+45EUWnvlsnlsMAWsApBmc4V7TWMIqeXxntJCTZOPMwCy1mdyXippnRBpDjQIl wDe8Tkq2ixBQw7qe86MGhg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1713966814; x= 1714053214; bh=52LBbKwJGtthYMdf9qF2JSvvtX0O4V/gK6YAQ9X5VtU=; b=b 3Sa2AzqDhRYNNA3qlg4vzMJ2FbHHk75Wu3tWS8JrduDXeGd5Y7JcF2YlcIuLYeSk u1RVIFUnsvKnWx5mZPyEv6mXhrDpom2NrrfGIzQoifwzAx44K+y8XY+eJKzqGCP4 PibgNlXARphkWzgt1ys8Z3SUg0/ZQRK9RKnQz5wTMJQdZ/cRgZIXnkfqDH5+JAbY kQtR/Hxs2uxOEZAFgN88k3pKUJHJvnPIahDGPOv4vUkrCHucgw4mYGWcXbTTnPrj NPD5YwNzBzM/WfIT9mCyB811SkptMzOIRttcXIJYhju4tJzqHtYHNWsVCY86X5ye lObs6TPkVYcN9y2QioFVg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudelhedgtdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepggfgtgffkfevuffhvffofhgjsehtqhertdertdejnecuhfhrohhmpedfkggr tghkucghvghinhgsvghrghdfuceoiigrtghksehofihlfhholhhiohdrohhrgheqnecugg ftrfgrthhtvghrnhepvdekueehgfejtdekieeiiefghfffkeelueffvdeuffegtdevuefh vdegffdutdetnecuffhomhgrihhnpehophgvnhhsshhlrdhorhhgpdhrvghlrdhrohenuc evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpeiirggtkhes ohiflhhfohhlihhordhorhhg X-ME-Proxy: Feedback-ID: i876146a2:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 24 Apr 2024 09:53:33 -0400 (EDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 24 Apr 2024 09:53:33 -0400 Message-Id: Cc: Subject: Re: Maybe we should get rid of ifuncs From: "Zack Weinberg" To: "Florian Weimer" X-Mailer: aerc 0.16.0 References: <87cyqfc3l2.fsf@oldenburg.str.redhat.com> In-Reply-To: <87cyqfc3l2.fsf@oldenburg.str.redhat.com> X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue Apr 23, 2024 at 2:54 PM EDT, Florian Weimer wrote: > * Zack Weinberg: > > The XZ exploit used an ifunc resolver to rewrite a whole bunch of > > PLT entries, intercepting both calls within sshd proper, and calls > > from sshd to libcrypto.so (i.e. OpenSSL's general-purpose > > cryptography library). > > GOT rewriting wasn't required. OpenSSL itself has support for hooking > the relevant functions: > > > > For some of the link orders I've seen, plain ELF symbol interposition > would have worked as well. We don't know if such a thing gets detected > in practice. I haven't looked closely at the actual Trojan payload myself; I didn't know it overtly defined symbols that collide with libcrypto entry points (thus potentially interposing those symbols). My goal with this proposal is not to make XZ-type exploits *impossible*, but rather, to make them easier to detect. Calls to RSA_set_method, calls to the "newer OSSL_PROVIDER API" as mentioned in the above manpage, and symbol collisions between libraries that have no business interposing on each other: these can all be mechanically detected, at least in principle. > > Ifuncs were already a problem -- resolvers are arbitrary application > > code that gets called from deep within the guts of the dynamic loader, > > possibly while internal locks are held (I don't know for sure). > > Internal locks are held. Yikes! That by itself seems like a strong argument for replacing this mechanism. > > In -z now mode, they are called not just before the core C library is > > fully initialized, but before symbol resolution is complete, meaning > > that they can't necessarily make *any* function calls; we've had any > > number of bug reports about this. > > We are getting closer to be able to fully initialize libc before IFUNC > resolvers run. It's good to know that it's *possible* to make ifunc resolvers more robust, but right now I'm not sure it's *worthwhile*. Unless someone has a use case that isn't CPU-based code selection, I currently think replacing ifuncs with something declarative would be a good idea regardless of potential security benefits. > In the other direction, I think it would be valuable to offer a mode > where we run ELF constructors when .data.rel.ro is still writable. What uses do you see for this mode? > (In general, I'd be worried to chase last month's problem.) Well, this is hardening -- every little bit helps. As I said above, my security goal here is to make it so potential interception of function calls to library A by library B is easily machine detectable. We would still need to build the machine, of course, but that's well within the scope of existing projects (e.g. archive-wide Lintian scans). > I'm not sure how valuable it is to prevent code execution at the > relocation stage when a few microseconds later, the ELF constructor is > invoked, which by definition contains arbitrary code. I see it as valuable precisely because ELF constructors (should) run after the PLT and GOT are made read-only. I do have a sketch of what it would take to move ld.so completely out of process, if you're interested in bigger hammers. > It's possible to revert RELRO. We do that for static dlopen on some > architectures (something that could be avoided with early libc > initialization described above). What would it take to get rid of that possibility? zw