Bug 715172

This still needs review. I updated the package version, splitted it on package/module base.
https://build.opensuse.org/package/show?package=connman&project=home%3AT_UNIX%3Amisc

got lost somehow :-(

Will have a look. Quite some code...

There are several problems:

1. I need a polkit policy config to check against; the small
   snippet that comes with it should probably not be used.

2. connmann seems to have its own builtin security checks/framework,
   but in most cases falls back to PolicyKit, as the builtin security
   functions are not defined in the table

3. It uses its own PolicyKit/DBUS glue code, which uses the old PolicyKit
   DBUS which is probably not suitable for us (we want to drop that and use
   the new polkit). [Needs verification, whether this isnt just fallback
   code]

4. Which plugins/parts will be enabled? There are lots of it, including own
   dhcp client/server.

5. connmann seem to not check origin of netlink messages (check nlmsg_pid
   being == 0) which allows to complete blowup

6. One plugin allows to call sethostname(2) with passed argument. Need to
   make sure that this doesnt allow to set hostname that contains
   shell metas, as a lot of shell scripts rely on sanitized hostname.
   A filter should be added and policy must forbid hostname setting by user.

For #6: It seems like the hostname option is parsed from
remote DHCP replies and passed to the loopback plugin set_hostname()
function w/o any character filtering. Thats equal to a remote root
exploit.

lease_available_cb():
    [...]
    option = g_dhcp_client_get_option(dhcp_client, G_DHCP_HOST_NAME);
    if (option != NULL)
          hostname = g_strdup(option->data);
    [...]
    __connman_utsname_set_hostname(hostname)
        -calls-> driver->set_hostname(hostname)  [iterates over all drivers]

The dhcp is requesting the hostname by default:

dhcp_request():
 [...]
 g_dhcp_client_set_request(dhcp_client, G_DHCP_HOST_NAME)
 [...]

so it will be in the list of options that is parsed when
a reply arrives in get_request(). I've seen no character filtering so
far; its all handled as plain string.

Compare to CVE-2011-0996 CVE-2011-0997 which was exactly that bug
in dhclient and ISC dhcpcd.

I checked their 0.84 version (you have 0.76 in your repo) but it
seems that the bug is still there; they just added dhcpv6 support.

I contacted upstream about the netlink and hostname issue.

The dhcpv6_get_option() DHCPv6 option parsing is vulnerable
to a DoS (endless loop) as len is uint16_t and can wrap to 0
(user input from packet), the while(1) loop is never left as
the pointer is advanced by len (==0) and the remaining bytes
is decreased by 0 too.

I also wonder about the use of GKeyFile (glib's config file framework).
VPN settings etc. can be saved in such key-stores, but everything
must be checked for the separator token; otherwise you can add
arbitrary (and might be policy-forbidden) data to the store.

Additionally, the saving of that provider/VPN data to a file inside
__connman_storage_save_provider() relies on the provider 'identifier'
which is a

  ident = g_strdup_printf("%s_%s", host, domain);

and may contain '../' and '_' itself (if its not checked in the DBUS
function?).

Now, the __connman_storage_save_provider() constructs the storage
directory as


  dirname = g_strdup_printf("%s/%s_%s", STORAGEDIR,
                        "provider", identifier);

So, you can first crate a identifier like 'a_b' (host=a, domain=b) and then one 
of 'a_b/../../../tmp/foo' (host=a, domain='b/../[...]foo')
to dump any data to the settings file inside /tmp/foo directory, which
is of course a symlink to /etc/passwd.

Made bug publically visible, contacted upstream and asked
for comments.

netlink issue: CVE-2012-2320
hostname issue: CVE-2012-2321
dhcp6 DoS: CVE-2012-2322

waiting for settings file overwrite to be confirmed

comment#10 is a non issue, as been clarified by upstream.
provider_dbus_ident() substitutes special chars with '_'.

I'm also interested in this package as it has been integrated to E17 I'm packaging.

Should I file new bug for this?

Yes, please do so and also reference this bug there.
Assign to security-team.
I guess theres need to re-check the code (polkit config at least)
as theres probably
new version. No guarantee that we can handle this quickly, as there
are already a lot of important AUDIT requests opened.