From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 08D3A384AB66 for ; Tue, 23 Apr 2024 18:54:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 08D3A384AB66 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 08D3A384AB66 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713898464; cv=none; b=xWtOigfy3iCISq4Jk2Y5jS/6tAXgNIkFU4UfJZkLDDJvRCUJWJ32XGGrlMAwrcaRDIhppusaQybVb5hkDvO+sfuUiFyD4IYN/72hSz4kS9lTOCUvVyn5K7XAvqmW42kmiWWmRJCd0rCgClX1TuTU3GtrxAavaZW4hOrxDMRLT+E= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713898464; c=relaxed/simple; bh=E1jqNC+gYbDTd896JzPQXdaYWcIegQRdaS/agHJHlU0=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=GtjtI/9cZ13k0kZWXqDkD7JVlKqyKw/twJsnJpIzGSHzHa9MgoUTu8s57JgTHOYPQvBbQevCniBiTZy6wVjMsREVcyBIOyBkK8orW9SboXRhCqicJhxL3dh7wTdExw1kOHJZS12BVdqumJg+aTeGdRvKaIYDaBS+tM4hUnTzSLE= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1713898462; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=iJabr3FiG26wrHVP6Q3Re9EJQvT/UO0jGcgoh1Z/JMc=; b=NHEun4uUt0IhS8tvzXonKwfFWYbyZkVXUAx4C6XwB/aIjBQ8pzyrRHfo+2KXTtyHEmuzHm yxpMR9W2XJQm7LPgPSEB4V8hEEeWuYFqeswu/fRYSm6UWwtZPlHhsApxaDVBQDueg1cv+u aMNuSEXvjGbiSMQhDqKjagp6DjasjrQ= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-357-7NjQ9YnlMrydn8CwhkKwUQ-1; Tue, 23 Apr 2024 14:54:19 -0400 X-MC-Unique: 7NjQ9YnlMrydn8CwhkKwUQ-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 60031800CAC; Tue, 23 Apr 2024 18:54:19 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.74]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A3C3D3543A; Tue, 23 Apr 2024 18:54:18 +0000 (UTC) From: Florian Weimer To: "Zack Weinberg" Cc: Subject: Re: Maybe we should get rid of ifuncs In-Reply-To: (Zack Weinberg's message of "Tue, 23 Apr 2024 14:14:23 -0400") References: Date: Tue, 23 Apr 2024 20:54:17 +0200 Message-ID: <87cyqfc3l2.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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: * Zack Weinberg: > I've been thinking about the XZ exploit (two versions of the compression > library `liblzma` included Trojan horse code that injected a back > door into sshd; see https://research.swtch.com/xz-timeline) and what > it means for glibc, and what I've come to is we should reconsider the > entire idea of ifuncs. > > The SSH protocol does not use XZ compression. liblzma.so was loaded > into sshd's address space because some Linux distributions patched > sshd to use libsystemd, and some libsystemd functions (having to do > with systemd's "journal" logging subsystem, IIUC) do use liblzma, but > by itself that wouldn't have been enough to give the exploit control, > because the patched sshd doesn't use any of those functions. But > these same Linux distributions also compile libsshd with -z now > (ironically, as a hardening measure, together with -z relro) and that > means the resolvers for all the ifuncs in *all* the loaded shared > libraries will be invoked, early enough in process startup that the > PLT and GOT are still writable. 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. > 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. That also happens for ELF constructors (but is perhaps fixable there). > 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 should be a relatively short patch (a few dozen lines), at least for Linux. Since commit 78ca44da0160a0b442f ("elf: Relocate libc.so early during startup and dlmopen (bug 31083)") we already relocate libc out of order. Beyond libc, there are still issues around symbol interposition (or underlinking) and execution of IFUNC resolvers implemented in yet-to-be-relocated shared objects. 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. (In general, I'd be worried to chase last month's problem.) > As far as I know, the only legitimate (non-malicious) use case anyone > wants for ifuncs is to allow a library to select one of several > implementations of a single function, based on the characteristics of > the CPU -- such as how glibc itself selects the best available > implementation of `memcpy` for the CPU. It seems to me that we ought > to be able to come up with a completely declarative mechanism for this > use case. Selection rules for string functions can be quite complicated, depending not just on advertised CPU capabilities but also on CPU models (and preferences derived from that). For each new selection criteria, we'd have to update glibc to implement it before it becomes usable by applications. 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. > And, in -z relro -z now mode, it would mean that no application code > could run before the PLT and GOT are made read-only, closing the path > that the XZ trojan used to hook itself into sshd. 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). Thanks, Florian