Re: Re: sshd refuses connections since upgrade to 2.4.0-1

Re: Re: sshd refuses connections since upgrade to 2.4.0-1

[Patrick Schmitt]

>> Hi!
>> 
>> Long time Cygwin user but first time error reporter to this mailing list.
>> Since upgrading my 32-bit Cygwin installation on Win7SP1 x64 from
>> 2.3.1-1 to the current 2.4.0-1 (and also 2.5.0-0.1 in my despair) I
>> can't connect to sshd running as a service anymore.
>> The service starts and spawns a child in order to handle the
>> connection request, but that fails even when connecting from
>> localhost.
>> I triaged the problem by trying snapshots between the two releases and
>> traced it to a change after 20151129:
>> cygwin1-20151129.dll works
>> cygwin1-20151203.dll fails
>> 
>> The sshd.log remains empty.
>> In order to create more information to go on I ran strace on the
>> parent (cyg_server spawned) sshd and tried to connect, the strace-log
>> (sshd_cygwin2.4.0_20160109) is attached together with a slightly
>> redacted cygcheck.out
>> 
>> Thanks for looking into this!
>> 
>> 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:
>
>--- Process 17828 loaded C:\PROGRA~1\Agnitum\OUTPOS~1\wl_hook.dll at 10000000
>--- Process 17828 unloaded DLL at 10000000
>--- Process 17828 loaded C:\PROGRA~1\Agnitum\OUTPOS~1\wl_hook.dll at 01280000
>--- Process 17828 loaded C:\Windows\SysWOW64\shell32.dll at 762F0000
>--- Process 17828 loaded C:\Windows\SysWOW64\shlwapi.dll at 75DE0000
>--- Process 17828 thread 18284 exited with status 0xc0000022
>--- Process 17828 thread 18412 exited with status 0xc0000022
>--- Process 17828 thread 17624 exited with status 0xc0000022
>--- Process 17828 exited with status 0xc0000022
>154769 11583429 [waitproc] sshd 8404 pinfo::status_exit: *** STATUS_0xC0000022
>
>Did you try excluding sshd from the checks of that scanner?
>
>
>Corinna
>

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 ?

I would assume especially users in enterprise environments might suffer this "problem"...


P.S. I'm sorry for breaking threading, but apparently my freemail provider (gmx.net) does not allow sending email to addresses longer than 60 characters. 
The subscription confirmation addresses for the list (ezmlm) are at least in my case longer than that (here 88 chars) :(

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Re: sshd refuses connections since upgrade to 2.4.0-1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2611 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: sshd refuses connections since upgrade to 2.4.0-1

[Achim Gratz]

Patrick Schmitt writes:
> P.S. I'm sorry for breaking threading, but apparently my freemail
> provider (gmx.net) does not allow sending email to addresses longer
> than 60 characters.  The subscription confirmation addresses for the
> list (ezmlm) are at least in my case longer than that (here 88 chars)
> :(

Then use gmane.org already.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple