X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=SAOOHXDoMPwMIe+V+B1Z6wTGTF+DCG6zf9nSMkmZzmQOp+MdyZsfH
	Dl6oQHK/PjQqnhfW4AQzd0QHmTH4clc84NJn4I3r7ph0goP6gYVACWPKlPjWSs4P
	+p9ACg0mv05cVDTh6VRx7HlhyI0db68Hemz+wdBlS+k6QrLtnJHp4g=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	 bh=g5tRm31dXToAQt9+U54zDjqAZpE=; b=xQJ8OPEJgLIU0Fbe4rNE3LeoWTK/
	OR6EMu612Pd3H4jI98M3LR6bPzVzordiP/nl2PK2+n72R+pOhzlX9mDtS7hKsVtZ
	OPo7TH0evQCIYF81pLPMvgsf1krnl3UHy59biXdWR3dPcw25EsNzqzw6jqBgCkbH
	YioYcaOnW/lBkJI=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2
X-HELO: calimero.vinschen.de
Date: Wed, 8 Oct 2014 15:41:06 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Cannot exec() program outside of /bin if PATH is unset
Message-ID: <20141008134106.GF29235@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <5413271B DOT 1010109 AT t-online DOT de> <54134A83 DOT 80107 AT redhat DOT com> <54135451 DOT 3060902 AT t-online DOT de> <601154762 DOT 20140913012935 AT yandex DOT ru> <541378C4 DOT 6030705 AT t-online DOT de> <54137BDE DOT 6040907 AT redhat DOT com> <54137C7F DOT 1040507 AT redhat DOT com> <541415B1 DOT 8090500 AT t-online DOT de> <541698CC DOT 7090802 AT lysator DOT liu DOT se> <5416F946 DOT 7010905 AT t-online DOT de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="NGIwU0kFl1Z1A3An"
Content-Disposition: inline
In-Reply-To: <5416F946.7010905@t-online.de>
User-Agent: Mutt/1.5.23 (2014-03-12)

--NGIwU0kFl1Z1A3An
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sep 15 16:35, Christian Franke wrote:
> Peter Rosin wrote:
> >On 2014-09-13 12:00, Christian Franke wrote:
> >>Note that setting PATH=3D/bin on Cygwin does not fix the security probl=
em in the DLL search order. Even with "SafeDllSearchMode" enabled, the curr=
ent directory is always checked before PATH. Running some Cygwin program fr=
om /usr/sbin, /usr/local/bin, /usr/libexec, ... would load a possible malic=
ious cyg*.dll from current directory regardless of PATH setting. Only progr=
ams in /bin are safe.
> >>
> >>Using SetDllDirectory("c:\\cygwin\\bin") somewhere in cygwin1.dll would=
 fix this also.
> >How could a call inside a DLL fix the library search order used
> >to find that same DLL? Yes, it is possible (or likely) that
> >SetDllDirectory fixes the immediate problem for processes that
> >are started *by* cygwin1.dll, but it is not effective for Cygwin
> >processes that are started by some direct use of the Win32 API.
>=20
> Of course, and the same is true for any non-Cygwin program. The security =
fix
> is effective only for any CreateProcess()/LoadLibrary() call within the
> process which called SetDllDirectory(DIR_OF_SUBSYSTEM_DLLs).
>=20
>=20
> >Also, SetDllDirectory will kill all attempts to run 32-bit
> >Cygwin programs from 64-bit Cygwin (and vice versa).
>=20
> For programs in /bin directory, there is no problem because the EXE's
> directory is always searched first for required DLLs. SetDllDirectory() t=
hen
> has no effect for cyg*.dll search order.
>=20
> For other programs it also works because Windows (at least 7) apparently
> skips 32-bit DLLs when searching for 64-bit ones (and vice versa). It is
> then required that PATH contains the other Cygwin's /bin directory.
>=20
> Testcase for calling 64-bit from 32-bit:
>=20
> exe in /bin:
>=20
>   SetDllDirectory("c:\\cygwin\\bin");
>   unsetenv("PATH");
>   execl("/cygdrive/c/cygwin64/bin/uname", "uname", "-a", (const char*)0);
>=20
> exe not in /bin:
>=20
>   SetDllDirectory("c:\\cygwin\\bin");
>   setenv("PATH", "/cygdrive/c/cygwin64/bin", 1);
>   execl("/cygdrive/c/cygwin64/usr/sbin/alternatives", "alternatives", (co=
nst
> char*)0);
>=20
> In both cases, the SetDllDirectory() call does not break anything.

I'm somewhat reluctant to add a call to SetDllDirectory to the Cygwin
DLL for two reasons.

- Calling SetDllDirectory with an explicit dir doesn't just add this dir
  to the search path, it also removes the CWD from the search path.
  While I agree that this is a good thing from a security POV, can we be
  sure that this behaviour isn't needed somewhere, by somebody?

- The fact that SetDllDirectory affects searching linked DLLs in calls
  to CreateProcess is undocumented.  Per the original MSDN pages,
  SetDllDirectory affects calls to LoadLibrary and LoadLibraryEx, but
  not linked DLLs when starting a child process.  The latter is only
  mentioned in a Community Addition:

  http://msdn.microsoft.com/en-us/library/windows/desktop/ms686203%28v=3Dvs=
.85%29.aspx

Having said that, we can certainly test this, but I'm wondering
if an upstream Cygwin patch might be ok.  Something similar has been
applied to the portable OpenSSH repository years ago, so there's
precedent.


Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--NGIwU0kFl1Z1A3An
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUNT7yAAoJEPU2Bp2uRE+gzDkP/iOGNWZvsInG1AZOv7iKHk1V
7bnVpmuBNEChIWOv7m+fkvP3YM+o+6HiHiS0rBZXc8AuxF65/BVwTTTKVp47azYe
c3rP1mwdYkv+hW/RaEdOrOPxJxpwIfasGyzx457Z5oToOR2gZNcuuRnXaTYoDvDt
KONldjTpbMqfEyE5vlBKSiHbRN0ysRKADi6rETgkhd0DtjCXjKnV40RoPmY3ZrmH
1FmUujoPlBFo2ocnEGRGLkmWRWEWjmxOjBSJ3+CRwGlPS4iTSNBkp/d9OR1rYndf
pby7XcBq0UsuQ0sfDQwOJze9Mw66K63fs9f3uTlGov+fObuTY6XxlhY/pNCyVe3I
yQUuLsHyTZsNcfo0pw6x57aVvJXP3YOBSXcJtc/OjXVPUVpgvulhlVTE/KbLTA8S
mc8uKa8xGxV/l5dFARltzmRsjD8MOKkKMOkbpBnOJeQBPyG6/eAJ7aFXVUD2LbZL
MzoUy6jF59u1B7L0s0F8qe/ZtdiEMevYOvK/g4eR66FCbJ9XHOf6gLIpi2Qn7V8a
8Lc8fCokhxYSK2hArDGY6K3cdkaWmehp9sfVKERdBzecKhdGuqi7DwUbs9uPKOSS
lHBnLvFR2hKoaKLjOQyhkUjkysUi4O4pCLKjHJLHdeXormMD7gPPKlw6EE2FQnfK
Zhz4c8ttQo20gu7iCgxo
=AQhM
-----END PGP SIGNATURE-----

--NGIwU0kFl1Z1A3An--