The `iodine-client-start` script in the iodine package sources
`/etc/default/iodine-client` as root and then uses values from it as shell
commands without quoting.

The relevant lines:

```bash
line 156:  . \${iodine_client_rc}
line 269:  ifup interface || {continue_on_error}
line 334:  ip -4 route add \${n}/32 via router || {continue_on_error}
line 346:  iodine \({iodine_opts} -P "\){passwd}" "subdomain" ||
{continue_on_error}
line 372: \${continue_on_error}
line 393:  ip -4 route add default via \({tunnel_remote}
\vert{}\vert{}\){continue_on_error}
```

Because `continue_on_error` is executed as a command, setting it in the
config to anything like `id` runs it as root when a previous command fails.
Other variables like `interface`, `testhost`, `router`, and `mtu` are also
unquoted, so a malformed config can break commands or inject extra
arguments.

PoC:

Add this to `/etc/default/iodine-client`:

```bash
continue_on_error='id'
```

Then run:

```bash
sudo iodine-client-start
```

When any command fails, `id` runs as root.

This means anyone who can write to `/etc/default/iodine-client` can
escalate to root. The fix is to quote all variables and not use
`continue_on_error` as a command.

I am reporting this privately first and can wait 60–90 days before
publishing details. If Debian confirms and assigns a CVE, I would like it
credited to Badr Azeez.

Thanks,
Badr Azeez

There is no privilege escalation. /e/d/iodine-client is correctly
writable only by root:

# ls -la /etc/default/iodine
-rw------- 1 root root 137 Sep  1 13:32 /etc/default/iodine

Thus any "escalation" would be from root to root, and thus not
crossing a security boundary.

I doubt you know what you are doing when you mail the Debian BTS.

Closing.
Chris