DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 5156SAZc1742883 Authentication-Results: delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com Authentication-Results: delorie.com; spf=pass smtp.mailfrom=cygwin.com DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 5156SAZc1742883 Authentication-Results: delorie.com; dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=kVFI5nHu X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6A92A385840E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1738736888; bh=bJVQB5i/LuYzYT3saTRB+1FWpoavgSw1PDm8rdQ7i3Y=; h=Date:To:Cc:Subject:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=kVFI5nHumZrKqoQicocwOetyVW4E+TA0zd7u0rGLMYnc+8MUwl1iftHYx1n4xn48P +so9kYowXk4MApZ3b2JtRP/epspxsDCoUzkHPd2LMopi8lhvhfslG08w+PiwZZBq69 scq48F8exZ/4x/Ls6K+dBIWJ1sQ1GpVOCgw942MQ= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BD6773858D20 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org BD6773858D20 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1738736862; cv=none; b=BuDk/UYAnL5KP4edkPSjP5/rV2cMVfnFYQMI+B5kHzXI2Sur9yNmcaqxldNKvIkQrF6DuhHmmgOjlJcnhzSQHdCs5tShIsln0UjzSIU8W4hqzfLMFoXYWqFRgLaM0S1TiRL6cDNL3qxNoB+I8i6A5eqIFScv43DURBXQDp0dJ3E= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1738736862; c=relaxed/simple; bh=37g6TYg+R4EjpYYkEuSvbmByk3b4LnxmI2hh2x61vJE=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=Yq0wx1DWDmetAWiCQic/TnC9f77PbtNgboE3aD0G6jKHHEnD8jPp+TopT3IpV0yMl3FT3J2IZNzMgWxdvsbACK3VshLOf7fUzPRHr7IVN+LMqjSAwiWaZAMRU4kmr3JHh4XsPaMPyty3ea28Pl5RixC+/4u/ZQmU881TJKUyHUY= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BD6773858D20 Date: Wed, 5 Feb 2025 01:27:38 -0500 To: Splitline Ng Cc: cygwin AT cygwin DOT com Subject: Re: Potential Argument Injection Issue in Cygwin's Command Line Handling Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.30 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Glenn Strauss via Cygwin Reply-To: Glenn Strauss Content-Type: text/plain; charset="utf-8" Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 5156SAZc1742883 On Wed, Feb 05, 2025 at 11:45:10AM +0800, Splitline Ng via Cygwin wrote: > Hi Marco, > > > $ python3.12 > > Python 3.12.8 (main, Jan 31 2025, 21:29:51) [GCC 12.4.0] on cygwin > > Type "help", "copyright", "credits" or "license" for more information. > > import subprocess > > subprocess.run(['./test.exe', '"', " a b c"]) > > argv[0] = ./test > > argv[1] = " > > argv[2] = a b c > > CompletedProcess(args=['./test.exe', '"', ' a b c'], returncode=0) > > > > it seems correct to me for a Cygwin Python > > This behavior appears correct for Cygwin Python because it assumes it > is running on a POSIX system. As a result, it uses Cygwin's simulated > `execve` system call rather than Windows' command-line parsing > mechanism and the parsing mechanism within Cygwin itself is consistent > so everything goes fine here. > To be more specific, the issue happens when a program thinks it is > still on Windows, so it uses Microsoft C startup convention to escape > and pass command line string and spawn that executable with > CreateProcess API. But it turns out Cygwin C startup function doesn't > fully follow that convention. > > > PS: Windows is not very consistent on quoting behaviour, e.g. > > https://github.com/Azure/azure-cli/blob/dev/doc/quoting-issues-with-powershell.md > > I think we should distinguish between shell parsing and command-line > parsing -- command-line parsing is all done by the executable itself > instead of the shell (powershell, cmd, bash etc.) > On Windows, arguments are parsed by the executable itself rather than > the shell. This means the shell does not pass an argv[] array directly > to the executable but instead sends the full command line string. Here > is a good article about this > https://daviddeley.com/autohotkey/parameters/parameters.htm#WIN > > Regards, > splitline > > On Tue, Feb 4, 2025 at 2:15 PM Splitline Huang wrote: > > > > Hello Cygwin team, > > > > I am splitline from DEVCORE research team. I recently have observed an inconsistency > > in how Cygwin handles command-line parsing compared to Microsoft’s implementation. > > > > > > According to Microsoft’s documentation [1], the \" sequence should always be > > interpreted as a literal double quote ("): > > > A double quote mark preceded by a backslash (\") is interpreted as a literal > > > double quote mark ("). > > > > However, in Cygwin, the same sequence treats the backslash as a literal character > > and starts quote mode instead. > > > > [1] https://learn.microsoft.com/en-us/cpp/c-language/parsing-c-command-line-arguments > > > > This inconsistency can cause unexpected behavior when passing executable arguments > > via the command line (as opposed to Cygwin’s `execve` method), potentially leading > > to argument injection vulnerabilities. > > > > > > Below is my testing process using the Python from Python.org (not the Cygwin version): > > > > > > splitline AT SPLITLINE0D06 ~ > > > > $ which gcc > > > > /usr/bin/gcc > > > > splitline AT SPLITLINE0D06 ~ > > > > $ cat test.c > > > > #include > > > > > > int main(int argc, char* argv[], char* envp[]) { > > > > for (int i = 0; i < argc; ++i) > > > > printf("argv[%d] = %s\n", i, argv[i]); > > > > } > > > > splitline AT SPLITLINE0D06 ~ > > > > $ gcc test.c -o test.exe > > > > splitline AT SPLITLINE0D06 ~ > > > > $ which python > > > > /cygdrive/c/Python313/python > > > > splitline AT SPLITLINE0D06 ~ > > > > $ python > > > > Python 3.13.1 (tags/v3.13.1:0671451, Dec 3 2024, 19:06:28) [MSC v.1942 > > > > 64 bit (AMD64)] on win32 > > > > Type "help", "copyright", "credits" or "license" for more information. > > > > >>> import subprocess > > > > >>> subprocess.run(['./test.exe', '"', " a b c"]) # should be only 2 args > > > > argv[0] = ./test > > > > argv[1] = \ > > > > argv[2] = a > > > > argv[3] = b > > > > argv[4] = c > > > > CompletedProcess(args=['./test.exe', '"', ' a b c'], returncode=0) > > > > >>> > > > > > > > > As we can see, it should originally be only 2 arguments: ["] and [ a b c]. However, > > the command line is parsed into 4 different arguments. > > > > Note: With that Python code, the spawned command line is: ./test.exe \" " a b c" > > > > Please let me know if you have any questions, thanks! > > > > Best regards, > > splitline > > DEVCORE Windows is security deficient in this area, not Cygwin. I'll quote myself to share my opinion: https://git.lighttpd.net/lighttpd/lighttpd1.4/src/branch/master/src/fdevent_win32.c#L543 * The Microsoft CreateProcess() interface is criminally broken. * Forcing argument strings to be concatenated into a single string * only to be re-parsed by Windows can lead to security issues. * * Above comment from 2021 was true then as now in 2025 * https://blog.orange.tw/posts/2025-01-worstfit-unveiling-hidden-transformers-in-windows-ansi/ Cheers, Glenn -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple