Access permissions in rpcd and uhttpd

[Jo-Philipp Wich]

Hi Hauke,

> We got multiple security reports related to missing access 
> permissions and I do not know if this is expected to be like this.

Unauthenticated `/list` access is expected in the sense that it has
intentionally behaved this way for many years. That does not
automatically mean the behavior is ideal, and I have no objection to
gating it behind authentication like the other methods.

What I would like to avoid, though, is treating every long-standing
implementation choice as if it were a newly discovered security
vulnerability. This is neither a regression nor broken logic; it is
simply how the gateway functionality was originally designed.

> uhttpd has basic authentication support, this is not the login used 
> by OpenWrt, but it allows to protect some folders. This 
> authentication only works for files, but not for file handlers like
> the rpcd endpoint.
> 
> Should we do something like this: 
> https://github.com/openwrt/uhttpd/pull/31/changes

As you already pointed out yourself, HTTP Basic Auth in uhttpd is an
optional feature which is not used by default in OpenWrt. Because of
that, the proposed change would not affect the default deployment model
and therefore would not address the reported issue in practice.

> https://github.com/openwrt/uhttpd/security/advisories/GHSA-5cgm-8h9x-v28c
 > The auth code in uhttpd was very buggy.

I also think we should be careful with wording such as "very buggy".

The advisory essentially describes a mismatch between an operator's
expectations and the implementation. One can certainly argue that the
current Basic Auth semantics are unintuitive or differ from those of
other HTTP servers, and that changing them would improve consistency.
That does not automatically make the existing behavior a security bug.

Basic Auth in uhttpd has always applied to static file serving. Script
handlers have historically been expected to implement their own
authentication model where appropriate. Whether that design is optimal
is a separate discussion from whether it constitutes a vulnerability.

More generally, I've noticed an increasing number of reports that start
from an implementation detail or surprising behavior and then build
increasingly elaborate deployment scenarios around it to argue for a
security classification or CVE. While these reports are often
technically detailed, they do not necessarily demonstrate a violation of
the intended security model or a vulnerability in realistic OpenWrt
deployments.

A considerable share of the recently reported issues also revolve around
deployment models that are technically supported but not representative
of how OpenWrt is used by default. For example, many reports assume
deployments making use of restricted ubus ACLs for non-root users. That
is a perfectly valid configuration, and we should certainly fix issues
in that area where practical, but it is worth keeping in mind that the
default OpenWrt deployment still operates management services in a root
context. As a result, many of these reports describe edge-case
configurations rather than vulnerabilities affecting out-of-the-box systems.

Similarly, there are reports that ultimately boil down to "a less
privileged user who can already modify a configuration file can
influence a command or script that is later executed by a privileged
service". In many cases, that is less an isolated vulnerability than a
consequence of long-standing configuration and process interaction
patterns across multiple packages. Addressing those properly would
require broader architectural changes rather than narrowly fixing a
single code path.

Reviewing, discussing and validating increasingly long advisories
consumes a non-trivial amount of maintainer time. I would much rather
see the effort invested in understanding the root cause, proposing a
concrete fix, or even submitting an RFC pull request. That is ultimately
what helps maintainers improve the project. Advisory write-ups have
their place, but they should support the engineering work rather than
become the primary deliverable.

I also think the recent rise of AI-assisted reporting has amplified this
trend. It has become much cheaper to produce lengthy, convincing-looking
advisories around relatively minor implementation details or non-default
deployment scenarios. While that undoubtedly increases the number of
reports, it also increases the review burden on maintainers.
Increasingly, it feels like this process serves the visibility and
credibility of the reporter more than it helps maintainers identify and
fix genuine security issues.

Best,
Jo