[OpenWrt-Devel] Security implications for consideration [Was: Re: [openwrt/openwrt] rpcd: add respawn param]

Petr Štetiar ynezz at true.cz
Wed Mar 4 04:26:08 EST 2020

LEDE Commits <lede-commits at lists.infradead.org> [2020-03-04 03:17:06]:


sorry for such late post-review :-), but I've somehow missed it previously
(probably because of commit subject?), just noticed it now via content of Jo's
commit email.

> jow pushed a commit to openwrt/openwrt.git, branch openwrt-19.07:
> Author: Florian Eckert <fe at dev.tdt.de>
>     rpcd: add respawn param
>     The rpcd service is an important service, 

It is _very_ important, because it's available by default in releases and
exposed to network.

> but if the service stops working for any reason, no one will ever respawn
> that service. 

The issue should be rather reported and fixed.

> With this commit, the procd service will monitor if the rpcd service is
> running. If the rpcd service has crashed, then procd respawns the rpcd
> service.

I simply would like to bring one important aspect for consideration. 

By respawning any network facing service indefinitely we're giving adversary
infinite attempts for figuring out the way in, decreasing the purpose of
(expensive) ASLR etc. See "Remotely Compromising an iPhone through
iMessage"[1] (48:41) for real world example.

I think, that the previous default (max 5 restarts?) was good enough, ideally
the timeout should be exponential in between those 5 restarts and I wouldn't
mind if the restart count was set to 0 by default.

> diff --git a/package/system/rpcd/files/rpcd.init b/package/system/rpcd/files/rpcd.init
> index 77ebcbe6cb..b1061b906c 100755
> --- a/package/system/rpcd/files/rpcd.init
> +++ b/package/system/rpcd/files/rpcd.init
> @@ -12,6 +12,7 @@ start_service() {
>  	procd_open_instance
>  	procd_set_param command "$PROG" ${socket:+-s "$socket"} ${timeout:+-t "$timeout"}
> +	procd_set_param respawn ${respawn_retry:-0}

IMHO this is probably not correct as well, that respawn param is "array" of
[threshold, timeout, retry] params, so this probably sets `respawn_threshold` to
0, not `respawn_retry` as intended.

1. https://media.ccc.de/v/36c3-10497-messenger_hacking_remotely_compromising_an_iphone_through_imessage

-- ynezz

openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list