Bug#882222: Document security problems with system.3 and popen.3 (argument injection)
Hello Bastien
On 22 November 2017 at 14:53, Bastien ROUCARIES
wrote:
> On Wed, Nov 22, 2017 at 2:45 PM, Michael Kerrisk (man-pages)
> wrote:
>>> Could you also warn about popen ?
>>
>> I already added a cross reference from popen(3) to the Caveats section
>> in system(3). I should have mentioned that before.
>>
>>> And mention that system(sprintf("command %s")) is a security hole
>>
>> That seems obviously dangerous. But don't you think it is covered by this
>> text:
>>
>>Any user input that is employed as part of command should be care‐
>>fully sanitized, to ensure that unexpected shell commands or com‐
>>mand options are not executed. Such risks are especially grave
>>when using system() from a privileged program.
>> ?
>
> Yes but does not avoid tentation do use escape character
>>
>>> BTW escaping char is hard with shell, better to use execvp
>>
>> Agreed. I would not attempt escaping. Safer to allow only a whitelist
>> of permited characters from user input.
>
> Could you therefore add:
> It is particularly hard to escape argument portably on all the POSIX
> system, including shell variation. It is safer to allow only a
> whitelist
> of permited characters from user input, taking care to use sane IFS.
> Only alphanum character with _ @ - are believed to be safe
Do you have some supporting evidence for that last line. That's an
extremely conservative set. It excludes URLs, for instance.
Thanks,
Michael
> If you need to escape better to use execvp.
>
> Please add also a warning about IFS
>
>
>>
>> Cheers,
>>
>> Michael
>>
>> --
>> Michael Kerrisk
>> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
>> Linux/UNIX System Programming Training: http://man7.org/training/
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
Bug#882222: Document security problems with system.3 and popen.3 (argument injection)
On Wed, Nov 22, 2017 at 2:45 PM, Michael Kerrisk (man-pages)
wrote:
>> Could you also warn about popen ?
>
> I already added a cross reference from popen(3) to the Caveats section
> in system(3). I should have mentioned that before.
>
>> And mention that system(sprintf("command %s")) is a security hole
>
> That seems obviously dangerous. But don't you think it is covered by this
> text:
>
>Any user input that is employed as part of command should be care‐
>fully sanitized, to ensure that unexpected shell commands or com‐
>mand options are not executed. Such risks are especially grave
>when using system() from a privileged program.
> ?
Yes but does not avoid tentation do use escape character
>
>> BTW escaping char is hard with shell, better to use execvp
>
> Agreed. I would not attempt escaping. Safer to allow only a whitelist
> of permited characters from user input.
Could you therefore add:
It is particularly hard to escape argument portably on all the POSIX
system, including shell variation. It is safer to allow only a
whitelist
of permited characters from user input, taking care to use sane IFS.
Only alphanum character with _ @ - are believed to be safe.
If you need to escape better to use execvp.
Please add also a warning about IFS
>
> Cheers,
>
> Michael
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/
Bug#882222: Document security problems with system.3 and popen.3 (argument injection)
> Could you also warn about popen ?
I already added a cross reference from popen(3) to the Caveats section
in system(3). I should have mentioned that before.
> And mention that system(sprintf("command %s")) is a security hole
That seems obviously dangerous. But don't you think it is covered by this text:
Any user input that is employed as part of command should be care‐
fully sanitized, to ensure that unexpected shell commands or com‐
mand options are not executed. Such risks are especially grave
when using system() from a privileged program.
?
> BTW escaping char is hard with shell, better to use execvp
Agreed. I would not attempt escaping. Safer to allow only a whitelist
of permited characters from user input.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
Bug#882222: Document security problems with system.3 and popen.3 (argument injection)
On Wed, Nov 22, 2017 at 10:58 AM, Michael Kerrisk (man-pages)
wrote:
> Hello Tobias, and Bastien,
>
> On 22 November 2017 at 09:52, Dr. Tobias Quathamer wrote:
>> control: severity -1 important
>>
>> Am 20.11.2017 um 12:29 schrieb Bastien ROUCARIES:
>>> Please document the implication of system.3 and popen.3, particularly
>>> argument injection.
>> Hi,
>>
>> thanks for the bug report, I'll take this upstream
>
> I already noticed this Debian bug report, and made a few upstream
> changes. See the Caveats subsection towards the end of the current
> draft in upstream Git:
> https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/man3/system.3
> The main changes were to mention the PATH variable more explicitly and
> to note that one should carefully sanitize the input of system().
>
>> and we'll see how to
>> get this better documented. Do you have a patch ready?
>>
>> Apart from that, I've lowered the severity of this bug. I do not agree
>> with you that this missing documentation is release critical.
>
> I agree. When I look through the source code of Fedora, I see dozens,
> if not hundreds of programs using system(). And I imagine that most of
> them are doing it quite safely. I find the advice given regarding
> system() in the site that you mentioned [1] Bastien is somewhat
> overwrought. (And some of the advice there is I find bizarre[2], which
> makes me a little skeptical about the site generally.) Certainly, one
> should be careful though. (BUt the same is true of any APIs that may
> handle user-supplied input.)
Could you also warn about popen ?
And mention that system(sprintf("command %s")) is a security hole
BTW escaping char is hard with shell, better to use execvp
See private mail
>
> Cheers,
>
> Michael
>
> [1] https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=87152177
> [2] For example,
> https://wiki.sei.cmu.edu/confluence/display/c/SIG34-C.+Do+not+call+signal%28%29+from+within+interruptible+signal+handlers
> seems simply confused.
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/
Bug#882222: Document security problems with system.3 and popen.3 (argument injection)
Hello Tobias, and Bastien, On 22 November 2017 at 09:52, Dr. Tobias Quathamer wrote: > control: severity -1 important > > Am 20.11.2017 um 12:29 schrieb Bastien ROUCARIES: >> Please document the implication of system.3 and popen.3, particularly >> argument injection. > Hi, > > thanks for the bug report, I'll take this upstream I already noticed this Debian bug report, and made a few upstream changes. See the Caveats subsection towards the end of the current draft in upstream Git: https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/man3/system.3 The main changes were to mention the PATH variable more explicitly and to note that one should carefully sanitize the input of system(). > and we'll see how to > get this better documented. Do you have a patch ready? > > Apart from that, I've lowered the severity of this bug. I do not agree > with you that this missing documentation is release critical. I agree. When I look through the source code of Fedora, I see dozens, if not hundreds of programs using system(). And I imagine that most of them are doing it quite safely. I find the advice given regarding system() in the site that you mentioned [1] Bastien is somewhat overwrought. (And some of the advice there is I find bizarre[2], which makes me a little skeptical about the site generally.) Certainly, one should be careful though. (BUt the same is true of any APIs that may handle user-supplied input.) Cheers, Michael [1] https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=87152177 [2] For example, https://wiki.sei.cmu.edu/confluence/display/c/SIG34-C.+Do+not+call+signal%28%29+from+within+interruptible+signal+handlers seems simply confused. -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
Bug#882222: Document security problems with system.3 and popen.3 (argument injection)
control: severity -1 important Am 20.11.2017 um 12:29 schrieb Bastien ROUCARIES: > Please document the implication of system.3 and popen.3, particularly > argument injection. Hi, thanks for the bug report, I'll take this upstream and we'll see how to get this better documented. Do you have a patch ready? Apart from that, I've lowered the severity of this bug. I do not agree with you that this missing documentation is release critical. Regards, Tobias signature.asc Description: OpenPGP digital signature
Bug#882222: Document security problems with system.3 and popen.3 (argument injection)
Package: manpages-dev Version: 4.13-3 Severity: grave Tags: security X-Debbugs-CC: secure-testing-t...@lists.alioth.debian.org Justification: more than 20 security bugs filled in other package control: clone -1 -2 control: reaffect -2 glibc-doc Please document the implication of system.3 and popen.3, particularly argument injection. Please get inspiration from ENV33-C. Do not call system() Sugest to use execvp and please provide example of secure alternative for both API Note that escaping argument is not portable particularly if argument include control char for a POSIX shell. https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=87152177 Use of the system() function can result in exploitable vulnerabilities, in the worst case allowing execution of arbitrary system commands. Situations in which calls to system() have high risk include the following: When passing an unsanitized or improperly sanitized command string originating from a tainted source If a command is specified without a path name and the command processor path name resolution mechanism is accessible to an attacker If a relative path to an executable is specified and control over the current working directory is accessible to an attacker If the specified executable program can be spoofed by an attacker
