BLODA detection code in latest snapshot

BLODA detection code in latest snapshot

[Corinna Vinschen]

Hi folks,


I've just uploaded a new snapshot "2012-02-27 12:04:23 UTC".  It
contains two code snippets which are supposed to help diagnosing BLODA
problems.

If you set the environment variable CYGWIN to "detect_bloda" and then
start a Cygwin process (bash or so), then Cygwin will detect two types
of anomalies:

- Threads injected into the process from an unknown source.

  Every thread started in a process triggers a message to the DLLs
  in a process.  When the Cygwin DLL gets this message, it tweaks
  the function pointer of the thread entry point so that it points to
  a Cygwin function.  Usually Cygwin just performs some setup and
  then starts the original thread function.

  If CYGWIN=detect_bloda, then the original function address is
  evaluated and if the address is neither in the Cygwin DLL, nor in
  the application image, nor in one of a few filtered system DLLs,
  then Cygwin prints a message like this:

    Potential BLODA detected!  Thread function called outside of Cygwin DLL:
      C:\foo\bar\baz.dll

  Of course this is not foolproof.  The only filtered system DLLs so
  far are kernel32.dll, ntdll.dll, mswsock.dll, amd ws2_32.dll.  If you
  playing around with this, and if you find that a core system DLL is
  reported (like, say, advapi32.dll), then please notify this list, too.

- Some BLODAs affect the network.  Winsock allows so-called "Layered
  Service Providers" (LSP).  The socket handle returned by a socket(2)
  call is not a real socket, but a pseudo handle returned by the LSP.
  While Cygwin tries to workaround this, it's nevertheless interesting
  to learn that an LSP is installed.
  
  For instance, there's the "Bytemobile optimization client" on our
  BLODA list at http://cygwin.com/faq/faq.using.html#faq.using.bloda
  If this is installed on your machine, and if you have CYGWIN=detect_bloda
  set, it's existence will be recognized twice when you try to open a
  socket connection.  First it injects a thread into the application, so
  you'll see something like this:

    Potential BLODA detected!  Thread function called outside of Cygwin DLL:
      C:\Windows\System32\bmnet.dll

  And additionally you'll see this:

    Potential BLODA detected!  Layered Socket Service Provider:
      BMA over MSAFD Tcpip [TCP/IP]

Please note that this new CYGWIN=detect_bloda setting is just for
diagnosing BLODA problems.  It's no swiss army knife to fix the BLODA
problems, but it might help to detect the cause for some of them.

Of course I'd be interested in your experience with this and in any
BLODA message you get by setting CYGWIN=detect_bloda.


Corinna

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

--
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: BLODA detection code in latest snapshot

[Larry Hall (Cygwin)]

On 2/27/2012 7:26 AM, Corinna Vinschen wrote:
> Hi folks,
>
>
> I've just uploaded a new snapshot "2012-02-27 12:04:23 UTC".  It
> contains two code snippets which are supposed to help diagnosing BLODA
> problems.

Very cool.  Thanks Corinna!


-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
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: BLODA detection code in latest snapshot

[David Rothenberger]

On 2/27/2012 4:26 AM, Corinna Vinschen wrote:
>   Of course this is not foolproof.  The only filtered system DLLs so
>   far are kernel32.dll, ntdll.dll, mswsock.dll, amd ws2_32.dll.  If you
>   playing around with this, and if you find that a core system DLL is
>   reported (like, say, advapi32.dll), then please notify this list, too.

On one of my Windows XP 32 boxes, it is reporting

Potential BLODA detected!  Thread function called outside of Cygwin DLL:
  C:\WINDOWS\system32\advapi32.dll

when I ssh to another host. The machine DOES have potential BLODA,
though: Symantec Endpoint Protection. It's never caused me any problems.

You did say above to report to the list if advapi32.dll is reported, and
you didn't say not to report it if there is helpful anti-workright
software on the machine, so, here's your report. Forgive me if I
misunderstood.

-- 
David Rothenberger  ----  daveroth@acm.org

Small things make base men proud.
                -- William Shakespeare, "Henry VI"

--
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: BLODA detection code in latest snapshot

[David Rothenberger]

On 2/27/2012 6:53 PM, David Rothenberger wrote:
> On 2/27/2012 4:26 AM, Corinna Vinschen wrote:
>>   Of course this is not foolproof.  The only filtered system DLLs so
>>   far are kernel32.dll, ntdll.dll, mswsock.dll, amd ws2_32.dll.  If you
>>   playing around with this, and if you find that a core system DLL is
>>   reported (like, say, advapi32.dll), then please notify this list, too.
> 
> On one of my Windows XP 32 boxes, it is reporting
> 
> Potential BLODA detected!  Thread function called outside of Cygwin DLL:
>   C:\WINDOWS\system32\advapi32.dll
> 
> when I ssh to another host. The machine DOES have potential BLODA,
> though: Symantec Endpoint Protection. It's never caused me any problems.
> 
> You did say above to report to the list if advapi32.dll is reported, and
> you didn't say not to report it if there is helpful anti-workright
> software on the machine, so, here's your report. Forgive me if I
> misunderstood.

Here's another one, this time on a Win7-64 machine:

Potential BLODA detected!  Thread function called outside of Cygwin DLL:
  C:\Windows\syswow64\SHLWAPI.dll

I get this when running

% cygstart --hide "$(cygpath -W)/sysnative/msg" $USER test

There's no BLODA on this machine.

-- 
David Rothenberger  ----  daveroth@acm.org

Adler's Distinction:
        Language is all that separates us from the lower animals,
        and from the bureaucrats.

--
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: BLODA detection code in latest snapshot

[Corinna Vinschen]

On Feb 27 18:53, David Rothenberger wrote:
> On 2/27/2012 4:26 AM, Corinna Vinschen wrote:
> >   Of course this is not foolproof.  The only filtered system DLLs so
> >   far are kernel32.dll, ntdll.dll, mswsock.dll, amd ws2_32.dll.  If you
> >   playing around with this, and if you find that a core system DLL is
> >   reported (like, say, advapi32.dll), then please notify this list, too.
> 
> On one of my Windows XP 32 boxes, it is reporting
> 
> Potential BLODA detected!  Thread function called outside of Cygwin DLL:
>   C:\WINDOWS\system32\advapi32.dll
> 
> when I ssh to another host. The machine DOES have potential BLODA,
> though: Symantec Endpoint Protection. It's never caused me any problems.

Weird!  I can't reproduce this on my XP box so I have to assume
this is a result of SEPs influence.  Hmm.  That's a bit disappointing.
How on earth can SEP call a thread function in advapi32?  I don't
think any of them are documented...

> you didn't say not to report it if there is helpful anti-workright
> software on the machine, so, here's your report. Forgive me if I
> misunderstood.

Oh.  In my last paragraph I wrote:

>> Of course I'd be interested in your experience with this and in any
>> BLODA message you get by setting CYGWIN=detect_bloda.

Sorry if that wasn't clear enough.


Corinna

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

--
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: BLODA detection code in latest snapshot

[Corinna Vinschen]

On Feb 27 20:02, David Rothenberger wrote:
> On 2/27/2012 6:53 PM, David Rothenberger wrote:
> > On 2/27/2012 4:26 AM, Corinna Vinschen wrote:
> >>   Of course this is not foolproof.  The only filtered system DLLs so
> >>   far are kernel32.dll, ntdll.dll, mswsock.dll, amd ws2_32.dll.  If you
> >>   playing around with this, and if you find that a core system DLL is
> >>   reported (like, say, advapi32.dll), then please notify this list, too.
> > 
> > On one of my Windows XP 32 boxes, it is reporting
> > 
> > Potential BLODA detected!  Thread function called outside of Cygwin DLL:
> >   C:\WINDOWS\system32\advapi32.dll
> > 
> > when I ssh to another host. The machine DOES have potential BLODA,
> > though: Symantec Endpoint Protection. It's never caused me any problems.
> > 
> > You did say above to report to the list if advapi32.dll is reported, and
> > you didn't say not to report it if there is helpful anti-workright
> > software on the machine, so, here's your report. Forgive me if I
> > misunderstood.
> 
> Here's another one, this time on a Win7-64 machine:
> 
> Potential BLODA detected!  Thread function called outside of Cygwin DLL:
>   C:\Windows\syswow64\SHLWAPI.dll
> 
> I get this when running
> 
> % cygstart --hide "$(cygpath -W)/sysnative/msg" $USER test

Yup, confirmed.  This occurs on W7/32 as well.  I add shlwapi to the
list of filtered DLLs for which no such message is printed.


Thanks,
Corinna

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

--
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: BLODA detection code in latest snapshot

[Andrey Repin]

Greetings, Corinna Vinschen!

> Yup, confirmed.  This occurs on W7/32 as well.
> I add shlwapi to the list of filtered DLLs for which no such message is printed.

