Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.