Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y6XcJ+tcf1Cg1jkZ@momentum.pseudorandom.co.uk>
Date: Fri, 23 Dec 2022 16:49:43 +0000
From: Simon McVittie <smcv@...ian.org>
To: oss-security@...ts.openwall.com
Subject: Re: [Linux] /proc/pid/stat parsing bugs

On Thu, 22 Dec 2022 at 10:04:48 -0500, Shawn Webb wrote:
> We knew way back then the dangers of VFS-based wizardry. Did we lose
> that knowledge somehow?

To me this seems like a parsing problem, not a VFS problem. Some
pseudo-files in Linux /proc are one file per item (/proc/self/oom_adj,
/proc/self/sessionid, most of /proc/sys) and those are fine[1]: the
structure is implicit in the filesystem layout, and the file contents
are trivial to "parse". Others have a simple and well-defined format
(like /proc/self/environ and /proc/self/cmdline, which are sequences of
\0-terminated bytestrings), and those also seem fine.

It's the pseudo-files that contain more than one item, particularly
those with a semi-consistent format that aims for human-readability, that
can easily get into escaping and parsing issues. If those pseudo-files
made *more* use of the VFS (one new file in /proc/self for each field
in the current /proc/self/stat?) then they would suffer from different
issues instead, like inability to read all fields atomically and maybe
performance issues for heavy users, but parsing would become a non-issue.

    smcv

[1] or when they're not fine, the issues are around things like how to
    separate an AppArmor enforcement mode from the label, which again is
    a matter of parsing a human-readable format with structure

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.