Could you please consider making such list configurable, if it's not much of
an issue?
This feature seems to be the reasonable way for rough detection of potentially
malicious presence, but I would like to avoid certain handlers to be reported,
such as antivirus' LSP or keyboard hotkey handler.


--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 29.02.2012, <02:36>

Sorry for my terrible english...


--
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: BLODA detection code in latest snapshot

[Corinna Vinschen]

On Feb 29 02:41, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
> 
> > Yup, confirmed.  This occurs on W7/32 as well.
> > I add shlwapi to the list of filtered DLLs for which no such message is printed.
> 
> Could you please consider making such list configurable, if it's not much of
> an issue?
> This feature seems to be the reasonable way for rough detection of potentially
> malicious presence, but I would like to avoid certain handlers to be reported,
> such as antivirus' LSP or keyboard hotkey handler.

Hmm.  Well, this option isn't meant to be used all the time.  It's not
overly intrusive, but it costs time and Cygwin already isn't exactly
fast.  For a pure diagnosing tool, does it makes sense to add lots
of configuration options?

If you want to make the DLL list configurable, what's your idea?  Another
env var like, say CYGWIN_DETECT_BLODA_DLL_IGNORE_LIST?


Corinna

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

--
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: BLODA detection code in latest snapshot

[Andrey Repin]

Greetings, Corinna Vinschen!

>> > Yup, confirmed.  This occurs on W7/32 as well.
>> > I add shlwapi to the list of filtered DLLs for which no such message is printed.
>> 
>> Could you please consider making such list configurable, if it's not much of
>> an issue?
>> This feature seems to be the reasonable way for rough detection of potentially
>> malicious presence, but I would like to avoid certain handlers to be reported,
>> such as antivirus' LSP or keyboard hotkey handler.

> Hmm.  Well, this option isn't meant to be used all the time.  It's not
> overly intrusive, but it costs time and Cygwin already isn't exactly
> fast.  For a pure diagnosing tool, does it makes sense to add lots
> of configuration options?

No, it doesn't. I've asked "just in cause" :)

> If you want to make the DLL list configurable, what's your idea?  Another
> env var like, say CYGWIN_DETECT_BLODA_DLL_IGNORE_LIST?

