[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH8yC8=p9a71AohbLtKGzb8d8yzBYyCADUJ1xthddQsyFbdSRA@mail.gmail.com>
Date: Thu, 29 Dec 2022 13:36:52 -0500
From: Jeffrey Walton <noloader@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: [patch] proc.5: tell how to parse /proc/*/stat correctly
On Thu, Dec 29, 2022 at 12:58 PM David A. Wheeler <dwheeler@...eeler.com> wrote:
>
> > On Dec 29, 2022, at 11:43 AM, Alan Coopersmith <alan.coopersmith@...cle.com> wrote:
>
> Another solution is to escape bytes that might cause trouble in this field, e.g., using %xx hexadecimal.
> So space would be %20, ")" would be %41, control characters 1-31 would be %01 to %1f,
> and (of course) "%" would be encoded as %25.
> Basically, URL-encode / Percent-encode them. See: https://en.wikipedia.org/wiki/Percent-encoding
Would you need a full blown encoder?
I was thinking along those lines, but pick a delimiter and only encode
the delimiter when it is present in the data. For example, use the
pipe as a delimiter.
Encoding the space character alone when it is present in the data may
also work. Once a string is parsed based on whitespace, decode the
percent-encoded spaces in the field.
Using \0 as the delimiter would still require encoding of \0 when it
is present in the data.
I guess the question is, do parsers need control characters (<= 0x1f)
encoded or not? If existing parsers can currently handle control
characters, then a full blown encoder may not be needed.
> Technically this would be a userspace change, but only in cases where the system
> would probably have done the wrong thing previously. It's okay if we break *attacker* workflows
> as long as we don't break others'. An advantage of URL encoding is that,
> like JSON, it's a well-known format. I might do something different if this was a new system,
> but that seems like the least-impact approach while eliminating the problem.
I know David did not suggest JSON, but please, no JSON. Use a simple
encoder/decoder like URL-encoding. A URL encoder is easy to implement
in C. JSON is more complex, and developers would probably want/need a
third-party library to do it. There's no sense in gratuitously
broadening the dependency tree.
Jeff
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.
