Re: [Mingw-w64-public] getmainargs changes

On Friday 17 January 2025 15:22:30 Lasse Collin wrote: > On 2025-01-16 Pali Rohár wrote: > > On Thursday 16 January 2025 18:32:08 Lasse Collin wrote: > > > I see that sizeof(DIR) depends on _USE_32BIT_TIME_T because DIR > > > contains _finddata_t or _wfinddata_t. Luckily no one is supposed to > > >

Re: [Mingw-w64-public] getmainargs changes

On 2025-01-16 Pali Rohár wrote: > On Thursday 16 January 2025 18:32:08 Lasse Collin wrote: > > I see that sizeof(DIR) depends on _USE_32BIT_TIME_T because DIR > > contains _finddata_t or _wfinddata_t. Luckily no one is supposed to > > access that structure directly. > > That is really bad. So it

Re: [Mingw-w64-public] getmainargs changes

On Thursday 16 January 2025 18:32:08 Lasse Collin wrote: > On 2025-01-14 Pali Rohár wrote: > > Well, warnings are warnings. They are always being added by new > > compiler versions, so I would not be afraid of adding also in new > > mingw-w64 version. And security "warning" for me sounds like a goo

Re: [Mingw-w64-public] getmainargs changes

On 2025-01-14 Pali Rohár wrote: > Well, warnings are warnings. They are always being added by new > compiler versions, so I would not be afraid of adding also in new > mingw-w64 version. And security "warning" for me sounds like a good > idea. OK, I agree. :-) Remember that I'm not a MinGW-w64 de

Re: [Mingw-w64-public] getmainargs changes

On Tuesday 14 January 2025 21:42:18 Lasse Collin wrote: > On 2025-01-12 Pali Rohár wrote: > > GetCommandLineA(), __p__acmdln(), _acmdln and WinMain()'s lpCmdLine > > are all affected by this problem. In any case, I think we should mark > > all these functions and variables as security vulnerable. I

Re: [Mingw-w64-public] getmainargs changes

On 2025-01-12 Pali Rohár wrote: > GetCommandLineA(), __p__acmdln(), _acmdln and WinMain()'s lpCmdLine > are all affected by this problem. In any case, I think we should mark > all these functions and variables as security vulnerable. Is there > some attribute for gcc for marking them, so usage woul

Re: [Mingw-w64-public] getmainargs changes

On Sunday 12 January 2025 21:09:38 Lasse Collin wrote: > On 2025-01-10 Pali Rohár wrote: > > Then there is an issue that argv[i] is suppose to be filename argument > > and even after the correct splitting of cmd-to-argv[], due to the > > bestfit, the argv[i] describes other file than the original o

Re: [Mingw-w64-public] getmainargs changes

On 2025-01-10 Pali Rohár wrote: > Then there is an issue that argv[i] is suppose to be filename argument > and even after the correct splitting of cmd-to-argv[], due to the > bestfit, the argv[i] describes other file than the original one in > wargv[i]. I was thinking more about this issue... but n

Re: [Mingw-w64-public] getmainargs changes

On Friday 10 January 2025 19:35:30 Lasse Collin wrote: > On 2025-01-04 Pali Rohár wrote: > > Interesting... What is not clear is if the research team reported this > > bug to Microsoft and if Microsoft is going to address this issue at > > some level, or at least document best practices what should

Re: [Mingw-w64-public] getmainargs changes

On 2025-01-04 Pali Rohár wrote: > Interesting... What is not clear is if the research team reported this > bug to Microsoft and if Microsoft is going to address this issue at > some level, or at least document best practices what should affected > applications do. There is a blog post with more de

Re: [Mingw-w64-public] getmainargs changes

Interesting... What is not clear is if the research team reported this bug to Microsoft and if Microsoft is going to address this issue at some level, or at least document best practices what should affected applications do. Anyway, Has somebody checked Visual C runtime and UCRT source code if the

Re: [Mingw-w64-public] getmainargs changes

There is more information about the issue at . Seems that it may have been released in mid-December already. -- Lasse Collin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lis

Re: [Mingw-w64-public] getmainargs changes

On Wednesday 27 November 2024 15:11:52 Pali Rohár wrote: > On Wednesday 27 November 2024 16:02:35 Lasse Collin wrote: > > On 2024-11-27 Pali Rohár wrote: > > > I think that we should not ignore memory allocation failures. > > > > I agree. I'm not able to comment the implementation ideas though. >

Re: [Mingw-w64-public] getmainargs changes

On Wednesday 27 November 2024 16:02:35 Lasse Collin wrote: > On 2024-11-27 Pali Rohár wrote: > > I think that we should not ignore memory allocation failures. > > I agree. I'm not able to comment the implementation ideas though. > > -- > Lasse Collin Just to note that this issue is mostly rare.