Registry key (REG_MULTI_SZ) would be better.
Speaking of which (a list of potentially intrusive DLL's) - do you filter by
DLL name or it's full path?
Because, %SystemRoot%\system32\shlwapi.dll is likely to be harmless.
But same name DLL inserted from any other place...


--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 29.02.2012, <16:09>

Sorry for my terrible english...


--
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: BLODA detection code in latest snapshot

[Ryan Johnson]

On 29/02/2012 7:22 AM, Andrey Repin wrote:
> do you filter by DLL name or it's full path?
> Because, %SystemRoot%\system32\shlwapi.dll is likely to be harmless.
> But same name DLL inserted from any other place...
That would be moving beyond mere BLODA and into malware territory. At 
that point, just because it's in %SystemRoot% doesn't mean it's safe, 
either. In fact, we can't really even be sure a well-known dll name in 
%SystemRoot% is safe if the machine is infected with something.

I don't think we're trying to play virus scanner here, so dll name 
should suffice.

$.02
Ryan


--
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: BLODA detection code in latest snapshot

[Ryan Johnson]

On 27/02/2012 7:26 AM, Corinna Vinschen wrote:
> Hi folks,
>
>
> I've just uploaded a new snapshot "2012-02-27 12:04:23 UTC".  It
> contains two code snippets which are supposed to help diagnosing BLODA
> problems.
>
> If you set the environment variable CYGWIN to "detect_bloda" and then
> start a Cygwin process (bash or so), then Cygwin will detect two types
> of anomalies:
>
> - Threads injected into the process from an unknown source.
>
>    Every thread started in a process triggers a message to the DLLs
>    in a process.  When the Cygwin DLL gets this message, it tweaks
>    the function pointer of the thread entry point so that it points to
>    a Cygwin function.  Usually Cygwin just performs some setup and
>    then starts the original thread function.
>
>    If CYGWIN=detect_bloda, then the original function address is
>    evaluated and if the address is neither in the Cygwin DLL, nor in
>    the application image, nor in one of a few filtered system DLLs,
>    then Cygwin prints a message like this:
>
>      Potential BLODA detected!  Thread function called outside of Cygwin DLL:
>        C:\foo\bar\baz.dll
>
>    Of course this is not foolproof.  The only filtered system DLLs so
>    far are kernel32.dll, ntdll.dll, mswsock.dll, amd ws2_32.dll.  If you
>    playing around with this, and if you find that a core system DLL is
>    reported (like, say, advapi32.dll), then please notify this list, too.
>
> - Some BLODAs affect the network.  Winsock allows so-called "Layered
>    Service Providers" (LSP).  The socket handle returned by a socket(2)
>    call is not a real socket, but a pseudo handle returned by the LSP.
>    While Cygwin tries to workaround this, it's nevertheless interesting
>    to learn that an LSP is installed.
>
>    For instance, there's the "Bytemobile optimization client" on our
>    BLODA list at http://cygwin.com/faq/faq.using.html#faq.using.bloda
>    If this is installed on your machine, and if you have CYGWIN=detect_bloda
>    set, it's existence will be recognized twice when you try to open a
>    socket connection.  First it injects a thread into the application, so
>    you'll see something like this:
>
>      Potential BLODA detected!  Thread function called outside of Cygwin DLL:
>        C:\Windows\System32\bmnet.dll
>
>    And additionally you'll see this:
>
>      Potential BLODA detected!  Layered Socket Service Provider:
>        BMA over MSAFD Tcpip [TCP/IP]
>
> Please note that this new CYGWIN=detect_bloda setting is just for
> diagnosing BLODA problems.  It's no swiss army knife to fix the BLODA
> problems, but it might help to detect the cause for some of them.
>
> Of course I'd be interested in your experience with this and in any
> BLODA message you get by setting CYGWIN=detect_bloda.
Would it be a good idea to update the FAQ's bloda entry with this info? 
Sure, it's probably going to give occasional false positives and/or 
negatives, but it would definitely catch the obvious cases and give a 
quick test for claims of bloda-free systems. You'd almost want a new 
cygcheck -b option that could fork off a process or two with 
detect_bloda active and capture any output that results.

Ryan

--
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: BLODA detection code in latest snapshot

[Corinna Vinschen]

On Feb 29 09:51, Ryan Johnson wrote:
> On 27/02/2012 7:26 AM, Corinna Vinschen wrote:
> >Hi folks,
> >
> >
> >I've just uploaded a new snapshot "2012-02-27 12:04:23 UTC".  It
> >contains two code snippets which are supposed to help diagnosing BLODA
> >problems.
> >
> >If you set the environment variable CYGWIN to "detect_bloda" and then
> >start a Cygwin process (bash or so), then Cygwin will detect two types
> >of anomalies:
> >[...]
> Would it be a good idea to update the FAQ's bloda entry with this
> info? Sure, it's probably going to give occasional false positives
> and/or negatives, but it would definitely catch the obvious cases
> and give a quick test for claims of bloda-free systems. You'd almost
> want a new cygcheck -b option that could fork off a process or two
> with detect_bloda active and capture any output that results.

Of course I will document this at one point.  So far I just didn't.
I doubt that the cygcheck -b would be useful, though.  Just call

  $ export CYGWIN=detect_bloda some_executable

and you get what you want.


Corinna

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

--
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: BLODA detection code in latest snapshot

[Ryan Johnson]

On 29/02/2012 10:01 AM, Corinna Vinschen wrote:
> On Feb 29 09:51, Ryan Johnson wrote:
>> On 27/02/2012 7:26 AM, Corinna Vinschen wrote:
>>> Hi folks,
>>>
>>>
>>> I've just uploaded a new snapshot "2012-02-27 12:04:23 UTC".  It
>>> contains two code snippets which are supposed to help diagnosing BLODA
>>> problems.
>>>
>>> If you set the environment variable CYGWIN to "detect_bloda" and then
>>> start a Cygwin process (bash or so), then Cygwin will detect two types
>>> of anomalies:
>>> [...]
>> Would it be a good idea to update the FAQ's bloda entry with this
>> info? Sure, it's probably going to give occasional false positives
>> and/or negatives, but it would definitely catch the obvious cases
>> and give a quick test for claims of bloda-free systems. You'd almost
>> want a new cygcheck -b option that could fork off a process or two
>> with detect_bloda active and capture any output that results.
> Of course I will document this at one point.  So far I just didn't.
> I doubt that the cygcheck -b would be useful, though.  Just call
>
>    $ export CYGWIN=detect_bloda some_executable
>
> and you get what you want.
Sure. That's what I'd do also, but we're both familiar with the bloda. I 
was thinking more of users sending problem reports. Telling them to 
attach the output of `cygcheck -svrb' would give us useful information 
even if they don't (yet) know what the bloda is let alone whether 
they're affected by it.  Sort of like how we could ask users having 
strange problems to check for a second cygwin1.dll in their path... but 
it's easier to just ask for cygcheck output and check that. As a bonus, 
it would catch times where someone (*cough* me *cough*) thinks they're 
bloda free and so doesn't check for it before reporting a problem.

Heck, if we really wanted to go whole-hog, we could add an option to 
check for dlls in $PATH that have base collisions. Once cygcheck 
supported both those checks, the fork failure error message could even 
tell users to run cygcheck before reporting a problem.

Actually, now that I think about it, we could just make cygwin list any 
base collisions among dlls used by a failed forkee and point to the FAQ 
entry on rebaseall. The info is at our fingertips (dll::preferred_base) 
and in the absence of base collisions we could spawn a process to check 
for bloda, whose output (if non-empty) is highly likely to be relevant. 
The latency of a single spawn is nothing compared to ten failed fork 
attempts, so it wouldn't make cygwin any slower. Between those two 
checks, an intelligent user could deal with the vast majority of fork 
failures without ever invoking the mailing list. No change to cygcheck 
needed at that point.

Of course, SHTDI and I won't be able to until the semester ends, but it 
should be just a few hours' work.

Ryan

--
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: BLODA detection code in latest snapshot

[Corinna Vinschen]

On Feb 29 11:06, Ryan Johnson wrote:
> On 29/02/2012 10:01 AM, Corinna Vinschen wrote:
> >On Feb 29 09:51, Ryan Johnson wrote:
> >>On 27/02/2012 7:26 AM, Corinna Vinschen wrote:
> >>>Hi folks,
> >>>
> >>>
> >>>I've just uploaded a new snapshot "2012-02-27 12:04:23 UTC".  It
> >>>contains two code snippets which are supposed to help diagnosing BLODA
> >>>problems.
> >>>
> >>>If you set the environment variable CYGWIN to "detect_bloda" and then
> >>>start a Cygwin process (bash or so), then Cygwin will detect two types
> >>>of anomalies:
> >>>[...]
> >>Would it be a good idea to update the FAQ's bloda entry with this
> >>info? Sure, it's probably going to give occasional false positives
> >>and/or negatives, but it would definitely catch the obvious cases
> >>and give a quick test for claims of bloda-free systems. You'd almost
> >>want a new cygcheck -b option that could fork off a process or two
> >>with detect_bloda active and capture any output that results.
> >Of course I will document this at one point.  So far I just didn't.
> >I doubt that the cygcheck -b would be useful, though.  Just call
> >
> >   $ export CYGWIN=detect_bloda some_executable
> >
> >and you get what you want.
> Sure. That's what I'd do also, but we're both familiar with the
> bloda. I was thinking more of users sending problem reports. Telling
> them to attach the output of `cygcheck -svrb' would give us useful
> information even if they don't (yet) know what the bloda is let
> alone whether they're affected by it.  Sort of like how we could ask

cygcheck already starts the `id' command.  We could start it with
the CYGWIN=detect_bloda setting.  But I don't think that's feasible.
The problem is, what application would you like to start, and what
would you like to do to trigger BLODA messages?

when I implemented this I didn't implement the DLL filter list at first.
I ran my first tests on W7.  I have one machine on which I have the
installer for a known BLODA, the Bytemobile stuff, but otherwise my
machines are rather stock OS + Cygwin.  So it came as a surprise to me
when the following happened:

I started bash with CYGWIN=detect_bloda, typed `ls' to see if it works
and then shifted my attention to something else.  After about 30
seconds, I got the follwoing message in bash, three times in a row:

  Potential BLODA detected!  Thread function "called outside of Cygwin DLL:
    C:\Windows\System32\ntdll.dll

I observed this more closely and it turned out that for each foreground
process which lived longer than about 30 seconds a thread function in
ntdll.dll was started three times in parallel.  After pretty much exactly
1 minute, all three threads disappeared again.

What I'm trying to say with this example is,  you just don't know what
a potential BLODA will do.  You don't know when it will intrude, nor
do you know what you have to do so that it intrudes.  Maybe it only
occurs when you press a key or open a socket connection, or only if
you move your mouse out of the Window, or if you perform a rain dance.

I don't think you have the faintest chance to catch BLODAs
automatically, other than by enhancing the BLODA tests for known BLODAs
in cygcheck.  That's what would be most helpful in the long run.  The
BLODA test in Cygwin is just a last straw sort of thing.  At least in
its current implementation.

> Heck, if we really wanted to go whole-hog, we could add an option to
> check for dlls in $PATH that have base collisions. Once cygcheck
> supported both those checks, the fork failure error message could
> even tell users to run cygcheck before reporting a problem.

To find base collisions it would be most helpful to run rebase with
the -i option.  We could add code to cygcheck to call rebase -i.

> Actually, now that I think about it, we could just make cygwin list
> any base collisions among dlls used by a failed forkee and point to
> the FAQ entry on rebaseall. The info is at our fingertips
> (dll::preferred_base) and in the absence of base collisions we could
> spawn a process to check for bloda, whose output (if non-empty) is
  ^^^^^^^^^^^^^^^
  Oh no, please don't.  The Cygwin DLL should not start applcations
  by itself.  That sounds like a potential security hole.


Corinna

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

--
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: BLODA detection code in latest snapshot

[Ryan Johnson]

On 01/03/2012 4:53 AM, Corinna Vinschen wrote:
> On Feb 29 11:06, Ryan Johnson wrote:
>> On 29/02/2012 10:01 AM, Corinna Vinschen wrote:
>>> On Feb 29 09:51, Ryan Johnson wrote:
>>>> On 27/02/2012 7:26 AM, Corinna Vinschen wrote:
>>>>> Hi folks,
>>>>>
>>>>>
>>>>> I've just uploaded a new snapshot "2012-02-27 12:04:23 UTC".  It
>>>>> contains two code snippets which are supposed to help diagnosing BLODA
>>>>> problems.
>>>>>
>>>>> If you set the environment variable CYGWIN to "detect_bloda" and then
>>>>> start a Cygwin process (bash or so), then Cygwin will detect two types
>>>>> of anomalies:
>>>>> [...]
>>>> Would it be a good idea to update the FAQ's bloda entry with this
>>>> info? Sure, it's probably going to give occasional false positives
>>>> and/or negatives, but it would definitely catch the obvious cases
>>>> and give a quick test for claims of bloda-free systems. You'd almost
>>>> want a new cygcheck -b option that could fork off a process or two
>>>> with detect_bloda active and capture any output that results.
>>> Of course I will document this at one point.  So far I just didn't.
>>> I doubt that the cygcheck -b would be useful, though.  Just call
>>>
>>>    $ export CYGWIN=detect_bloda some_executable
>>>
>>> and you get what you want.
>> Sure. That's what I'd do also, but we're both familiar with the
>> bloda. I was thinking more of users sending problem reports. Telling
>> them to attach the output of `cygcheck -svrb' would give us useful
>> information even if they don't (yet) know what the bloda is let
>> alone whether they're affected by it.  Sort of like how we could ask
> [bloda horror stories]
>
> What I'm trying to say with this example is,  you just don't know what
> a potential BLODA will do.  You don't know when it will intrude, nor
> do you know what you have to do so that it intrudes.  Maybe it only
> occurs when you press a key or open a socket connection, or only if
> you move your mouse out of the Window, or if you perform a rain dance.
>
> I don't think you have the faintest chance to catch BLODAs
> automatically, other than by enhancing the BLODA tests for known BLODAs
> in cygcheck.  That's what would be most helpful in the long run.  The
> BLODA test in Cygwin is just a last straw sort of thing.  At least in
> its current implementation.
Point taken. The idea did sound a little too good to be true...

>> Heck, if we really wanted to go whole-hog, we could add an option to
>> check for dlls in $PATH that have base collisions. Once cygcheck
>> supported both those checks, the fork failure error message could
>> even tell users to run cygcheck before reporting a problem.
> To find base collisions it would be most helpful to run rebase with
> the -i option.  We could add code to cygcheck to call rebase -i.
That could be helpful.

>> Actually, now that I think about it, we could just make cygwin list
>> any base collisions among dlls used by a failed forkee and point to
>> the FAQ entry on rebaseall. The info is at our fingertips
>> (dll::preferred_base) and in the absence of base collisions we could
>> spawn a process to check for bloda, whose output (if non-empty) is
>    ^^^^^^^^^^^^^^^
>    Oh no, please don't.  The Cygwin DLL should not start applcations
>    by itself.  That sounds like a potential security hole.
Fair enough. Security hole or not, it sounds like it wouldn't have 
actually helped, so it really shouldn't be considered further.

I still think reporting specific base collisions during a fork failure 
-- or at least detecting their existence and telling the user to rebase 
-- would be helpful. Judging from the messages that regularly hit the 
list, the extra info currently delivered with fork failure messages 
isn't really actionable by the average user. Plus, we could list the 
offending paths (which may not all be on rebaseall's default path list)

Anyway, these were all just a bunch of musings, no big deal if they're 
full of holes.

Ryan


--
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: BLODA detection code in latest snapshot

[Corinna Vinschen]

On Mar  1 08:19, Ryan Johnson wrote:
> I still think reporting specific base collisions during a fork
> failure -- or at least detecting their existence and telling the
> user to rebase -- would be helpful.

Yes, that could be helpful.


Corinna

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

--
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: BLODA detection code in latest snapshot

[Andrey Repin]

Greetings, Corinna Vinschen!

>> > Yup, confirmed.  This occurs on W7/32 as well.
>> > I add shlwapi to the list of filtered DLLs for which no such message is printed.
>> 
>> Could you please consider making such list configurable, if it's not much of
>> an issue?
>> This feature seems to be the reasonable way for rough detection of potentially
>> malicious presence, but I would like to avoid certain handlers to be reported,
>> such as antivirus' LSP or keyboard hotkey handler.

> Hmm.  Well, this option isn't meant to be used all the time.  It's not
> overly intrusive, but it costs time and Cygwin already isn't exactly
> fast.  For a pure diagnosing tool, does it makes sense to add lots
> of configuration options?

> If you want to make the DLL list configurable, what's your idea?  Another
> env var like, say CYGWIN_DETECT_BLODA_DLL_IGNORE_LIST?

After a good day of pondering the question, I would suggest to not filter out
anything at all.
And i'm leaning to the suggestion of extending cygcheck functionality in the
way of reporting inserted dll's. Probably this should be done by default.


--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 02.03.2012, <02:51>

Sorry for my terrible english...


--
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: BLODA detection code in latest snapshot

[Denis Excoffier]

On Tue, Feb 28, 2012 at 10:21:44AM +0100, Corinna Vinschen wrote:
>> On Feb 27 18:53, David Rothenberger wrote:
>> > On 2/27/2012 4:26 AM, Corinna Vinschen wrote:
>> > >   Of course this is not foolproof.  The only filtered system DLLs so
>> > >   far are kernel32.dll, ntdll.dll, mswsock.dll, amd ws2_32.dll.  If you
>> > >   playing around with this, and if you find that a core system DLL is
>> > >   reported (like, say, advapi32.dll), then please notify this list, too.
>> > 
>> > On one of my Windows XP 32 boxes, it is reporting
>> > 
>> > Potential BLODA detected!  Thread function called outside of Cygwin DLL:
>> >   C:\WINDOWS\system32\advapi32.dll
>> > 
>> > when I ssh to another host. The machine DOES have potential BLODA,
>> > though: Symantec Endpoint Protection. It's never caused me any problems.
>> 
>> Weird!  I can't reproduce this on my XP box so I have to assume
>> this is a result of SEPs influence.  Hmm.  That's a bit disappointing.
>> How on earth can SEP call a thread function in advapi32?  I don't
>> think any of them are documented...
>> 
I had the same with script+xinit (using snapshot 20120314 and the
new xorg-server 1.12, although i don't think this makes any difference):

% script
% xinit      <- this is an alias
...
Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.12.0.0
OS: Windows XP Service Pack 3 [Windows NT 5.1 build 2600] (Win32)
Package: version 1.12.0-1 built 2012-03-12

XWin was started with the following command line:

/usr/bin/XWin -emulate3buttons -unixkill :0

_XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
_XSERVTransOpen: transport open failed for inet6/po8371:0
_XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6


Potential BLODA detected!  Thread function called outside of Cygwin DLL:
  D:\WINDOWS\system32\ADVAPI32.DLL
(II) xorg.conf is not supported
(II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information
LoadPreferences: /tmp/myh/.XWinrc not found
LoadPreferences: Loading /etc/X11/system.XWinrc

...

% exit
exit
Script done, file is typescript



Hope this helps,

Denis Excoffier.

--
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: BLODA detection code in latest snapshot

[Corinna Vinschen]

On Mar 21 10:39, Denis Excoffier wrote:
> XWin was started with the following command line:
> 
> /usr/bin/XWin -emulate3buttons -unixkill :0
> 
> _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
> _XSERVTransOpen: transport open failed for inet6/po8371:0
> _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6
> 
> 
> Potential BLODA detected!  Thread function called outside of Cygwin DLL:
>   D:\WINDOWS\system32\ADVAPI32.DLL

I added advapi32.dll to the list of ignored DLLs.  There's more stuff
starting new threads under the hood than I expected.


Thanks,
Corinna

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

--
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: BLODA detection code in latest snapshot

[Denis Excoffier]

On Wed, Mar 21, 2012 at 11:43:26AM +0100, Corinna Vinschen wrote:
>> I added advapi32.dll to the list of ignored DLLs.  There's more stuff
>> starting new threads under the hood than I expected.

Thank you.

Incidentally, why in the quoted message, and also in
http://cygwin.com/ml/cygwin/2012-03/msg00567.html
some of the References indicated
(eg <20120227122614.GB31025@calimero.vinschen.de>)
are not "clickable"?

Compare eg with http://cygwin.com/ml/cygwin/2012-02/msg00826.html

Could it be:
- a 29th February problem?
- a ' AT ' or ' DOT ' problem?

Regards,

Denis Excoffier.

--
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: BLODA detection code in latest snapshot

[Corinna Vinschen]

On Mar 21 12:04, Denis Excoffier wrote:
> On Wed, Mar 21, 2012 at 11:43:26AM +0100, Corinna Vinschen wrote:
> >> I added advapi32.dll to the list of ignored DLLs.  There's more stuff
> >> starting new threads under the hood than I expected.
> 
> Thank you.
> 
> Incidentally, why in the quoted message, and also in
> http://cygwin.com/ml/cygwin/2012-03/msg00567.html
> some of the References indicated
> (eg <20120227122614.GB31025@calimero.vinschen.de>)
> are not "clickable"?
> 
> Compare eg with http://cygwin.com/ml/cygwin/2012-02/msg00826.html
> 
> Could it be:
> - a 29th February problem?
> - a ' AT ' or ' DOT ' problem?

Honestly, I have no idea.  If that's a problem, maybe you could ask
on the overseers list at sourceware.org.


Corinna

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

--
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: BLODA detection code in latest snapshot

[Christian Franke]

On Feb 27, Corinna Vinschen wrote:
> I've just uploaded a new snapshot "2012-02-27 12:04:23 UTC".  It
> contains two code snippets which are supposed to help diagnosing BLODA
> problems.
> [...]
> Of course I'd be interested in your experience with this and in any
> BLODA message you get by setting CYGWIN=detect_bloda.

Got this with current "2012-03-30 10:24:55 UTC" snapshot:

$ svn log https://...

Potential BLODA detected!  Thread function called outside of Cygwin DLL:
   C:\Windows\syswow64\CRYPT32.DLL


Christian


--
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: BLODA detection code in latest snapshot

[David Rothenberger]

On 3/30/2012 1:51 PM, Christian Franke wrote:
> On Feb 27, Corinna Vinschen wrote:
>> I've just uploaded a new snapshot "2012-02-27 12:04:23 UTC".  It
>> contains two code snippets which are supposed to help diagnosing BLODA
>> problems.
>> [...]
>> Of course I'd be interested in your experience with this and in any
>> BLODA message you get by setting CYGWIN=detect_bloda.
> 
> Got this with current "2012-03-30 10:24:55 UTC" snapshot:
> 
> $ svn log https://...
> 
> Potential BLODA detected!  Thread function called outside of Cygwin DLL:
>   C:\Windows\syswow64\CRYPT32.DLL

I link svn against CRYPT32.DLL to use the "windows-cryptoapi" password
store code in the Subversion source. This is used by svn to encrypt
passwords it stores in the filesystem. Without it, the only choices are
"gnome-keyring" and "kwallet", which aren't great for Cygwin.

So, that's where the reference to CRYPT32.DLL comes from.

I do see the same message on my Win7 x64 system, but not on my WinXP 32
system.

-- 
David Rothenberger  ----  daveroth@acm.org

--
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: BLODA detection code in latest snapshot

[Yaakov (Cygwin/X)]

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

On 2012-03-30 16:15, David Rothenberger wrote:
> I link svn against CRYPT32.DLL to use the "windows-cryptoapi" password
> store code in the Subversion source. This is used by svn to encrypt
> passwords it stores in the filesystem. Without it, the only choices are
> "gnome-keyring" and "kwallet", which aren't great for Cygwin.

gnome-keyring is available and working on Cygwin.  This could still be 
supported in a separate subversion-gnome package (containing only 
cygsvn_auth_gnome_keyring-1-0.dll) by adding --enable-gnome-keyring to 
CYGCONF_ARGS and with the attached patch (untested).


Yaakov

[-- Attachment #2: 13-dso_open.patch --]
[-- Type: application/x-itunes-itlp, Size: 2081 bytes --]

[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

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