On 2021-10-23 22:57:09 -0500, Rob Landley via austin-group-l at The Open Group
wrote:
> On 10/23/21 8:39 PM, Vincent Lefevre wrote:
> > On 2021-10-23 18:08:37 -0500, Rob Landley via austin-group-l at The Open
> > Group wrote:
> >> Testing:
> >>
> >> $ bash -c '-i echo hello'
> >> bash: - : invalid option
> >> $ dash -c '-i echo hello'
> >> dash: 0: Illegal option -
> >> # android
> >> $ sh -c "-i echo hello"
> >> sh: sh: - : unknown option
> >>
> >> So implementing system with arguments {"sh", "-c", "--", cmd, 0}
> >> shouldn't break any existing use case that worked before.
> >
> > Couldn't this potentially introduce a security issue, in case the
> > system() argument would come from untrusted data, with sanitization
> > assuming "sh -c"?
> >
> > I mean that some strings would be expected to fail, but if "--" is
> > introduced, real code could be executed.
>
> You're suggesting that if we explicitly fix the reported bug, and have no side
> effects other than fixing that bug, this is potentially a bad thing.
>
> You're suggesting "I'm going to pass untrusted strings to sh -c and maybe bash
> will error out instead of running some of them" can be feasibly described as a
> security strategy.
No, this is not what I've said. On the contrary, I've said that
there is *sanitization* of untrusted data. My point is that this
sanitization could be based on the fact that the data are passed
to "sh -c" only, as currently specified, and code that is known
to fail could be passed as trusted (trusted, just because it is
known to fail, thus with no unexpected behavior).
--
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
