This is the mail archive of the
mailing list for the Cygwin project.
Re: Re: sshd refuses connections since upgrade to 2.4.0-1
- From: "Patrick Schmitt" <p dot r dot schmitt at gmx dot de>
- To: cygwin at cygwin dot com
- Date: Fri, 29 Jan 2016 17:05:11 +0100
- Subject: Re: Re: sshd refuses connections since upgrade to 2.4.0-1
- Authentication-results: sourceware.org; auth=none
- Sensitivity: Normal
>> 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
>> 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?
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).
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
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple