Re: Cygwin's ACL handling is NOT interoperable with Windows
Andrey Repin wrote: > Greetings, Stefan Kanthak! > >> PS: <https://cygwin.com/cygwin-ug-net/using.html#pathnames-win32-api> >> too states bloody lies: > >> | The Windows subsystem only supports CWD paths of up to 258 chars. ~~~ > > 260 including drive letter. WRONG, AGAIN! 260 is the value of MAX_PATH, which accounts for the trailing \0, and commonly used as | char buffer[MAX_PATH]; I recommend to read <https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file> VERY careful! >> The Win32 API supports pathnames with up to 32767 (Unicode) characters; >> this includes of course the CWD! > > CWD may be, but command processor does not. Neither Cygwin's WRONG documentation nor I referred to the command processor. regards Stefan -- 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
Cygwin's ACL handling is NOT interoperable with Windows
Hi, <https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-files> states: | There's just one problem when trying to map the POSIX permission model | onto the Windows permission model. ... | Canonical ACLs are unable to reflect each possible combination of POSIX | permissions. ... | Again: This works on all supported versions of Windows. Only the GUIs | aren't able (or willing) to deal with that order. These last two statements are wrong: * the first statement holds ONLY because of the LIMITATION of the POSIX permissions; it is WRONG for the general case, which ALL Windows interfaces/components need to consider and handle, EVERYWHERE! * the second statement is a blatant lie: to guarantee CORRECT interpretation of arbitrary ACLs, ALL Windows interfaces/components, not just the "GUIs", MUST create CANONICAL ACLs only. This especially means that not just Windows Explorer, but also the command processor with its builtin COPY command as well as the CopyFile() <https://msdn.microsoft.com/en-us/library/aa220078.aspx> API (just to pick 3 examples) bring INHERITED ACEs into their PROPER canonical order. As Cygwin is a guest in the house of Windows, it should respect its hosts house rules; instead it but violates them, and blames the host for its faults! | But don't even think of pressing OK... Fortunately nobody need to press OK here, but everybody can demonstrate Cygwin's defects as follows: * Use Windows Explorer, the command processor or CopyFile() to copy an arbitrary file into a directory created by Cygwin, then inspect its ACL! * Use Windows' Explorer, the command processor or CopyFile() to copy an arbitrary file created by Cygwin into an arbitrary directory created by Cygwin, then inspect its ACL. * Use Windows Explorer or the command processor to create a subdirectory in a directory created by Cygwin, then inspects its ACL! Do these ACLs reflect the intended or expected POSIX permissions? OUCH³! Win32 functions like CreateFile() and CreateDirectory() (see <https://msdn.microsoft.com/en-us/library/aa363858.aspx> and <https://msdn.microsoft.com/en-us/library/aa363855.aspx>) allow to write NON-canonical ACLs via direct specification of a "security descriptor"; if NULL is specified (which is the typical case), they create canonical ACLs, reordering inherited ACEs! Unfortunately their documentation misses remarks on the proper canonical order of ACLs, and how inherited but UNORDERED ACLs are handled. The documentation of other Win32 functions, for example AddAccessAllowedAce() and AddAccessDeniedAce() (see <https://msdn.microsoft.com/en-us/library/aa374947.aspx> and <https://msdn.microsoft.com/de-de/library/aa374962.aspx>) but EXPLICITLY states: | These functions do not automatically place the new ACE in the | proper canonical order. It is the caller's responsibility to | ensure that the ACL is in canonical order by adding ACEs in the | proper sequence. <https://msdn.microsoft.com/en-us/library/aa374951.aspx> and <https://msdn.microsoft.com/en-us/library/aa374964.aspx> go further: | The caller must ensure that ACEs are added to the DACL in the | correct order. For more information, see Order of ACEs in a DACL. <https://msdn.microsoft.com/en-us/library/aa379298.aspx> <https://msdn.microsoft.com/en-us/library/aa446683.aspx> <https://technet.microsoft.com/en-us/library/cc781716.aspx> | The canonical order ensures that an explicit access-denied ACE is | enforced regardless of any explicit access-allowed ACE. JFTR: for the algorithm used in Windows and why the proper order of ACLs is crucial see <https://blogs.msdn.microsoft.com/oldnewthing/20070608-00/?p=26503> Also see <http://www.ntfs.com/ntfs-permissions-acl-use.htm> Fix Cygwin's BUGGY ACL creation! regards Stefan Kanthak PS: <https://cygwin.com/cygwin-ug-net/using.html#pathnames-win32-api> too states bloody lies: | The Windows subsystem only supports CWD paths of up to 258 chars. The Win32 API supports pathnames with up to 32767 (Unicode) characters; this includes of course the CWD! -- 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: Defective "portable executables" distributed/created by Cygwin
VS/VC 2010 (as well as VS/VC 2008) is still supported by Microsoft. To my knowledge, 10.00.40219.386 is the latest linker available for VS/VC 2010. Where can I get a fixed linker for this supported product? regards Stefan Kanthak - Original Message - From: "YongKang Zhu" To: "Ten Tzen" ; "Steve Carroll (VISUAL STUDIO)" ; "Stefan Kanthak" ; Cc: "Compiler Crash" Sent: Thursday, May 10, 2018 11:45 PM Subject: RE: Defective "portable executables" distributed/created by Cygwin I remember this has been fixed. Please try use a more recent linker. >From the exception message below, the linker from VS 2010 was being used. From: Ten Tzen Sent: Thursday, May 10, 2018 2:27 PM To: Steve Carroll (VISUAL STUDIO) ; Stefan Kanthak ; cygwin@cygwin.com; YongKang Zhu Cc: Compiler Crash Subject: Re: Defective "portable executables" distributed/created by Cygwin +Yongkang Get Outlook for iOS<https://aka.ms/o0ukef> From: Steve Carroll (VISUAL STUDIO) Sent: Thursday, May 10, 2018 3:29:24 PM To: Stefan Kanthak; cygwin@cygwin.com<mailto:cygwin@cygwin.com>; Ten Tzen Cc: Compiler Crash Subject: RE: Defective "portable executables" distributed/created by Cygwin @Ten Tzen can you take a look? -Original Message- From: Stefan Kanthak mailto:stefan.kant...@nexgo.de>> Sent: Thursday, May 10, 2018 11:30 AM To: cygwin@cygwin.com<mailto:cygwin@cygwin.com> Cc: Compiler Crash mailto:compilercr...@microsoft.com>> Subject: Defective "portable executables" distributed/created by Cygwin Hi @ll, the "portable executables" distributed by Cygwin (and of course those created with Cygwin's GCC toolchain too) have INVALID/ILLEGAL headers: 0. Microsoft's DUMPBIN.EXE alias LINK.EXE /DUMP aborts with "access violation" (see below) on almost all Cygwin binaries! 1. they use INVALID/ILLEGAL section names like "/4" or "/14", upon which Microsoft's DUMPBIN.EXE alias LINK.EXE /DUMP stops enumerating the section headers (see below)! From the PE format specification <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmsdn.microsoft.com%2Fen-us%2Flibrary%2F%2Fms680547.aspx%23secti on_table__section_headers_&data=02%7C01%7CSteven.Carroll%40microsoft.com%7C0e2f82b44f0347620dda08d5b6a5bd04%7C72f988bf86f141af91ab2d 7cd011db47%7C1%7C0%7C636615745333593092&sdata=FUYwQywfO%2FPDIDeT3%2BQSaVEk7iLj32PRJT4T8mxUKdg%3D&reserved=0>: | Offset Size Field Description | 0 8 Name An 8-byte, null-padded UTF-8 encoded string. | If the string is exactly 8 characters long, | there is no terminating null. For longer names, | this field contains a slash (/) that is followed | by an ASCII representation of a decimal number | that is an offset into the string table. | Executable images do not use a string table and | do ~~ | not support section names longer than 8 characters. ~~~ | Long names in object files are truncated if they | are emitted to an executable file. ~~ 2. despite no COFF symbol table and a symbol count of 0 (in words: ZERO!) they specify the "PointerToSymbolTable" (see below)! From the PE format specification <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmsdn.microsoft.com%2Fen-us%2Flibrary%2F%2Fms680547.aspx%23coff_ file_header__object_and_image_&data=02%7C01%7CSteven.Carroll%40microsoft.com%7C0e2f82b44f0347620dda08d5b6a5bd04%7C72f988bf86f141af91 ab2d7cd011db47%7C1%7C0%7C636615745333593092&sdata=gbNW5KJ5qkGc2IjJf3eEeSQDeqk3iQN5iBQUbf2WNec%3D&reserved=0>: | Offset Size Field Description | 8 4 PointerToSymbolTable The file offset of the COFF symbol | table, or zero if no COFF symbol | table is present. This value should | be zero for an image because COFF | debugging information is deprecated. Please fix your tools! regards Stefan Kanthak === output from LINK.EXE /DUMP bash.exe === Microsoft (R) COFF/PE Dumper Version 10.00.40219.386 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file bash.exe File Type: EXECUTABLE IMAGE LINK : fatal error LNK1000: Internal error during DumpSections Version 10.00.40219.386 ExceptionCode= C005 E
Defective "portable executables" distributed/created by Cygwin
Hi @ll, the "portable executables" distributed by Cygwin (and of course those created with Cygwin's GCC toolchain too) have INVALID/ILLEGAL headers: 0. Microsoft's DUMPBIN.EXE alias LINK.EXE /DUMP aborts with "access violation" (see below) on almost all Cygwin binaries! 1. they use INVALID/ILLEGAL section names like "/4" or "/14", upon which Microsoft's DUMPBIN.EXE alias LINK.EXE /DUMP stops enumerating the section headers (see below)! From the PE format specification <https://msdn.microsoft.com/en-us/library//ms680547.aspx#section_table__section_headers_>: | Offset Size Field Description | 0 8 Name An 8-byte, null-padded UTF-8 encoded string. | If the string is exactly 8 characters long, | there is no terminating null. For longer names, | this field contains a slash (/) that is followed | by an ASCII representation of a decimal number | that is an offset into the string table. | Executable images do not use a string table and do ~~ | not support section names longer than 8 characters. ~~~ | Long names in object files are truncated if they | are emitted to an executable file. ~~ 2. despite no COFF symbol table and a symbol count of 0 (in words: ZERO!) they specify the "PointerToSymbolTable" (see below)! From the PE format specification <https://msdn.microsoft.com/en-us/library//ms680547.aspx#coff_file_header__object_and_image_>: | Offset Size Field Description | 8 4 PointerToSymbolTable The file offset of the COFF symbol | table, or zero if no COFF symbol | table is present. This value should | be zero for an image because COFF | debugging information is deprecated. Please fix your tools! regards Stefan Kanthak === output from LINK.EXE /DUMP bash.exe === Microsoft (R) COFF/PE Dumper Version 10.00.40219.386 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file bash.exe File Type: EXECUTABLE IMAGE LINK : fatal error LNK1000: Internal error during DumpSections Version 10.00.40219.386 ExceptionCode= C005 ExceptionFlags = ExceptionAddress = 00427FE0 (0040) "C:\Program Files\Microsoft Visual Studio 2010\VC\bin\link.exe" NumberParameters = 0002 ExceptionInformation[ 0] = ExceptionInformation[ 1] = 0004 CONTEXT: Eax= 4040 Esp= 0012E740 Ebx= 014B53C0 Ebp= 0012E768 Ecx= 0004 Esi= 0004 Edx= 00404164 Edi= 014C Eip= 00427FE0 EFlags = 00010246 SegCs = 001B SegDs = 0023 SegSs = 0023 SegEs = 0023 SegFs = 003B SegGs = Dr0= Dr3= Dr1= Dr6= Dr2= Dr7= === output from LINK.EXE /DUMP /HEADERS bash.exe === Microsoft (R) COFF/PE Dumper Version 10.00.40219.386 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file bash.exe PE signature found File Type: EXECUTABLE IMAGE FILE HEADER VALUES 14C machine (x86) B number of sections 3000 time date stamp Thu Jan 01 04:24:48 1970 C2600 file pointer to symbol table 0 number of symbols E0 size of optional header 32E characteristics Executable Line numbers stripped Symbols stripped Application can handle large (>2GB) addresses 32 bit word machine Debug information stripped OPTIONAL HEADER VALUES 10B magic # (PE32) 2.25 linker version 7C800 size of code C2200 size of initialized data 9E00 size of uninitialized data 1000 entry point (00401000) 1000 base of code 7E000 base of data 40 image base (0040 to 004D2FFF) 1000 section alignment 200 file alignment 4.00 operating system version 1.00 image version 4.00 subsystem version 0 Win32 version D3000 size of image 400 size of headers C85A6 checksum 3 subsystem (Windows CUI) 8000 DLL characteristics
Re: [PWNED/DOSSED] Cygwin's setup-x86.exe loads and executes rogue DLL from its application directory
Second and last chance! See <http://home.arcor.de/skanthak/policy.html> - Original Message - From: "Stefan Kanthak" To: Cc: Sent: Monday, December 28, 2015 4:23 AM Subject: [PWNED/DOSSED] Cygwin's setup-x86.exe loads and executes rogue DLL from its application directory > Hi, > > Cygwin's setup-x86.exe loads and executes UXTheme.dll > (on Windows XP also ClbCatQ.dll) and more from its > "application directory". > > For software downloaded with a web browser the application > directory is typically the user's "Downloads" directory: see > <https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html>, > <http://blog.acrossecurity.com/2012/02/downloads-folder-binary-planting.html> > and <http://seclists.org/fulldisclosure/2012/Aug/134> > > If UXTheme.dll (or one of the other DLLs) gets planted in > the user's "Downloads" directory per "drive-by download" or > "social engineering" this vulnerability becomes a remote code > execution. > > If setup-x86.exe is NOT started with --no-admin the vulnerability > results in an escalation of privilege too! > > > Proof of concept/demonstration: > ~~~ > > 1. visit <http://home.arcor.de/skanthak/sentinel.html>, download > <http://home.arcor.de/skanthak/download/SENTINEL.DLL> and save > it as UXTheme.dll in your "Downloads" directory; > > 2. on Windows XP, copy the downloaded UXTheme.dll as ClbCatQ.dll; > > 3. download setup-x86.exe and save it in your "Downloads" directory; > > 4. execute setup-x86.exe from your "Downloads" directory; > > 5. notice the message boxes displayed from UXTheme.dll placed in > step 1 (and ClbCatQ.dll placed in step 2). > > PWNED! > > 6. copy the downloaded UXTheme.dll as WSock32.dll (on Windows XP > also as PSAPI.dll and WS2_32.dll); > > 7. rerun setup-x86.exe from your "Downloads" directory. > > DOSSED! > > 8. turning the denial of service into an arbitrary (remote) code > execution is trivial: just add the SINGLE entry (PSAPI.dll: > EnumProcesses, WSock32.Dll: recv, WS2_32.dll: Ordinal 21) > referenced from setup-x86.exe to a rogue DLL of your choice. > > PWNED again! > > > See <http://seclists.org/fulldisclosure/2015/Nov/101>, > <http://seclists.org/fulldisclosure/2015/Dec/86> and > <http://seclists.org/fulldisclosure/2015/Dec/121> plus > <http://home.arcor.de/skanthak/!execute.html> and > <http://home.arcor.de/skanthak/sentinel.html> for details about > this well-known and well-documented BEGINNER'S error! > > > Then dump your vulnerable executable installer and provide a SAFE > installer instead: either .MSI or .INF (plus .CAB). > > > I'll publish in 45 days. > See <http://home.arcor.de/skanthak/policy.html> and return the > CVE identifier assigned for this vulnerability to me! > > > regards > Stefan Kanthak -- 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
