[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cad6e3380e53431ae91d5a3b520e59a59043ab90@opteya.com>
Date: Wed, 21 Dec 2022 18:13:50 +0000
From: "Yann Droneaud" <ydroneaud@...eya.com>
To: oss-security@...ts.openwall.com
Subject: Re: [Linux] /proc/pid/stat parsing bugs
Hi,
21 décembre 2022 à 18:59 "Demi Marie Obenour" <demi@...isiblethingslab.com> a écrit:
> On Wed, Dec 21, 2022 at 06:13:17PM +0100, Dmitry Vyukov wrote:
>
> >
> > Hello,
> >
> > This is not a single vulnerability, the list of affected software is
> > large, but it's not a security issue for all of it.
> >
> > It occurred to me that most of the Linux procfs /proc/pid/stat and
> > /proc/pid/task/tid/stat parsing code out there is buggy. The fine
> > contains a set of numbers about the task:
> > https://man7.org/linux/man-pages/man5/proc.5.html
> >
> > e.g. $ cat /proc/self/stat
> > 1715376 (cat) R 1544883 1715376 1544883 34819 1715376 4194304 106 0 0
> > 0 0 0 0 0 20 0 1 0 42505561 9207808 237 18446744073709551615
> > 93955355631616 93955355651497 140737444557056 0 0 0 0 0 0 0 0 0 17 36
> > 0 0 0 0 0 93955355667504 93955355669120 93955385581568 140737444559745
> > 140737444559765 140737444559765 140737444564971 0
> >
> > Most of the code splits it by space and takes an N-th field.
> > The problem is that the process name "(cat)" can contain spaces (and
> > brackets). Potentially some important software (containers/sandboxes)
> > can be tricked into getting wrong data, and I've seen cases close to
> > stack overflows (buffer for a fixed number of fields is allocated on
> > stack).
> >
> > Some examples:
> > OpenJDK:
> > https://sourcegraph.com/github.com/openjdk/jdk/-/blob/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c?L133-139
> > https://sourcegraph.com/github.com/openjdk/jdk8u/-/blob/jdk/src/solaris/native/sun/management/OperatingSystemImpl.c?L223-229
> >
> > Ansible:
> > https://sourcegraph.com/github.com/ansible/ansible/-/blob/lib/ansible/modules/yum.py?L507-510
> >
> > Libuv:
> > https://sourcegraph.com/github.com/libuv/libuv/-/blob/src/unix/linux.c?L674-701
> >
> > bdwgc:
> > https://sourcegraph.com/github.com/mono/linux-packaging-mono/-/blob/external/bdwgc/os_dep.c?L1138-1155
> >
> > But really most of the code that does it:
> > https://sourcegraph.com/search?q=context:global+/%5C%22%5C/proc%5C/.*%5C/stat%5C%22/
> >
> > The only way to parse it is to do strrchr(')') first (fortunately it
> > contains just one unescaped string).
> >
> > Thanks
> >
>
> Should Linux be patched to somehow escape the spaces, or replace them
> with something else? /proc/pid/status is even harder to parse robustly.
It might be difficult because of Linux's policy to not break userspace ABI.
For example, I've suggested some sort of escaping on /proc/net/unix, and
it was not welcomed.
https://lore.kernel.org/all/20220406102213.2020784-1-ydroneaud@opteya.com/
In a follow up, I've added a PoC for injecting fake entries in /proc/net/unix
https://lore.kernel.org/all/8a87957e-4d33-9351-ae74-243441cb03cd@opteya.com/
I didn't found a way to abuse this issue: no vulnerability, no need for
a change that would break userspace ABI.
Regards.
--
Yann Droneaud
OPTEYA
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.
