Bug 1728632 (CVE-2019-13012) - CVE-2019-13012 glib2: insecure permissions for files and directories
Summary: CVE-2019-13012 glib2: insecure permissions for files and directories
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2019-13012
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1728633 1728727 1728730
Blocks: 1728635
TreeView+ depends on / blocked
 
Reported: 2019-07-10 10:30 UTC by Dhananjay Arunesh
Modified: 2021-05-18 14:33 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-05-18 14:33:48 UTC
Embargoed:


Attachments (Terms of Use)

Description Dhananjay Arunesh 2019-07-10 10:30:01 UTC
The keyfile settings backend in GNOME GLib (aka glib2.0) before 2.59.1 creates
directories using g_file_make_directory_with_parents (kfsb->dir, NULL, NULL) and
files using g_file_replace_contents (kfsb->file, contents, length, NULL, FALSE,
G_FILE_CREATE_REPLACE_DESTINATION, NULL, NULL, NULL). Consequently, it does not
properly restrict directory (and file) permissions. Instead, for directories,
0777 permissions are used; for files, default file permissions are used. This is
similar to CVE-2019-12450.

Reference:
https://gitlab.gnome.org/GNOME/glib/issues/1658

Upstream commit:
https://gitlab.gnome.org/GNOME/glib/commit/5e4da714f00f6bfb2ccd6d73d61329c6f3a08429

Comment 1 Dhananjay Arunesh 2019-07-10 10:30:30 UTC
Created glib2 tracking bugs for this issue:

Affects: fedora-all [bug 1728633]

Comment 2 Kalev Lember 2019-07-10 11:28:31 UTC
Fedora 30 has glib2 2.60.4 in the stable updates repo (and 2.60.5 in updates-testing) that has this already fixed.

Comment 9 Marco Benatto 2019-07-11 13:45:07 UTC
Statement:

This issue affects glib2 as shipped with Red Hat Enterprise Linux 6, 7 and 8 and was rated as having a Low security impact by Red Hat Product Security team.

Although Red Hat Enterprise Linux versions above ships the vulnerable code the flaw itself is not currently exploitable due to the presence of another glib2 bug (rhbz#1728896).
This bug avoid glib's 'keyfile' module to be loaded at glib2 initialization, thus the vulnerable code is currently unreachable.

Red Hat Enterprise Linux 6 is now in Maintenance Support 2 Phase of the support and maintenance life cycle. This has been rated as having a security impact of Low, and is not currently planned to be addressed in future updates. For additional information, refer to the Red Hat Enterprise Linux Life Cycle: https://access.redhat.com/support/policy/updates/errata/.

For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.

Comment 10 Marco Benatto 2019-07-11 14:11:06 UTC
glib2 provides several backend types to handling configuration files in custom applications or shipped configuration utilities (such as gsettings).
One of these backends is called keyfile, which basically consists in a key-value text file used to stored the desired configuration entries.
Currently keyfile backend has a vulnerability when creating the output file's parent directory and the file itself, where both are created with insecure permissions. This flaw may end up allowing an attacker to read and write to the target file under certain circumstances causing confidentiality and integrity issues.

It's important to notice the fact of currently the flaw is not exploitable on the affected Red Hat Enterprise Linux versions using any packaged applications due to the presence of bz1728896, which prevents the 'keyfile' module to be loaded during glib2's initialization process.

Comment 12 errata-xmlrpc 2021-05-18 13:26:48 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2021:1586 https://access.redhat.com/errata/RHSA-2021:1586

Comment 13 Product Security DevOps Team 2021-05-18 14:33:48 UTC
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):

https://access.redhat.com/security/cve/cve-2019-13012


Note You need to log in before you can comment on or make changes to this bug.