IBus broken after updating glib2 2.80.1

[akiirui]

Please fill in the following items if you don't know the root cause.

Which distribution and version?:

• Arch Linux

Which desktop environment and version?:

• GNOME 46.1

Which session type?:

• Wayland

Which application and version?:

• glib2 2.80.1

IBus version?:

• IBus 1.5.30

Issue description:

See CVE-2024-34397 https://gitlab.gnome.org/GNOME/glib/-/issues/3268.
Received GetNameOwner reply with invalid owner "org.freedesktop.IBus" for "org.freedesktop.IBus"

Steps to reproduce:

1. Update glib2 to 2.80.1
2. Restart
3. IBus not work and see log Received GetNameOwner reply with invalid owner "org.freedesktop.IBus" for "org.freedesktop.IBus"

Can you reproduce your problem when you restart ibus-daemon? (yes / no):

• Yes

Do you see any errors when you run ibus-daemon with the verbose option?

• (ibus-ui-gtk3:38001): GLib-GIO-WARNING **: 07:35:37.908: Received GetNameOwner reply with invalid owner "org.freedesktop.IBus" for "org.freedesktop.IBus"

Can you reproduce your problem with a new user account instead of the current your account? (yes / no):

• Yes

[fujiwarat]

(ibus-ui-gtk3:38001): GLib-GIO-WARNING **: 07:35:37.908: Received GetNameOwner reply with invalid owner "org.freedesktop.IBus" for "org.freedesktop.IBus"

Do you receive the warning message from ibus-ui-gtk3 only?
ibus-ui-gtk3 should not be used in GNOME desktop because GNOME provides the owned panel icon so you should run ibus-daemon --panel disable &

[akiirui]

Do you receive the warning message from ibus-ui-gtk3 only?

No, I get warning messages from all applications with input entry, such as gnome-shell, nautilus, chromium...

[fujiwarat]

No, I get warning messages from all applications with input entry, such as gnome-shell, nautilus, chromium...

Can you please paste the warning messages?

[akiirui]

No, I get warning messages from all applications with input entry, such as gnome-shell, nautilus, chromium...

Can you please paste the warning messages?

journalctl -b | rg -i ibus
May 08 00:28:26 akii /usr/lib/gdm-wayland-session[752]: dbus-daemon[752]: [session uid=120 pid=752] Activating service name='org.freedesktop.portal.IBus' requested by ':1.26' (uid=120 pid=1008 comm="ibus-daemon --panel disable")
May 08 00:28:26 akii /usr/lib/gdm-wayland-session[752]: dbus-daemon[752]: [session uid=120 pid=752] Successfully activated service 'org.freedesktop.portal.IBus'
May 08 00:28:26 akii gnome-shell[765]: Received GetNameOwner reply with invalid owner "org.freedesktop.IBus" for "org.freedesktop.IBus"
May 08 00:28:26 akii /usr/lib/gdm-wayland-session[752]: dbus-daemon[752]: [session uid=120 pid=752] Activating service name='org.freedesktop.portal.IBus' requested by ':1.35' (uid=120 pid=1157 comm="ibus-daemon --panel disable -r --xim")
May 08 00:28:26 akii gnome-shell[765]: Received GetNameOwner reply with invalid owner "org.freedesktop.IBus" for "org.freedesktop.IBus"
May 08 00:28:26 akii /usr/lib/gdm-wayland-session[752]: dbus-daemon[752]: [session uid=120 pid=752] Successfully activated service 'org.freedesktop.portal.IBus'
May 08 00:28:31 akii systemd[1263]: Starting IBus Daemon for GNOME...
May 08 00:28:31 akii systemd[1263]: Started IBus Daemon for GNOME.
May 08 00:28:31 akii systemd[1263]: Created slice Slice /app/dbus-:1.2-org.freedesktop.portal.IBus.
May 08 00:28:31 akii systemd[1263]: Started dbus-:1.2-org.freedesktop.portal.IBus@0.service.
May 08 00:28:31 akii gnome-shell[1374]: Received GetNameOwner reply with invalid owner "org.freedesktop.IBus" for "org.freedesktop.IBus"
May 08 00:28:39 akii chromium[1893]: Received GetNameOwner reply with invalid owner "org.freedesktop.IBus" for "org.freedesktop.IBus"

[smcv]

Received GetNameOwner reply with invalid owner "org.freedesktop.IBus" for "org.freedesktop.IBus"

Does ibus use G_DBUS_CONNECTION_FLAGS_MESSAGE_BUS_CONNECTION for its own reimplementation of the D-Bus message bus that does not follow the D-Bus Specification, or something like that?