Re: [Mingw-w64-public] getmainargs changes

On 2024-11-27 Pali Rohár wrote: > I think that we should not ignore memory allocation failures. I agree. I'm not able to comment the implementation ideas though. -- Lasse Collin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net

Re: [Mingw-w64-public] getmainargs changes

On Saturday 09 November 2024 16:27:09 Pali Rohár wrote: > Hello, now, when looking at this issue, I have figured out that in > mingw-w64 is declaration of __getmainargs() and __wgetmainargs() > functions incompatible with msvcrt.dll library. > > In header file mingw-w64-crt/include/internal.h is:

Re: [Mingw-w64-public] getmainargs changes

On Tuesday 12 November 2024 19:39:17 Lasse Collin wrote: > On 2024-11-12 Pali Rohár wrote: > > The only idea for FindFirstFileA/FindNextFindA which I have is to > > return "problematic" file names only in 8.3 notation. 8.3 notation is > > supported in all WinAPI calls, it is always in ASCII and has

Re: [Mingw-w64-public] getmainargs changes

On 2024-11-12 Lasse Collin wrote: > On 2024-11-12 Pali Rohár wrote: > > At least every character which is by best-fit mapped to double quote > > has to be replaced. > > Yes, that seems mandatory. This alone might not be enough because a double quote can be escaped with a backslash. Thus unexpec

Re: [Mingw-w64-public] getmainargs changes

On 2024-11-12 Jeremy Drake wrote: > On Tue, 12 Nov 2024, Martin Storsjö wrote: > > > Regarding the above, I wouldn't exactly think that those apps ignore > > argv[] and get the command line some other way - but I'm not > > entirely sure; ideally we'd take it up with them to understand > > exactly

Re: [Mingw-w64-public] getmainargs changes

On Tue, 12 Nov 2024, Martin Storsjö wrote: > Regarding the above, I wouldn't exactly think that those apps ignore > argv[] and get the command line some other way - but I'm not entirely > sure; ideally we'd take it up with them to understand exactly what their > setup is and how it works, and how

Re: [Mingw-w64-public] getmainargs changes

