another question about cygwin bash trying to make connections

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

another question about cygwin bash trying to make connections

LMHmedchem2
Hello,

Every single time run bash in a terminal, I get the following firewall alerts,

C:\cygwin\bin\bash.exe
An attempt to communicate a foreign process has been detected.
Target PID: 1616
Image Name: svchost.exe

C:\cygwin\bin\bash.exe
A potential threat to network traffic interception or injection has been detected.

This is when running a script that invokes bash with the shebang. The same thing
happens if I just run bash with no arguments. On every run of bash, bash tries to IPC
with svchost.exe. The second alert for network traffic injection suggests that
bash.exe is attempting to use svchost to make a network connection. This is common
enough since svchost.exe has unfiltered network connection permission on most systems
(stupid in my opinion).

I have looked in all of the versions of .bashrc and .bash_profile and don't see
anything there that looks relevant. I presume that bash is trying to do something
like check to see if it needs to be updated. In that case, I have never understood
why bash.exe needs to try to connect through another process instead of just making
the connection itself. If this is something else, well, who knows.

The attempted IPC is entirely unnecessary as blocking both alerts has no effect
whatsoever.

How should I go about trying to run this down? I can just create the rule to
permanently block the IPC and network traffic injection, but I would prefer to stop
the connection attempt from what is triggering it. That would allow me to see new
alerts if it happens again.

This is the version of bash,

GNU bash, version 4.3.42(4)-release (i686-pc-cygwin)

it would be very helpful as a first step if I could find a verified digital signature
for this version of bash. The index here,

https://ftp.gnu.org/gnu/bash/

gives an archive of bash with a signature for each tar.gz but not the signature for
each version of the extracted binary.

Thanks,

LMH

--
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

Reply | Threaded
Open this post in threaded view
|

Re: another question about cygwin bash trying to make connections

marco atzeri-4
Am 07.01.2020 um 21:58 schrieb LMH:

> Hello,
>
>
> This is the version of bash,
>
> GNU bash, version 4.3.42(4)-release (i686-pc-cygwin)
>
> it would be very helpful as a first step if I could find a verified digital signature
> for this version of bash. The index here,
>
> https://ftp.gnu.org/gnu/bash/
>
> gives an archive of bash with a signature for each tar.gz but not the signature for
> each version of the extracted binary.
>
> Thanks,
>

that is not the last version of bash, so I guess your system is not
updated anyway


$ bash --version
GNU bash, version 4.4.12(3)-release (i686-pc-cygwin)

--
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

Reply | Threaded
Open this post in threaded view
|

Re: another question about cygwin bash trying to make connections

LMHmedchem2
Marco Atzeri wrote:

> Am 07.01.2020 um 21:58 schrieb LMH:
>> Hello,
>>
>>
>> This is the version of bash,
>>
>> GNU bash, version 4.3.42(4)-release (i686-pc-cygwin)
>>
>> it would be very helpful as a first step if I could find a verified digital signature
>> for this version of bash. The index here,
>>
>> https://ftp.gnu.org/gnu/bash/
>>
>> gives an archive of bash with a signature for each tar.gz but not the signature for
>> each version of the extracted binary.
>>
>> Thanks,
>>
>
> that is not the last version of bash, so I guess your system is not updated anyway
>
>
> $ bash --version
> GNU bash, version 4.4.12(3)-release (i686-pc-cygwin)
>
> --
> 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
>
>

No, this is an older system that I keep around to run and test XP software on. It has
the latest version of cygwin that still supports XP (2.874). This system isn't on the
internet very often.

It is still of interest to me to understand how the components of cywgin work and
what controls such things as how and why IPC may be triggered. This is especially
true when I see behavior that doesn't make sense to me. I don't see any reason why
bash should need to communicate with svchost every time it is run, especially where
blocking that communication has no discernible effect.

If this is evidence of a system problem somewhere, I of course would like to know
about that as well.

LMH










--
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

Reply | Threaded
Open this post in threaded view
|

Re: another question about cygwin bash trying to make connections

Brian Inglis
On 2020-01-07 16:02, LMH wrote:

> Marco Atzeri wrote:
>> Am 07.01.2020 um 21:58 schrieb LMH:
>>> This is the version of bash,
>>>
>>> GNU bash, version 4.3.42(4)-release (i686-pc-cygwin)
>>>
>>> it would be very helpful as a first step if I could find a verified
>>> digital signature for this version of bash. The index here,
>>>
>>> https://ftp.gnu.org/gnu/bash/
>>>
>>> gives an archive of bash with a signature for each tar.gz but not the
>>> signature for each version of the extracted binary.

GNU packages are source only and GNU does not distribute binaries. Some GNU
maintainers may make binaries available from their own personal systems.

Binaries are built for each platform with some compiler version that runs on
that platform, so each binary for each platform, compiler, and compilation run
has a different digital signature, as each compilation run typically injects
time stamps and other run-dependent data, especially with included debug info.

The reproducible build movement is trying to reduce and eliminate those
variations for easier binary validation and verification, but requires tool
chains which support suppression of all info not strictly dependent on the
source code, compiler, tools, and platform versions.

Each source package is typically packaged with components for that platform
package, so the best you can do is probably check the signature of the original
GNU bash source package against the copy included verbatim in the Cygwin source
package as the build base; the hashes of the downloaded Cygwin bash source and
binary packages against those in your latest downloaded setup.ini or the
x86{,_64}/release/bash/sha512.sum file on your local mirror or the sourceware
mirror; and the signature of x86{,_64}/setup.ini in x86{,_64}/setup.ini.sig on
your local mirror or the sourceware mirror.

>> that is not the last version of bash, so I guess your system is not
>> updated anyway
>>
>> $ bash --version
>> GNU bash, version 4.4.12(3)-release (i686-pc-cygwin)

> No, this is an older system that I keep around to run and test XP software
> on. It has the latest version of cygwin that still supports XP (2.874). This
> system isn't on the internet very often.
>
> It is still of interest to me to understand how the components of cywgin
> work and what controls such things as how and why IPC may be triggered. This
> is especially true when I see behavior that doesn't make sense to me. I
> don't see any reason why bash should need to communicate with svchost every
> time it is run, especially where blocking that communication has no
> discernible effect.
>
> If this is evidence of a system problem somewhere, I of course would like to
> know about that as well.

If you are or appear to be on a domain, any Cygwin access to user and some other
info may invoke a Windows call which accesses the domain controller.

On newer systems, if you have not disabled Windows usage monitoring, data
collection, and submission to MicroSoft, or have any MicroSoft accounts instead
of local accounts, any Windows call may access MicroSoft domain systems.

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

--
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