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=ysKzXQEcvcGAhvIuO1JbnsyH5LiqdeKlaflq5bTbVKpj4VliI0HRa
	SThYtTdEU+vESlOgMH8uVpYpGylFOBazNZ5lCULp/itfhSV1E/MUzfncDk+91bWF
	rVpDJzrlbBOc3VLRkJxeGlnFqC7+NJk8yB9fojjE+kIh5Yz+dtX3KI=
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=kcpHLPB/5Vj98W11tDyyZEmcjYg=; b=jAmcoC2X5mpVjovM8GvO/J8Zagym
	Y4VIGZTCTQnbNBkzFUPtBE5GdiqBjKazsNFcu5bQxphCGwWgo52wofeFf7J7CZtj
	Zqyp6FWBwp/mc+dMku5xpIhpLdeHEzAP87rPzwgLEUdbty8DYK7WfGwFZytpC1bU
	Tz0VQ27xT7CBzvQ=
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=-93.9 required=5.0 tests=BAYES_50,KAM_LAZY_DOMAIN_SECURITY,KHOP_DYNAMIC,RCVD_IN_PBL,RDNS_DYNAMIC,USER_IN_WHITELIST autolearn=no version=3.3.2 spammy=Experience, x64, mitigation, catches
X-HELO:	calimero.vinschen.de
Date:	Fri, 29 Jan 2016 20:02:21 +0100
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: Re: sshd refuses connections since upgrade to 2.4.0-1
Message-ID:	<20160129190221.GA32735@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<trinity-e0c4c2ae-0b01-4f13-be63-dfdd7ec3ac4e-1454083511499 AT 3capp-gmx-bs05>
MIME-Version:	1.0
In-Reply-To:	<trinity-e0c4c2ae-0b01-4f13-be63-dfdd7ec3ac4e-1454083511499@3capp-gmx-bs05>
User-Agent:	Mutt/1.5.24 (2015-08-30)

--fUYQa+Pmc3FrFX/N
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Jan 29 17:05, Patrick Schmitt wrote:
> >> P.S. As can be seen from the strace I'm running Agnitum Outpost
> >> Firewall Pro and the current EMET - both has never been a problem with
> >> Cygwin's sshd (in this installation since May 2010).
> >
> >An "Access denied" error occurs, apparently in a Windows DLL while
> >loading Windows DLLs.  It's hard to tell what the reason is, but what
> >strikes me as weird is that the crash occurs right after this Agnitum
> >thingy has been injected into the process:
> >[...]
> >Did you try excluding sshd from the checks of that scanner?
>=20
> After some debugging and playing with different settings in
> Microsoft's Enhanced Mitigation Experience Toolkit
> ( https://technet.microsoft.com/de-de/security/jj653751 )
> I managed to determine the following as a "cause" for my sshd problems.
> My firewall (Agnitum Outpost Firewall Pro) does not play any role.
>=20
> With the current release version 5.2 of EMET on Win7SP1 x64 before
> cygwin1-20151203.dll: All mitigations except ASR (Attack Surface
> Reduction) could be used (ASR is not needed).
>=20
> Since cygwin1-20151203.dll:=20
> The following mitigations must be disabled for sshd to allow connections:
> * EAF+ (Export Address Table Access Filtering Plus)
> * Stack Pivot
> But getting a shell still fails (connection closes before shell starts
> ?!).  For fully working sshd additionally the following mitigation
> must also be disabled:
> * Sim Exec Flow (ROP Mitigation)
>=20
> The question is what changes/new codepaths in cygwin1.dll trigger the
> three mitigations mentioned above since 20151203 ?

Well, I have no idea.  Cygwin is not doing anything weird (unless you
think everything Cygwin is doing to emulate a POSIX environment on
Windows is weird).  I took a quick glance over the changes between 11/29
and 12/03 and nothing catches my attention.  In fact, part of the
changes try to clean up code, e.g., using NtCurrentTeb() rather than
direct calls to "%fs:4" etc when accessing the TEB.  A lot of other
changes were only affecting 64 bit Cygwin (e.g., moving the main thread
stack to a Cygwin-defined address)

If you want to find out, feel free to use git blame on the Cygwin
sources.  But dependent on the outcome I give no guarantee that this can
be changed back.  You might want to excempt the Cygwin DLL from the
scanner if the scanner is not grok'ing that Cygwin is doing nothing bad.


Corinna

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

--fUYQa+Pmc3FrFX/N
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWq7c9AAoJEPU2Bp2uRE+gfYIP/imHMXK5LW+JnvDyjZ1dMasi
0VMkV9j+jBUJO2YSzVIBpXhybI5z39HsAJ2BvpbANS8uxa5R+w5buQxc8oRFuHX8
aNa4bF6tpIfypqnBXzsdG1F9LpWzNm59NSGDfPQRZt+7f/grEER+tWPq8PTvl8Ao
CXQIxc3S/QiMTC4FchC7Aua/YWody2HCqFNFAeFNcnGDSzW0YimyFdNagjVhHnHW
+nfvDhSTGI9wsCf2qmORSVuXiPr9Fr8XBoJcBiXts9kspbYHv4n1Tvn6wdPlGdZf
tIRlMr6YRVgQQmvj/kKJxCE7vGWm+H8ORtrxjJb64OQ/3hU48c3+2MYZSl/QAxQG
N/ov6nOOfUk0iDCUJs3AYlQ8vdredKNH6LRwi4gZJCovMYsxlFdzVzaEiajBMi2v
6M3P2bnQ3G5E1daleQ+uI3lfG1cBe+ajiLIaJbgj2QyeZockb1/JT8Y0tt0PlBw2
lasEH7n1oHa6Vsx/Jc/OtmiKWpT9/fkgUKD+UTKpoC3/OHY68gzuUpgF4HBsDoaL
qav5H7YcPGAHuOudgStjqH+hbiEgGy4IwEbiJy7K43H7wOizghEBHHNu0ux4OPd9
zVAgikWYmt+ygzmUgj9I7YeSYMXKR3KUehWoKcVUxQ8mxmBMELqmGDDKSDksFMO3
YvZwD13LMW1TlHTJdNk0
=yMeH
-----END PGP SIGNATURE-----

--fUYQa+Pmc3FrFX/N--

- Raw text -