[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20240410203602.7d11csyn@steffen%sdaoden.eu>
Date: Wed, 10 Apr 2024 22:36:02 +0200
From: Steffen Nurpmeso <steffen@...oden.eu>
To: oss-security@...ts.openwall.com
Subject: Re: CERT VU#123335: Multiple Programming
Languages Fail to Escape Arguments Properly in Microsoft Windows
I want to thank Mr. Coopersmith for all his efforts.
I think this list was detoriated by some parties in the last
years, possibly due to the (management or whatever imposed)
requirement for more "formalized professionalism", instead of
trusting the main drivers of this list, but it seems that,
effectively, the situation detoriated to the absolute opposite.
Alan Coopersmith wrote in
<20215e9a-c05f-4897-8e4c-ae617ebd0cd4@...cle.com>:
|https://www.kb.cert.org/vuls/id/123335 announces:
|
|> Vulnerability Note VU#123335
|> Original Release Date: 2024-04-10 | Last Revised: 2024-04-10
...
|> Various programming languages lack proper validation mechanisms for
|> commands and in some cases also fail to escape arguments correctly
|> when invoking commands within a Microsoft Windows environment. The
...
|> <https://learn.microsoft.com/en-us/archive/blogs/twistylittlepassagesall\
|> alike/everyone-quotes-command-line-arguments-the-wrong-way>.
...
Searching around the internet all Microsoft document( translation)s
contain big warning boxes on that.
What i do not understand is why Microsoft does not fix its
_spawn*() function series to convert the char**argv array to
a properly quoted command line argument (or whatever way they
could also take *internally* to get that done)?
They could internally even double-check that the
array->string->array conversion results in the same data, and do
perform auto-quoting if not?
How likely it is that anyone really wants to turn a char**argv
array into a string that does not convert back properly?
I mean, it is Microsoft's C library that we are talking about[1]:
In principle, each program can parse the command line string
differently, but most use the convetion that CommandLineToArgvW
and the Microsoft C library understand. This convention is
a good one because it provides a way to encode any command line
argument as part of a command line string without losing
information.
The problem is that there is no ArgvToCommandLineW. How do we
construct an argument string understood by CommandLineToArgvW?
^ But *why* then?
The C runtime library is useless
--------------------------------
Our first instinct should be look for a library function that's
already solved the problem.
...
That's not what we want!
^ Maybe make it better, then? Why not?
The correct solution
^ There it is!
[1] https://learn.microsoft.com/en-us/archive/blogs/twistylittlepassagesallalike/everyone-quotes-command-line-arguments-the-wrong-way
Shouldn't the real vulnerability be attributed to the Microsoft
_spawn*() function series? It takes an array of individual
strings, if it internally munges that for whatever reason into
a single string they could as well take that single string from
the outside, surely the "blamed" language developers would have
spend a thought. The Microsoft interface is to blame!
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
