REDHAT-BUG-2440301: SQL Injection

Description

The addressbook file backend implementation in e-book-backend-file.c manages contact photo and logo files stored on disk. When a contact is created or modified, inline image data is converted to a file on disk and the vCard is updated with a file URI pointing to the stored file. When a contact is deleted or its image changes, the old file is removed from disk. Both the PHOTO and LOGO vCard fields go through this same code path. Two different functions implement security checks on these URIs, using inconsistent comparison logic. During contact creation and modification, maybetransformvcardfieldforphoto() calls isbackendowneduri() to determine whether an incoming URI belongs to the backend. This function extracts the directory component with gpathgetdirname() and performs an exact match against the photo directory using strcmp():

dirname = gpathgetdirname (filename); owneduri = bf->priv->photodirname && (strcmp (dirname, bf->priv->photodirname) == 0);

A URI containing ../ sequences will not match, so isbackendowneduri() returns FALSE. The URI is then stored verbatim in the SQLite database without transformation. During contact deletion, bookbackendfileremovecontactssync() calls maybedeleteunuseduris(), which retrieves the stored URIs for both the ECONTACTPHOTO and ECONTACTLOGO fields via checkremoveuriforfield() and passes each to maybedeleteuri(). This function performs a prefix match on the raw, unresolved path using strncmp():

if (bf->priv->photodirname && !strncmp (bf->priv->photodirname, filename, strlen (bf->priv->photodirname))) { d (gprint ("Deleting uri file: %s\n", filename)); / Deleting uris should not cause the backend to fail to update a contact so the best we can do from here is log warnings when we fail to unlink a file from the disk. / if (!removefile (filename, &error)) { gwarning ("Unable to cleanup photo uri: %s", error->message); gerrorfree (error); } }

Since strncmp() only checks that the path starts with the photo directory, a URI containing ../ sequences after the prefix will pass this check. The removefile() function then calls gunlink(), which resolves the ../ sequences, deleting the traversed target file. Because maybedeleteunuseduris() processes both fields independently, a single contact can be used to delete two arbitrary files in one operation. The Evolution backend server exposes the D-Bus service org.gnome.evolution.dataserver.AddressBook, that can be used in order to manage contacts. A Flatpak application with access to this D-Bus service can exploit this issue in order to gain arbitrary file deletion on the host filesystem. A simple proof of concept script shhowcasing this issue can be found in the attached file. Impact

A Flatpak application with D-Bus access to the addressbook service can delete arbitrary files on the host, potentially including Flatpak override files, which are typically used to remove permissions at varying levels of granularity, from app-specific to user- or system-wide. Recommended solution

Canonicalize the file path in maybedeleteuri() using realpath() before performing the prefix comparison, ensuring that ../ sequences are resolved.