(Cross-posting from distributor-list.)
Today we’re releasing a fix for an issue in g_file_replace(). See this issue for the details, and these two merge requests for the fixes for GLib master (2.67.x series) and GLib 2.66:
- https://gitlab.gnome.org/GNOME/glib/-/issues/2325
- https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1981
- https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1982
GLib release series 2.66 (stable) and 2.67 (development) are vulnerable. It’s likely that versions <2.66 are also vulnerable, but these have not been tested.
The fixes have just been merged into GLib, and will be available in the upcoming 2.67.6 and 2.66.8 releases, due later this week.
The fix concerns use of g_file_replace() with the G_FILE_CREATE_REPLACE_DESTINATION flag set. When replacing a file which is actually a dangling symlink, the target of the symlink will be created as an empty file, and then the symlink itself will be replaced with the new file. The bug is the creation of the empty file; in
situations where the symlink is under the control of an attacker, the attacker can get a more-privileged process to create empty files at chosen locations.
Thanks to Yiğit Can Yılmaz, Ondrej Holy, Sebastian Dröge and Emmanuele Bassi for their efforts on this.