Access permissions in rpcd and uhttpd

[Hauke Mehrtens]

On 7/19/26 22:12, 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.

This is the reason I bring this up on the public mailing list. I would 
prefer to convert this private security report into a normal issue.

>> 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".

We fixed multiple problems in this code in the last few months. I do not 
think it was used often.

> 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.
I agree with you on that. I assume most of these reports are found by 
AIs, they get some harness and then look at all the features the code 
provides.

I send this mail to the public mailing list because I want such a 
discussion. I do not think these are big problems we have to manage in 
private and then release in a coordinated way.

I am using AI to read the security reports. It is also pretty good at 
judging if it is a real problem or a design decision we did many years ago.

We should get these reports out of our security report flow. The 
security flow takes too much time. I already switched to publish public 
PRs for security issues which were reported in private now.

I think we should either decline such reports and suggest people to 
create a PR or issue ticket or convert the security reports into public 
tickets ourself. If they become public tickets they probably get ignored 
by most us, but at least the design is documented.

Hauke