On 6/28/26 13:54, Jo-Philipp Wich wrote:
Hi,
many of the LuCI reported issues are systemic and not easily fixable, if
at all.
They roughly fall into four categories:
1) simple shell injection; many packages ship ad-hoc rpcd ubus plugins
which
provide methods that end up calling various commands to scrape info
from,
passing user input as shell arguments without proper escaping -
commonly
in the form 'fs.popen(`/usr/bin/somecomannd ${some_ubus_arg}`)'
which is
a textbook injection; I'll fix these case by case and work on an
improved
popen() implementation in ucode which takes an array command vector to
make it easier to write safe code, e.g.
`fs.popen(['/usr/bin/somecommand', some_ubus_arg])`
2) stored XSS; external sources or saved uci values providing some kind of
freetext description field (e.g. DHCP hostnames, UPnP lease
descriptions)
which are then output as-is without additional HTML escaping,
leading to
XSS. I'll fix these case by case.
3) stored command privilege escalation; many packages support specifying
arbitrary command hooks in their uci configuration. Even if a
restricted
user context is set up which is only allowed to read and write the uci
configuration of a particular package (e.g. ddns-scripts), the
restricted
user can set an arbitrary command (e.g. ddns-scripts `ip_script`
option)
which ends up being executed as root by the packages init script or
some
event handler. These class of bugs cannot be reasonably fixed in
LuCI and
require a general rearchitecturing of the backend package, e.g. by
dropping
support for command hooks, using restricted user contexts, some sort of
jailing, pre-approved whitelists etc.
4) newline injections; many init script implementations translate uci to
native configuration without actually validating the values,
allowing users
to plant uci values which end up being written as additional
options, e.g.
`option 'foo' 'value\nbar value2'` would be written as
foo = value
bar = value2
into the ephemeral native configuration, allowing a uci write
privileged
user to inject arbitrary native settings, even those deliberately
left out
from uci for e.g. security reasons. If a process happens to support
options
taking shell commands to excecute or files to read from/write to,
chances
are high that those end up getting executed as root on the next service
restart.
While class 1 and 2 issues are simple web develpoment things we have to
take care of, class 3 and 4 ones are systemic problems which require a
concerted effort in the entire OpenWrt and packages ecosystem to solve.
Fixing those entails migrating packages to non-root users, jailing,
restructuring configuration, auditing uci translations, introducing safe
by default behavior (e.g. let config_get fail for values with newlines/
other problematic chars and introduce a config_get_unsafe or similar for
those rare cases where such values are allowed.
Regards,
Jo
Hi Jo,
Thank you for looking into the reports.
I saw that you fixed some problems on the master branch, could you
please cherry pick them to the 25.12 branch too, I would like to tag the
next release soon and would like to include as many fixes as we have.
Hauke
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