On a spec-compliant message bus, each connection has exactly one unique name which starts with : (typically :1.23), and zero or more well-known names which do not (for example com.example.Foo). For each well-known name like com.example.Foo, if the name has an owner, it is a unique name like :1.23.

The only exception to this is that org.freedesktop.DBus is a special name representing the message bus itself, and behaves like a unique name (in particular it is its own owner).

After fixing CVE-2024-34397, GLib enforces those rules - but if ibus is doing something weird here then that enforcement might need to be relaxed.

[pwithnall]

The problem can be reproduced simply by running the following command when IBus is enabled:

$ gdbus call --address "$(ibus address)" --dest org.freedesktop.DBus -o /org/freedesktop/DBus -m org.freedesktop.DBus.GetNameOwner 'org.freedesktop.IBus'
('org.freedesktop.IBus',)

If IBus were following the D-Bus specification, the return value would look like (':1.23',) (a unique name) instead.

By contrast, if the bus daemon on the session bus is asked what unique name owns org.freedesktop.IBus, it gives a correct response:

$ gdbus call --session --dest org.freedesktop.DBus -o /org/freedesktop/DBus -m org.freedesktop.DBus.GetNameOwner 'org.freedesktop.IBus'
(':1.52',)

[pwithnall]

The reply to GetNameOwner for org.freedesktop.IBus is hardcoded here:

ibus/bus/dbusimpl.c

Line 789 in 4059b9f

g_strcmp0 (name, "org.freedesktop.IBus") == 0) {

This code appears to originate from before at least 13 years ago, when IBus was ported from libdbus to GDBus.

[smcv]

GLib 2.80.2 and 2.78.6 work around this by allowing the owner of a well-known name to be a well-known name, but it's still weird, and it would be better if ibus behaved more like a normal message bus.

[fujiwarat]

OK, I see.
My understanding is CVE-2024-34397 indicates the hard-coded "org.freedesktop.IBus" name can be a security issue and ":1.1" or ":org.freedesktop.IBus" too.
I guess IBus needs to decide a random name likes ":1.32423" and needs to send it to the registered D-Bus clients as the IBus destination.

[fujiwarat]

However ibus-daemon has already implemented bus_authorize_authenticated_peer_cb() in server.c to check the same user id and I guess the CVE's concern is not applied to IBus.

[pwithnall]

My understanding is CVE-2024-34397 indicates the hard-coded "org.freedesktop.IBus" name can be a security issue and ":1.1" or ":org.freedesktop.IBus" too.
I guess IBus needs to decide a random name likes ":1.32423" and needs to send it to the registered D-Bus clients as the IBus destination.

Not really. There are two issues in IBus related to this, but as far as I know neither of them are security issues.

The first issue is that IBus returns org.freedesktop.IBus from GetNameOwner() when the D-Bus Specification requires it to instead return a unique bus name.

The second issue is that IBus sets org.freedesktop.IBus as the SENDER header for various signals (see this comment and this comment for a list). The D-Bus Specification requires it to set a unique bus name as the SENDER; as in the first issue, org.freedesktop.IBus is not a unique bus name as it doesn’t follow the form :1.23.

Simon’s suggestion of reserving :0.0 as the unique bus name corresponding to the well-known org.freedesktop.IBus bus name makes sense. That could be implemented by building on top of my draft MR and changing all the g_dbus_message_set_sender (…, "org.freedesktop.IBus") calls to g_dbus_message_set_sender (…, ":0.0").

A more systematic solution which adds a mapping between org.freedesktop.IBus and :0.0 and tracks it as its own BusConnection and BusNameService, rather than hard-coding the behaviour of org.freedesktop.IBus in every method in dbusimpl.c, would probably be better in the long term, but that’s a bigger change to make.

[fujiwarat]

If reserving :0.0 is allowed for this issue, I think :org.freedesktop.IBus also works since g_dbus_is_unique_name() works for the name? It checks the first ":" and alphabet or number.

[smcv]

If reserving :0.0 is allowed for this issue, I think :org.freedesktop.IBus also works since g_dbus_is_unique_name() works for the name? It checks the first ":" and alphabet or number.

I believe that would be valid according to the D-Bus Specification and accepted by GDBus.

I can't guarantee that all other D-Bus implementations that might interact with ibus follow the spec. It's possible that there is an implementation that assumes that unique names always fit the pattern used in the reference dbus-daemon (which is basically ":%u.%u"). I think that would be a bug in those D-Bus implementations, but a regression is a regression.

[fujiwarat]

@smcv Thank you for your advice. I agree with you.

[fujiwarat]

I craated #2643 thx.