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 > [email protected] > https://lists.openwrt.org/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
