From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id a71b33ba for ; Sun, 15 Dec 2019 07:58:28 +0000 (UTC) Received: (qmail 24151 invoked by alias); 15 Dec 2019 07:58:20 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: List-Unsubscribe: X-Seq: 24533 Received: (qmail 2927 invoked by uid 1010); 15 Dec 2019 07:58:20 -0000 X-Qmail-Scanner-Diagnostics: from mail-wm1-f41.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.1/25656. spamassassin: 3.4.2. Clear:RC:0(209.85.128.41):SA:0(-2.0/5.0):. Processed in 1.619116 secs); 15 Dec 2019 07:58:20 -0000 X-Envelope-From: andrew.j.c.parker@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.128.41 as permitted sender) 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=lxjsKYiDTkgLE12axeOEq0nL3kp650CEyIHUdShctBo=; b=Q/SzNFC3AJOUN06RATaFEbOQ3uhbPGiRb9JoS/UYVRV73y3/o0guELASWW4o75Fuzc x68IqmeQO5MJHaPbsN8vXQKKTGvwuWov5kgENPnrHpKv6pVsyXdpX/m+v4e1z1816hWk Sv4CDaaNxH+aJPLEX8q5FbSlm1JNNyG7kVvqB8gmfd35TQIM5HLElehvcUbAiPJI4LZe J2j8ObN8XXyb2/+VPRx1jqSW7+k++oWHlKO8+lYZOZUAuX8vzjbmonjNvrBpbd09H429 3FQiaUi4BFxyodrCwBZ1SbIGLC5vQC2ElFnxzlbTRWgSMBk7CXg2fO1BY7KY7FChOW1k WhVg== X-Gm-Message-State: APjAAAVDKhw/svxNNM71RuQ2kF8IVHylP2z8OauZlXDwGU4csrfZkuow LcFsC54VTkKHyUeVksJttFC2wzXY7XYQpXbrx8NuCw== X-Google-Smtp-Source: APXvYqwMey2Ih1GHqfcYJd/z0rNrW9cTRpVuFESjtjWqQZbcow/o9s5+zLdy4toawVTCDuLs4s6gyVfpm2UijKOyvfk= X-Received: by 2002:a1c:8086:: with SMTP id b128mr24162940wmd.80.1576396664166; Sat, 14 Dec 2019 23:57:44 -0800 (PST) MIME-Version: 1.0 References: <20191215071417.ivb76lzapj43ag3z@tarpaulin.shahaf.local2> In-Reply-To: <20191215071417.ivb76lzapj43ag3z@tarpaulin.shahaf.local2> From: Andrew Parker Date: Sun, 15 Dec 2019 15:57:32 +0800 Message-ID: Subject: Re: Thoughts on protecting against PATH interception via user owned profiles To: Daniel Shahaf Cc: zsh-users@zsh.org Content-Type: multipart/alternative; boundary="000000000000315dd80599b9736d" --000000000000315dd80599b9736d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Daniel Thanks for the response The privilege escalation comes after the PATH is changed. The problem effectively is me, the developer. I run another program which escalates and inherits the PATH variable. That program then executes commands without specifying the full path to the binary. Here's an example Consider Homebrew. The installation script calls sudo. The root shell inherits my user's env. Brew them executes numerous commands that can be intercepted. My system is now forever compromised. It's easy to argue that this is a homebrew issue. However what about the 100s if not 1000s of "reasonable quality" tools that do similar things. As a modern developer how am I supposed to handle this? Do I have to audit every tool I use before allowing escalation? That's maybe a reasonable argument as well, but that's a hell of an overhead. Then what about upstream dependencies? Just because I audited homebrew today doesn't mean it'll be good tomorrow. Do we expect every developer to do this? Not really. Even if I do this, do I expect that I'll remember or get it right every time? Not really. So my view is that a defence in depth strategy is the best approach. A relatively cheap and simple change would, at least as far as I can see, potentially add a lot of benefit to a lot of people. Took a quick look at taint btw. Not a perl user. Seems interesting but seems much broader in scope. Will check more later. AFK at the moment Andrew On Sun, 15 Dec 2019, 15:14 Daniel Shahaf, wrote: > Andrew Parker wrote on Sun, Dec 15, 2019 at 14:27:45 +0800: > > I'm curious to hear the community's thoughts on the threat of PATH > > interception in shells. Specifically, it's very easy for a malicious > > process, running as regularly user, to interfere with your profiles and > > there's no fool-proof way to protect against this. For example, a > malicious > > binary can easily change a profile to insert something into your PATH. > Once > > that's done a privilege escalation is extremely feasible due to the vas= t > > number of tools that rely on your path and which don't specify full pat= hs > > to binaries they in turn shell out to. > > So you're saying is that an attacker that can run arbitrary code as your > user > *now* can use this to modify script files (such as ~/.zshenv) to be able > to run > arbitrary code as you *later*. > > First of all, this is not what's normally meant by a "privilege escalatio= n" > attack. That generally means "Alice can run code as Bob". > > As to your attacker, you could uninstall zsh entirely and he'd still have > any > number of ways to run code as you =E2=80=94 for example, by editing > ~/.config/autostart/, or ~/.xinitrc, or ~/.vimrc, or ~/.gitconfig=C2=B9, = etc., > or by > running crontab(1) or at(1). > > The short answer here is that untrusted applications should not be given > write > access to files that will be executed by trusted programs. Traditionally= , > untrusted applications would be run under a dedicated unprivileged uid, a= nd > their output sanitized if needed. Nowadays there are tools such as Qubes > (q.v.). > > > My question is whether zsh (and other shells) would ever be interested = in > > implementing a solution to this. My suggestion would be something like > the > > following (although there may be better alternatives): > > > > * zsh uses a config file in e.g. /etc directory which much be owned and > > only writable by root > > * The config can be used enable "protected profiles" > > * Once protected profiles are enabled, only profiles which are owned an= d > > only writable by root can be sourced on startup > > > > I think you've basically reinvented Perl's taint mode ("perl -T"). > > Anyway, even if you wanted to implement a taint mode in zsh, treating > dotfiles > as tainted is simply not enough. There's any number of ways to mount > a "delayed code execution" attack _against zsh_ without editing the > dotfiles. > > Cheers, > > Daniel > > =C2=B9 =C2=ABgit which __git_config_option-or-value | egrep -c > '_absolute_command_names|_cmdstring'=C2=BB > prints 33. > --000000000000315dd80599b9736d--