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