On 2024-11-12 Pali Rohár wrote: > On Monday 11 November 2024 22:10:01 Lasse Collin wrote: > > If permissive mode can be enabled the same way as _dowildcard works, > > then argv[] could be constructed with the same code as in strict > > mode. The current crtexe.c in master has > > > > for (int i

Re: [Mingw-w64-public] getmainargs changes

在 2024-11-12 23:17, Lasse Collin 写道: I'm suggesting it because the patch clearly is harmful for some types of apps which don't need it for security reasons. I leave the final decision to MinGW-w64 maintainers. Done now: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/c6857dc Meanwhile, I see

Re: [Mingw-w64-public] getmainargs changes

On 2024-11-12 LIU Hao wrote: > 在 2024-11-12 22:49, Lasse Collin 写道: > > The _exit(255) trick is clearly not an acceptable default. My patch > > should be reverted until a better one is made. It might be that all > > apps that want safe argv[] for main() will need something special on > > Windows (l

Re: [Mingw-w64-public] getmainargs changes

On Tue, 12 Nov 2024, Lasse Collin wrote: On 2024-11-12 Martin Storsjö wrote: FYI, see https://github.com/msys2/MINGW-packages/issues/22462 where someone ran into issues caused by this. Also see https://ffmpeg.org/pipermail/ffmpeg-devel/2024-November/335936.html where someone else observes othe

Re: [Mingw-w64-public] getmainargs changes

在 2024-11-12 22:49, Lasse Collin 写道: I understand only now that many apps use main() but ignore argv[] and instead get the args by some other method. I was too focused on porting apps written for POSIX systems. I'm sorry. It doesn't matter. That's not your fault. The _exit(255) trick is clea

Re: [Mingw-w64-public] getmainargs changes

On 2024-11-12 Martin Storsjö wrote: > FYI, see https://github.com/msys2/MINGW-packages/issues/22462 where > someone ran into issues caused by this. > > Also see > https://ffmpeg.org/pipermail/ffmpeg-devel/2024-November/335936.html where > someone else observes other issues related to this. (The

Re: [Mingw-w64-public] getmainargs changes

在 2024-11-12 06:34, Martin Storsjö 写道: FYI, see https://github.com/msys2/MINGW-packages/issues/22462 where someone ran into issues caused by this. Also see https://ffmpeg.org/pipermail/ffmpeg-devel/2024-November/335936.html where someone else observes other issues related to this. (The descrip

Re: [Mingw-w64-public] getmainargs changes

On Monday 11 November 2024 22:10:01 Lasse Collin wrote: > On 2024-11-11 Pali Rohár wrote: > > If application do not want to fail then double quote in _acmdln must > > not come from other (non double quote) character. Otherwise argv[] > > would be wrongly constructed. And I think that argv[] splitti

Re: [Mingw-w64-public] getmainargs changes

On Mon, 11 Nov 2024, Lasse Collin wrote: On 2024-11-11 Pali Rohár wrote: If application do not want to fail then double quote in _acmdln must not come from other (non double quote) character. Otherwise argv[] would be wrongly constructed. And I think that argv[] splitting must be done correctly

Re: [Mingw-w64-public] getmainargs changes

Hello, now I have figured out that the problem described here is still present in mingw-w64 repository even with the fix from commit: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/0d42217123d3aec0341b79f6d959c76e09648a1e/ The problem is in the file mingw-w64-crt/crt/crtexewin.c which directly

Re: [Mingw-w64-public] getmainargs changes

On 2024-11-11 Pali Rohár wrote: > If application do not want to fail then double quote in _acmdln must > not come from other (non double quote) character. Otherwise argv[] > would be wrongly constructed. And I think that argv[] splitting must > be done correctly. I agree it makes sense to do split

Re: [Mingw-w64-public] getmainargs changes

On Sunday 10 November 2024 20:56:05 Lasse Collin wrote: > On 2024-11-10 Pali Rohár wrote: > > On Sunday 10 November 2024 00:14:42 Pali Rohár wrote: > > > > On 2024-11-09 LIU Hao wrote: > > > > > I have a crazy idea now. Does it make sense to overwrite > > > > > `_acmdln` (for MSVCRT) or `*__p__ac

Re: [Mingw-w64-public] getmainargs changes

在 2024-11-11 02:56, Lasse Collin 写道: If conversion cannot be done in a lossless way, it depends on the application what is a safe fallback, or if there are any useful fallbacks at all. Maybe I'm missing something but I don't see a useful generic method to overwrite _acmdln. In a previous messag

Re: [Mingw-w64-public] getmainargs changes

On Sunday 10 November 2024 00:14:42 Pali Rohár wrote: > On Saturday 09 November 2024 21:30:53 Lasse Collin wrote: > > On 2024-11-09 LIU Hao wrote: > > > Really, I don't think this should be fixed in the CRT. It should be > > > fixed by sanitizing the result in `GetCommandLineA()`. Reverting the > >

Re: [Mingw-w64-public] getmainargs changes

On Saturday 09 November 2024 21:30:53 Lasse Collin wrote: > On 2024-11-09 LIU Hao wrote: > > Really, I don't think this should be fixed in the CRT. It should be > > fixed by sanitizing the result in `GetCommandLineA()`. Reverting the > > commit makes sense if Microsoft will fix it sooner or latter.

Re: [Mingw-w64-public] getmainargs changes

On Saturday 09 November 2024 22:39:08 LIU Hao wrote: > 在 2024-11-09 02:23, Pali Rohár 写道: > > On Friday 08 November 2024 19:49:24 Lasse Collin wrote: > > > Hello! > > > > > > I apologize for the hassle. :-( It's a security issue that (I think) is > > > only half-public, so I didn't want to post to

Re: [Mingw-w64-public] getmainargs changes

On Saturday 09 November 2024 22:39:08 LIU Hao wrote: > 在 2024-11-09 02:23, Pali Rohár 写道: > > On Friday 08 November 2024 19:49:24 Lasse Collin wrote: > > > Hello! > > > > > > I apologize for the hassle. :-( It's a security issue that (I think) is > > > only half-public, so I didn't want to post to

Re: [Mingw-w64-public] getmainargs changes

Hello, now, when looking at this issue, I have figured out that in mingw-w64 is declaration of __getmainargs() and __wgetmainargs() functions incompatible with msvcrt.dll library. In header file mingw-w64-crt/include/internal.h is: _CRTIMP int __cdecl __getmainargs(int * _Argc, char *** _Argv, ch

Re: [Mingw-w64-public] getmainargs changes

在 2024-11-09 02:23, Pali Rohár 写道: On Friday 08 November 2024 19:49:24 Lasse Collin wrote: Hello! I apologize for the hassle. :-( It's a security issue that (I think) is only half-public, so I didn't want to post to the public mailing list. Apparently the tiny group of people I discussed this w

Re: [Mingw-w64-public] getmainargs changes

On Friday 08 November 2024 19:49:24 Lasse Collin wrote: > Hello! > > I apologize for the hassle. :-( It's a security issue that (I think) is > only half-public, so I didn't want to post to the public mailing list. > Apparently the tiny group of people I discussed this was too small (all > are in t

[Mingw-w64-public] getmainargs changes

Hello, In recent commit "crt: Avoid best-fit mapping when constructing argv for main()" https://sourceforge.net/p/mingw-w64/mingw-w64/ci/0d42217123d3aec0341b79f6d959c76e09648a1e/ was done big change in how all compiled applications will handle access to argc and argv[]. I consider this change mor