Access permissions in rpcd and uhttpd

[Enrico Mioso]

On Sun, Jul 19, 2026 at 10:12:55PM +0200, Jo-Philipp Wich wrote:
> 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

I totally agree with you, Jo-Philipp. That said, probably less informations we give out to an authenticated user, the better it is.
But it's an API change, and I admittedly don't know what is relying on such a behaviour.

Best regards,
Enrico
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel