Re: BLODA detection code in latest snapshot
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
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 daver...@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
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 13-dso_open.patch Description: application/itunes-itlp -- 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
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
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
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.gb31...@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
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.gb31...@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
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
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
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
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 (anrdae...@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
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
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 (anrdae...@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
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
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
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
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
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
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
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 (anrdae...@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
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
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 daver...@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
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 daver...@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
