From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 37EACC433DB for ; Fri, 5 Feb 2021 15:31:47 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 961F5650EC for ; Fri, 5 Feb 2021 15:31:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 961F5650EC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:56692 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l835F-00030c-GS for qemu-devel@archiver.kernel.org; Fri, 05 Feb 2021 10:31:45 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:53830) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l8333-0001vl-E1 for qemu-devel@nongnu.org; Fri, 05 Feb 2021 10:29:30 -0500 Received: from mail-ej1-x636.google.com ([2a00:1450:4864:20::636]:41866) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l8330-0005Bf-OE for qemu-devel@nongnu.org; Fri, 05 Feb 2021 10:29:29 -0500 Received: by mail-ej1-x636.google.com with SMTP id f14so12521326ejc.8 for ; Fri, 05 Feb 2021 07:29:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UQ0FvqEsvwhOk1J4aJRozU/5FhgB0VGKiDGGsG4//rw=; b=Ab9CSnmhQzkZR/cpBXjY3+uocCQDKvCeWJ2Wz00b5LoSap8nsI6+fmijNjeHlg0Z4n XCBY1dzAwTmXk3uzdZyJb7E3tXsC8yIyupAoqpzh0wcwN7/xFU5rPWLSAD00ZPbzMXCn jFWc8TRG18Ru05TR7exOajo3NUy4zOdPTOVhU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UQ0FvqEsvwhOk1J4aJRozU/5FhgB0VGKiDGGsG4//rw=; b=Hx56bEQw40weH0okC0gWQo155WVZh4Tm2eeXu99/eJ5XDG7SeVFq4aAJ9e3Qt03pWe 6ihiq6Hhx4B9+iz9aAG/z8+OPKIh6J6KcldDUAJ9tnKBDFiNvr+ojYG6dKeV3jfMYZnK ftbvtojRKhNnwXNTRF5wX8eyU4uoeJUOyFmA5/FkEL05OfTmvPiXCgL6llAZ2GSQmGpn mz+jT1uTmAs6Q4NPGcRzhq5mJbXiZzep+/sABRH8ezgpF7bxDyY+k6gDtj1xVyEMFlLp o0K1HrUwxqA4DWh0Ug0KmjqYwmjZb3iM39WC6OfTNE8hTlnBaxMnrpi9s6DKCeM1G4jW uguw== X-Gm-Message-State: AOAM531ZUYw7HFvj62Lfk/MdpAtGiOOlySu5xeBp8k9QCqotwqfQhWp9 RSOF6AUObOTIWs/R2g3R5VNZLIcuTW7sQsIc9BDwYw== X-Google-Smtp-Source: ABdhPJy+n5T4noLuXUlz4IJwSviadqTlNl9uZlJ9y4YVp2b9WdQfkJLPWyolH6xFMd2vj/WvGe9obsu1hxFVMcK0pZY= X-Received: by 2002:a17:907:78d5:: with SMTP id kv21mr4538731ejc.461.1612538963116; Fri, 05 Feb 2021 07:29:23 -0800 (PST) MIME-Version: 1.0 References: <20210127112131.308451-1-stefanha@redhat.com> <20210128184416.4dbdd23b@bahia.lan> <20210201171440.GA180539@stefanha-x1.localdomain> <20210201182215.GA221556@stefanha-x1.localdomain> In-Reply-To: <20210201182215.GA221556@stefanha-x1.localdomain> From: Chirantan Ekbote Date: Sat, 6 Feb 2021 00:29:11 +0900 Message-ID: Subject: Re: [Virtio-fs] [PATCH v3] virtiofsd: prevent opening of special files (CVE-2020-35517) To: Stefan Hajnoczi Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a00:1450:4864:20::636; envelope-from=chirantan@google.com; helo=mail-ej1-x636.google.com X-Spam_score_int: -95 X-Spam_score: -9.6 X-Spam_bar: --------- X-Spam_report: (-9.6 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.352, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Daniel Berrange , qemu-devel@nongnu.org, P J P , virtio-fs-list , Greg Kurz , Alex Xu , Laszlo Ersek , Vivek Goyal Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Tue, Feb 2, 2021 at 3:22 AM Stefan Hajnoczi wrote: > Hi Chirantan, > I wanted to bring this CVE to your attention because the discussion has > revealed a number of other issues (not necessarily security issues) in > virtiofsd that may also be present in other virtio-fs daemon > implementations. > Hi Stefan, Thanks for the heads up. I'm going to summarize the thread just to make sure I understood correctly. The CVE seems to be that the virtio-fs daemon allows opening special files and the short-term fix is to detect and block this in the daemon. The long term fix is to mount the data with nosuid,nodev,noexec. I think crosvm's virtio-fs also doesn't check the file type before opening it but chrome os has mounted all stateful data as nosuid,nodev,noexec as long as I can remember so I think we got lucky there. It's probably still worth adding the check to the server. The other issue is that there is a race between when an entry is created and when we look it up by name where it may be modified and replaced by an external process. While I can see how this can be fixed for files, it seems like there's no choice for directories. It's not like mkdirat returns an fd for the newly created directory. Though, it seems like every process is affected by this. I guess if you wanted to be really paranoid you could do something like mkdtemp, get an fd, and then rename to the real name. Did I miss anything? Thanks, Chirantan