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?
> 
> 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.
> 
> 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).
> 
> Since cygwin1-20151203.dll: 
> 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)
> 
> 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

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