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 br
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
P
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
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
alrea
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 p
> 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 teststring
> 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 situ
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() do
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 "$(perl
17 matches
Mail list logo
