CVSS: 7.5EPSS: 0%CPEs: 1EXPL: 0CVE-2019-13012 – glib2: insecure permissions for files and directories
https://notcve.org/view.php?id=CVE-2019-13012
The keyfile settings backend in GNOME GLib (aka glib2.0) before 2.60.0 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. La back-end de configuración de keyfile en GLib (también se conoce como glib2.0) anterior a versión 2.60.0 de GNOME, crea directorios usando g_file_make_directory_with_parents (kfsb-)dir, NULL, NULL) y archivos utilizando g_file_replace_contents (kfsb-)file, contents, length, NULL, FALSE, G_FILE_CREATE_REPLACE_DESTINATION, NULL, NULL, NULL). • http://lists.opensuse.org/opensuse-security-announce/2019-07/msg00022.html https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931234#12 https://gitlab.gnome.org/GNOME/glib/commit/5e4da714f00f6bfb2ccd6d73d61329c6f3a08429 https://gitlab.gnome.org/GNOME/glib/issues/1658 https://gitlab.gnome.org/GNOME/glib/merge_requests/450 https://lists.apache.org/thread.html/r58af02e294bd07f487e2c64ffc0a29b837db5600e33b6e698b9d696b%40%3Cissues.bookkeeper.apache.org%3E https://lists.apache.org/thread.html/rf4c02775860db415b4955778a131c2795223f61cb8c6a45089365 • CWE-732: Incorrect Permission Assignment for Critical Resource •
CVSS: 9.8EPSS: 1%CPEs: 21EXPL: 0CVE-2019-12450 – glib2: file_copy_fallback in gio/gfile.c in GNOME GLib does not properly restrict file permissions while a copy operation is in progress
https://notcve.org/view.php?id=CVE-2019-12450
file_copy_fallback in gio/gfile.c in GNOME GLib 2.15.0 through 2.61.1 does not properly restrict file permissions while a copy operation is in progress. Instead, default permissions are used. La función file_copy_fallback en el archivo gio/gfile.c en GNOME GLib versión 2.15.0 hasta la 2.61.1, no restringe apropiadamente los permisos de los archivos durante una operación de copia en progreso. En su lugar, se utilizan los permisos por defecto. • http://lists.opensuse.org/opensuse-security-announce/2019-06/msg00076.html https://access.redhat.com/errata/RHSA-2019:3530 https://gitlab.gnome.org/GNOME/glib/commit/d8f8f4d637ce43f8699ba94c9b7648beda0ca174 https://lists.debian.org/debian-lts-announce/2019/06/msg00013.html https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/2W4WIOAGO3M743M5KZLVQZM3NGHQDYLI https://security.netapp.com/advisory/ntap-20190606-0003 https://usn.ubuntu.com/4014-1 https://usn.ubuntu.com/4014- • CWE-276: Incorrect Default Permissions CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') CWE-552: Files or Directories Accessible to External Parties •
CVSS: 5.0EPSS: 0%CPEs: 257EXPL: 0CVE-2012-0039
https://notcve.org/view.php?id=CVE-2012-0039
GLib 2.31.8 and earlier, when the g_str_hash function is used, computes hash values without restricting the ability to trigger hash collisions predictably, which allows context-dependent attackers to cause a denial of service (CPU consumption) via crafted input to an application that maintains a hash table. NOTE: this issue may be disputed by the vendor; the existence of the g_str_hash function is not a vulnerability in the library, because callers of g_hash_table_new and g_hash_table_new_full can specify an arbitrary hash function that is appropriate for the application. ** DISPUTADA ** GLib 2.31.8 y anteriores, cuando la función g_str_hash está utilizada, calcula los valores hash sin restringir la capacidad de provocar colisiones previsibles, lo que permite a atacantes dependientes de contexto causar una denegación de servicio (consumo de CPU) a través de entradas manipuladas en una aplicación que mantiene una tabla hash. NOTA: este problema lo puede disputar el proveedor, la existencia de la función g_str_hash no se tarta de una vulnerabilidad en la librería, porque llamadores de g_hash_table_new y g_hash_table_new_full pueden especificar una función hash arbitraria que sea apropiada para la aplicación. • http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=655044 http://mail.gnome.org/archives/gtk-devel-list/2003-May/msg00111.html http://openwall.com/lists/oss-security/2012/01/10/12 https://bugzilla.redhat.com/show_bug.cgi?id=772720 • CWE-310: Cryptographic Issues •