Re: Questionable CVE's reported against dnsmasq

[Collin Funk <collin.funk1 () gmail com>]

Hi Russ,

Russ Allbery <eagle () eyrie org> writes:

> Solar Designer <solar () openwall com> writes:
>
> > I don't think a "check that the config file is root-owned and not
> > user-writable" would be relevant since a maybe-relevant threat model
> > involves config files intentionally created by other software such as a
> > web UI, which would set permissions such that the file is processed, and
> > since such checks are uncommon and the lack of them does not mean the
> > software supports untrusted config files.
>
> > Other than that, I see that this gets tricky for a CNA to evaluate
> > without input from the maintainers, so I may have been unnecessarily
> > harsh on VulDB.
>
> This is a bit of an "ask the Lazyweb" question since I have done only
> minimal research, but is there any way for me to declare, as the software
> maintainer, what I consider to be the security boundaries of the software
> in a way that can be at least partially machine-readable? I know there are
> tons of modeling languages for *building* software, imposing or checking
> access control, etc., but is there a way for me to *label* a free software
> project to communicate information such as "edit access to the
> configuration file is arbitrary code execution by design"?

If it makes you feel better, I do not think it is an "ask the Lazyweb"
question. I actually had the same question.

There is a recent example in GNU Tar CVE-2025-45582 [1] which describes
a situation that has been described in the manual for 15 years. Copying
the relevant text from the manual [2]:

    When extracting from two or more untrusted archives, each one should
    be extracted independently, into different empty
    directories. Otherwise, the first archive could create a symbolic
    link into an area outside the working directory, and the second one
    could follow the link and overwrite data that is not under the
    working directory. For example, when restoring from a series of
    incremental dumps, the archives should have been created by a
    trusted process, as otherwise the incremental restores might alter
    data outside the working directory.

There seems to have been agreement to change this longstanding behavior,
but the CVE situation seems to have been handled very sloppily. The CVE
was assigned on 2025-07-11, and the GNU Tar mantainers did not know
about it until 2025-08-07 when a third party inquired about it on
list [3]. Presumably upon scanning a container or something like
that.

Collin

[1] https://nvd.nist.gov/vuln/detail/CVE-2025-45582
[2] https://www.gnu.org/software/tar/manual/html_node/Integrity.html
[3] https://lists.gnu.org/archive/html/bug-tar/2025-08/msg00000.html