Recent

Author Topic: Vulnerabilities lurking in Windows Unicode conversion ("WorstFit")  (Read 1215 times)

colo

  • New Member
  • *
  • Posts: 48
A few days ago, a (imho) very impressive writeup on a peculiartiy of the Windows platform and how it handles Unicode/ANSI-Codepage backwards compatibility and conversion was published at https://blog.orange.tw/posts/2025-01-worstfit-unveiling-hidden-transformers-in-windows-ansi/ - the gist is that, if one is unlucky enough to pass Unicode into routines that expect non-Unicode string data, implicit conversion to the current OS codepage will happen - and if the stars align just right (i.e., the string having been passed in was massaged carefully by an attacker), a lot of bad things, up to arbitrary code execution, can follow.

Now as far as I can tell, you can (hopefully) avoid the pitfalls mentioned in the article if you are VERY careful to avoid all the ANSI-specific implementations in Windows, and stick to the wide-character-variants of the affected APIs.

Alternatively, you can reconfigure your Windows OS to use only Unicode encoded in UTF-8 as its internal string encoding/representation, but that will probably break legacy applications in obscure places.

Mitigating against this seems to be non-trivial (or maybe downright impossible?) for anything that uses Windows' C runtime/API in what could be construed as a "portable" fashion (i. e., defining main() instead of the Windows-specific wmain() is enough to incur the problem).

I was wondering what software authors implementing their programs in FPC and Lazarus could do to avoid being bitten by these hidden mines in the Windows API. Do you have any thoughts or advice on the matter?

Thaddy

  • Hero Member
  • *****
  • Posts: 16520
  • Kallstadt seems a good place to evict Trump to.
Re: Vulnerabilities lurking in Windows Unicode conversion ("WorstFit")
« Reply #1 on: January 12, 2025, 01:04:42 pm »
Basically nobody (if everybody would be honest), but indeed I configured my windows terminals to use Unicode utf8
----
C:\Users\thadd>chcp
Active code page: 65001
----

It is a pity that this is still not the default.
On most nixes it is the default.
« Last Edit: January 12, 2025, 01:10:36 pm by Thaddy »
But I am sure they don't want the Trumps back...

tetrastes

  • Hero Member
  • *****
  • Posts: 632
Re: Vulnerabilities lurking in Windows Unicode conversion ("WorstFit")
« Reply #2 on: January 12, 2025, 06:25:19 pm »
I was wondering what software authors implementing their programs in FPC and Lazarus could do to avoid being bitten by these hidden mines in the Windows API. Do you have any thoughts or advice on the matter?

From Win 10 1903 one can use UTF-8 ANSI CP at per program basis using manifest, regardless of programming language. In Lazarus you can simply add this to manifest in Project Options.

colo

  • New Member
  • *
  • Posts: 48
Re: Vulnerabilities lurking in Windows Unicode conversion ("WorstFit")
« Reply #3 on: January 13, 2025, 09:45:08 am »
@Thaddy: yeah, that's one blunt but effective way I've seen mentioned to deal with it - but I guess it'd be unwise to rely on users universally setting this manually to prevet one's program from being vulnerable to WorstFit-enabled weaknesses. I've read (afaict unsubstantiated) comments/reports on the web that said codepage 65001 is "buggy" - I was wondering if you are aware of any concrete problems you have on your machine/with applications you use because of having it set?

@tetrastes: Nice, thank you very much for this very practical advice - TIL! :) I guess that helps move the whole tragedy from "potential security problem" territory into "potentially corrupted data problem" territory, which is a clear win in my book!


Is there any guide/advice on how to set up one's FPC and Lazarus programming environment (the Lazarus IDE, but also source code thorugh modes and use of components/classes) optimally to deal as correctly as possible with a Unicode environment?

Thaddy

  • Hero Member
  • *****
  • Posts: 16520
  • Kallstadt seems a good place to evict Trump to.
Re: Vulnerabilities lurking in Windows Unicode conversion ("WorstFit")
« Reply #4 on: January 13, 2025, 11:10:21 am »
I've read (afaict unsubstantiated) comments/reports on the web that said codepage 65001 is "buggy" - I was wondering if you are aware of any concrete problems you have on your machine/with applications you use because of having it set?
If UTF8 was buggy, Linux would not work. Such comments are usually from nitwits that do not understand unicode (8,16,32)  or are still under the impression that it is ucs2.
On Windows there are also no issues since a very long time, even if Windows is utf16 centric, its utf8 support is seamless.
Information on the web has a sell-by date and may people forget that.
But I am sure they don't want the Trumps back...

tetrastes

  • Hero Member
  • *****
  • Posts: 632
Re: Vulnerabilities lurking in Windows Unicode conversion ("WorstFit")
« Reply #5 on: January 13, 2025, 12:51:20 pm »
Is there any guide/advice on how to set up one's FPC and Lazarus programming environment (the Lazarus IDE, but also source code thorugh modes and use of components/classes) optimally to deal as correctly as possible with a Unicode environment?

https://wiki.lazarus.freepascal.org/FPC_Unicode_support
https://wiki.lazarus.freepascal.org/Unicode_Support_in_Lazarus

 

TinyPortal © 2005-2018