control: tags -1 +fixed-upstream
[2019-03-20 13:50] Jesse Smith
> I have removed the "-f" flag for formatting (and the custom string
> substitution patch). It has been replaced by the patch from KatolaZ
> which allows for a custom field separator. This has been applied
> upstream in the 2.95
I have removed the "-f" flag for formatting (and the custom string
substitution patch). It has been replaced by the patch from KatolaZ
which allows for a custom field separator. This has been applied
upstream in the 2.95 branch.
- Jesse
[2019-03-19 16:15] KatolaZ
> On Tue, Mar 19, 2019 at 03:36:41PM +0100, Matteo Croce wrote:
> > Hi all,
> >
> > I have an idea: implement an option to specify the default separator as
> > in propcs-ng:
> >
> > https://gitlab.com/procps-ng/procps/commit/73492b182dc60c1605d1b0d62de651fad97807af
On 3/19/19 7:28 PM, KatolaZ wrote:
> On Tue, Mar 19, 2019 at 05:54:56PM -0300, Jesse Smith wrote:
>> I am certainly open to replacing the "format" flag (-f) with an
>> alternative field separator flag. It has a nice Unixy feel to it and
>> requires less code.
>>
>> Personally, I think using -d (or
On Tue, Mar 19, 2019 at 05:54:56PM -0300, Jesse Smith wrote:
> I am certainly open to replacing the "format" flag (-f) with an
> alternative field separator flag. It has a nice Unixy feel to it and
> requires less code.
>
> Personally, I think using -d (or --delimiter) might be the only change
>
I am certainly open to replacing the "format" flag (-f) with an
alternative field separator flag. It has a nice Unixy feel to it and
requires less code.
Personally, I think using -d (or --delimiter) might be the only change
I'd want to make to the patch KatolaZ provided. Partly because pidof
On Tue, Mar 19, 2019 at 03:36:41PM +0100, Matteo Croce wrote:
> Hi all,
>
> I have an idea: implement an option to specify the default separator as
> in propcs-ng:
>
> https://gitlab.com/procps-ng/procps/commit/73492b182dc60c1605d1b0d62de651fad97807af
>
> $ pidof bash
> 17701 14019 5276
Hi all,
I have an idea: implement an option to specify the default separator as
in propcs-ng:
https://gitlab.com/procps-ng/procps/commit/73492b182dc60c1605d1b0d62de651fad97807af
$ pidof bash
17701 14019 5276 2967
$ pidof -S, bash
17701,14019,5276,2967
$ pidof -S'
On Mon, Mar 18, 2019 at 05:10:36PM -0300, Jesse Smith wrote:
> I have been playing around with this a little and believe I have come up
> with a workable solution. The attached patch causes the passed in format
> string to be dumbed down so that we only translate instances of %d into
> the PID and
Hi Jesse,
I didn't try the patch myself, but this seems a good tradeoff between
functionality and security: I think that -f was used only to separate
the PIDs by something different than a space, eg. comma or new line, so
it's all covered.
ACK
--
Matteo Croce
per aspera ad upstream
I have been playing around with this a little and believe I have come up
with a workable solution. The attached patch causes the passed in format
string to be dumbed down so that we only translate instances of %d into
the PID and \n into newline characters. Everything else is treated as a
literal
> What's the attack vector here (making this an exploit rather than
> "just" a bug)?
>
I didn't investigate too much, but with a trivial brute force I can add
%hhd at will until I dump what I need from the stack:
$ arg='[%d '; until ./pidof -f "$arg] mem: %s" pidof teststring |grep
-q
> Wouldn't you need to have some process which was passing untrusted data
> directly to the `-f` argument, is that likely in the real world?
It may not be likely, but anything that makes a command line tool crash
or output weird data after being fed unfiltered command line input is
not a good
On Sun, 2019-03-17 at 19:06 +0100, Matteo Croce wrote:
> #571590 added the '-f' argument to pidof, which allows to specify an
> arbitrary format string for the PIDs.
> Unfortunately this is broken, because passing plain user input to
> printf() can easily exploited:
What's the attack vector here
> This is a good find and I see two fairly straight forward ways to deal
> with the bug:
>
> 1. We can drop the new -f flag. This is a little inconvenient for some
> users, but immediately plugs the hole.
>
That's an option, even if it would break existing scripts which use -f,
if any. Probably
This is a good find and I see two fairly straight forward ways to deal
with the bug:
1. We can drop the new -f flag. This is a little inconvenient for some
users, but immediately plugs the hole.
2. We can write our own print function that will not crash or give weird
behaviour the way printf()
Package: sysvinit-utils
Version: 2.93-8
Severity: normal
Dear Maintainer,
#571590 added the '-f' argument to pidof, which allows to specify an
arbitrary format string for the PIDs.
Unfortunately this is broken, because passing plain user input to
printf() can easily exploited:
$ pidof -f
17 matches
Mail list logo
