| 2020-06-04 00:50:09 |
Seong-Joong Kim |
bug |
|
|
added bug |
| 2020-06-04 00:50:09 |
Seong-Joong Kim |
attachment added |
|
memory leak poc https://bugs.launchpad.net/bugs/1881982/+attachment/5380170/+files/memory_leak_poc.py |
|
| 2020-06-10 05:13:45 |
Seong-Joong Kim |
attachment added |
|
g_hash_table_memory_leak.patch https://bugs.launchpad.net/ubuntu/+source/whoopsie/+bug/1881982/+attachment/5382293/+files/g_hash_table_memory_leak.patch |
|
| 2020-06-10 06:38:12 |
Seong-Joong Kim |
description |
Hi,
I have found a security issue on whoopsie 0.2.69 and earlier.
## Vulnerability in whoopsie
- whoopsie 0.2.69 and earlier have a memory leak vulnerability.
- An attacker can cause a denial of service (application crash) via a crafted .crash file.
## Basic
When a program has been crashed, Linux system tries to create a '.crash' file on '/var/crash/' directory with python script located in '/usr/share/apport/apport'.
The file contains a series of system crash information including core dump, syslog, stack trace, memory map info, etc.
A user is given read and write permission to the file.
After then, whoopsie parses key-value pairs in ‘.crash’ file and encodes it into binary json (bson) format.
Lastly, whoopsie forwards the data to a remotely connected Ubuntu error report system.
## Vulnerability
We have found a memory leak vulnerability during the parsing the crash file, when a collision occurs on GHashTable through g_hash_table_insert().
According to [1], if the key already exists in the GHashTable, its current value is replaced with the new value.
If 'key_destory_func' and 'value_destroy_func' are supplied when creating the table, the old value and the passed key are freed using that function.
Unfortunately, whoopsie does not handle the old value and the passed key when collision happens.
If a crash file contains same repetitive key-value pairs, it leads to memory leak as much as the amount of repetition and results in denial-of-service.
## Attack
1) Create a fake.crash file
memory_leak_poc.py script measures an available memory and generates a malicious crash file that contains same repetitive key-value pairs as much as 20% of the available memory size; 'ProblemType: Crash'.
The reason for 20% is that we just check the memory leakage.
2) Before the attack, it checks memory usage of whoopsie process with psutil
3) It triggers the whoopsie to read the fake.crash file
4) Then, it measures the memory usage of whoopsie process
5) It results in denial-of-service and then other users can no longer report crash to the Ubuntu error report system.
## Mitigation
We should use g_hash_table_new_full() with ‘key_destroy_func’ and ‘value_destroy_func’ functions instead of g_hash_table_new().
Otherwise, before g_hash_table_insert(), we should check the collision via g_hash_table_lookup_extended() and obtain pointer to the old value and remove it.
Sincerely,
[1] https://developer.gnome.org/glib/stable/glib-Hash-Tables.html#g-hash-table-insert |
Hi,
I have found a security issue on whoopsie 0.2.69 and earlier.
## Vulnerability in whoopsie
- whoopsie 0.2.69 and earlier have a memory leak vulnerability.
- An attacker can cause a denial of service (application crash) via a crafted .crash file.
## Basic
When a program has been crashed, Linux system tries to create a '.crash' file on '/var/crash/' directory with python script located in '/usr/share/apport/apport'.
The file contains a series of system crash information including core dump, syslog, stack trace, memory map info, etc.
A user is given read and write permission to the file.
After then, whoopsie parses key-value pairs in ‘.crash’ file and encodes it into binary json (bson) format.
Lastly, whoopsie forwards the data to a remotely connected Ubuntu error report system.
## Vulnerability
We have found a memory leak vulnerability during the parsing the crash file, when a collision occurs on GHashTable through g_hash_table_insert().
According to [1], if the key already exists in the GHashTable, its current value is replaced with the new value.
If 'key_destory_func' and 'value_destroy_func' are supplied when creating the table, the old value and the passed key are freed using that function.
Unfortunately, whoopsie does not handle the old value and the passed key when collision happens.
If a crash file contains same repetitive key-value pairs, it leads to memory leak as much as the amount of repetition and results in denial-of-service.
## Attack
1) Create a fake.crash file
memory_leak_poc.py script measures an available memory and generates a malicious crash file that contains same repetitive key-value pairs as much as 20% of the available memory size; 'ProblemType: Crash'.
20% indicates arbitrary amount of the memory leakage.
2) Before the attack, the script checks memory usage of whoopsie process with psutil
3) It triggers the whoopsie to read the fake.crash file
4) Then, it measures the memory usage of whoopsie process
5) It results in denial-of-service and then other users can no longer report crash to the Ubuntu error report system.
## Mitigation
We should use g_hash_table_new_full() with ‘key_destroy_func’ and ‘value_destroy_func’ functions instead of g_hash_table_new().
Otherwise, before g_hash_table_insert(), we should check the collision via g_hash_table_lookup_extended() and obtain pointer to the old value and remove it.
Sincerely,
[1] https://developer.gnome.org/glib/stable/glib-Hash-Tables.html#g-hash-table-insert |
|
| 2020-06-11 01:43:50 |
Seong-Joong Kim |
information type |
Private Security |
Public Security |
|
| 2020-06-11 04:22:49 |
Ubuntu Foundations Team Bug Bot |
tags |
|
patch |
|
| 2020-06-11 04:22:55 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Review Team |
| 2020-06-11 07:50:55 |
Sebastien Bacher |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2020-06-13 07:26:34 |
Mathew Hodson |
whoopsie (Ubuntu): importance |
Undecided |
Medium |
|
| 2020-06-16 01:58:35 |
Seong-Joong Kim |
summary |
Memory leak in parse_report() |
memory exhaustion in parse_report() |
|
| 2020-06-16 02:13:31 |
Seong-Joong Kim |
description |
Hi,
I have found a security issue on whoopsie 0.2.69 and earlier.
## Vulnerability in whoopsie
- whoopsie 0.2.69 and earlier have a memory leak vulnerability.
- An attacker can cause a denial of service (application crash) via a crafted .crash file.
## Basic
When a program has been crashed, Linux system tries to create a '.crash' file on '/var/crash/' directory with python script located in '/usr/share/apport/apport'.
The file contains a series of system crash information including core dump, syslog, stack trace, memory map info, etc.
A user is given read and write permission to the file.
After then, whoopsie parses key-value pairs in ‘.crash’ file and encodes it into binary json (bson) format.
Lastly, whoopsie forwards the data to a remotely connected Ubuntu error report system.
## Vulnerability
We have found a memory leak vulnerability during the parsing the crash file, when a collision occurs on GHashTable through g_hash_table_insert().
According to [1], if the key already exists in the GHashTable, its current value is replaced with the new value.
If 'key_destory_func' and 'value_destroy_func' are supplied when creating the table, the old value and the passed key are freed using that function.
Unfortunately, whoopsie does not handle the old value and the passed key when collision happens.
If a crash file contains same repetitive key-value pairs, it leads to memory leak as much as the amount of repetition and results in denial-of-service.
## Attack
1) Create a fake.crash file
memory_leak_poc.py script measures an available memory and generates a malicious crash file that contains same repetitive key-value pairs as much as 20% of the available memory size; 'ProblemType: Crash'.
20% indicates arbitrary amount of the memory leakage.
2) Before the attack, the script checks memory usage of whoopsie process with psutil
3) It triggers the whoopsie to read the fake.crash file
4) Then, it measures the memory usage of whoopsie process
5) It results in denial-of-service and then other users can no longer report crash to the Ubuntu error report system.
## Mitigation
We should use g_hash_table_new_full() with ‘key_destroy_func’ and ‘value_destroy_func’ functions instead of g_hash_table_new().
Otherwise, before g_hash_table_insert(), we should check the collision via g_hash_table_lookup_extended() and obtain pointer to the old value and remove it.
Sincerely,
[1] https://developer.gnome.org/glib/stable/glib-Hash-Tables.html#g-hash-table-insert |
Hi,
I have found a security issue on whoopsie 0.2.69 and earlier.
## Vulnerability in whoopsie
- It was discovered that whoopsie incorrectly handled certain malformed crash files. If a user using whoopsie were tricked into parsing and uploading a specially crafted crash file, an attacker could exploit this to cause a denial of service.
## Basic
When a program has been crashed, Linux system tries to create a '.crash' file on '/var/crash/' directory with python script located in '/usr/share/apport/apport'.
The file contains a series of system crash information including core dump, syslog, stack trace, memory map info, etc.
A user is given read and write permission to the file.
After then, whoopsie parses key-value pairs in ‘.crash’ file and encodes it into binary json (bson) format.
Lastly, whoopsie forwards the data to a remotely connected Ubuntu error report system.
## Vulnerability
We have found a memory leak vulnerability during the parsing the crash file, when a collision occurs on GHashTable through g_hash_table_insert().
According to [1], if the key already exists in the GHashTable, its current value is replaced with the new value.
If 'key_destory_func' and 'value_destroy_func' are supplied when creating the table, the old value and the passed key are freed using that function.
Unfortunately, whoopsie does not handle the old value and the passed key when collision happens.
If a crash file contains same repetitive key-value pairs, it leads to memory leak as much as the amount of repetition and results in denial-of-service.
## Attack
1) Generates a certain malformed crash file that contains same repetitive key-value pairs.
2) Trigger the whoopsie to read the generated crash file.
3) After then, the whoopsie process has been killed.
## Mitigation
We should use g_hash_table_new_full() with ‘key_destroy_func’ and ‘value_destroy_func’ functions instead of g_hash_table_new().
Otherwise, before g_hash_table_insert(), we should check the collision via g_hash_table_lookup_extended() and obtain pointer to the old value and remove it.
Sincerely,
[1] https://developer.gnome.org/glib/stable/glib-Hash-Tables.html#g-hash-table-insert |
|
| 2020-06-18 01:21:24 |
Seong-Joong Kim |
attachment removed |
memory leak poc https://bugs.launchpad.net/ubuntu/+source/whoopsie/+bug/1881982/+attachment/5380170/+files/memory_leak_poc.py |
|
|
| 2020-06-18 01:24:44 |
Seong-Joong Kim |
attachment added |
|
whoopsie_killer.py https://bugs.launchpad.net/ubuntu/+source/whoopsie/+bug/1881982/+attachment/5384875/+files/whoopsie_killer.py |
|
| 2020-06-19 05:52:43 |
Seong-Joong Kim |
bug |
|
|
added subscriber Mathew Hodson |
| 2020-06-19 06:41:19 |
Seong-Joong Kim |
description |
Hi,
I have found a security issue on whoopsie 0.2.69 and earlier.
## Vulnerability in whoopsie
- It was discovered that whoopsie incorrectly handled certain malformed crash files. If a user using whoopsie were tricked into parsing and uploading a specially crafted crash file, an attacker could exploit this to cause a denial of service.
## Basic
When a program has been crashed, Linux system tries to create a '.crash' file on '/var/crash/' directory with python script located in '/usr/share/apport/apport'.
The file contains a series of system crash information including core dump, syslog, stack trace, memory map info, etc.
A user is given read and write permission to the file.
After then, whoopsie parses key-value pairs in ‘.crash’ file and encodes it into binary json (bson) format.
Lastly, whoopsie forwards the data to a remotely connected Ubuntu error report system.
## Vulnerability
We have found a memory leak vulnerability during the parsing the crash file, when a collision occurs on GHashTable through g_hash_table_insert().
According to [1], if the key already exists in the GHashTable, its current value is replaced with the new value.
If 'key_destory_func' and 'value_destroy_func' are supplied when creating the table, the old value and the passed key are freed using that function.
Unfortunately, whoopsie does not handle the old value and the passed key when collision happens.
If a crash file contains same repetitive key-value pairs, it leads to memory leak as much as the amount of repetition and results in denial-of-service.
## Attack
1) Generates a certain malformed crash file that contains same repetitive key-value pairs.
2) Trigger the whoopsie to read the generated crash file.
3) After then, the whoopsie process has been killed.
## Mitigation
We should use g_hash_table_new_full() with ‘key_destroy_func’ and ‘value_destroy_func’ functions instead of g_hash_table_new().
Otherwise, before g_hash_table_insert(), we should check the collision via g_hash_table_lookup_extended() and obtain pointer to the old value and remove it.
Sincerely,
[1] https://developer.gnome.org/glib/stable/glib-Hash-Tables.html#g-hash-table-insert |
Hi,
I have found a security issue on whoopsie 0.2.69 and earlier.
# Vulnerability description
The parse_report() function in whoopsie.c allows attackers to cause a denial of service (memory leak) via a crafted file.
Exploitation of this issue causes excessive memory consumption which results in the Linux kernel triggering OOM killer on arbitrary process.
This results in the process being terminated by the OOM killer.
# Details
We have found a memory leak vulnerability during the parsing the crash file, when a collision occurs on GHashTable through g_hash_table_insert().
According to [1], if the key already exists in the GHashTable, its current value is replaced with the new value.
If 'key_destory_func' and 'value_destroy_func' are supplied when creating the table, the old value and the passed key are freed using that function.
Unfortunately, whoopsie does not handle the old value and the passed key when collision happens.
If a crash file contains same repetitive key-value pairs, it leads to memory leak as much as the amount of repetition and results in denial-of-service.
[1] https://developer.gnome.org/glib/stable/glib-Hash-Tables.html#g-hash-table-insert
# PoC (*Please check the below PoC: whoopsie_killer.py)
1) Generates a certain malformed crash file that contains same repetitive key-value pairs.
2) Trigger the whoopsie to read the generated crash file.
3) After then, the whoopsie process has been killed.
# Mitigation (*Please check the below patch: g_hash_table_memory_leak.patch)
We should use g_hash_table_new_full() with ‘key_destroy_func’ and ‘value_destroy_func’ functions instead of g_hash_table_new().
Otherwise, before g_hash_table_insert(), we should check the collision via g_hash_table_lookup_extended() and obtain pointer to the old value and remove it.
Sincerely, |
|
| 2020-06-19 06:41:27 |
Seong-Joong Kim |
summary |
memory exhaustion in parse_report() |
DoS vulnerability: cause resource exhaustion |
|
| 2020-07-06 15:39:33 |
Leonidas S. Barbosa |
whoopsie (Ubuntu): status |
New |
Confirmed |
|
| 2020-07-06 15:39:45 |
Leonidas S. Barbosa |
whoopsie (Ubuntu): assignee |
|
Alex Murray (alexmurray) |
|
| 2020-07-06 18:04:24 |
Mathew Hodson |
removed subscriber Mathew Hodson |
|
|
|
| 2020-07-09 12:42:59 |
Marc Deslauriers |
whoopsie (Ubuntu): assignee |
Alex Murray (alexmurray) |
Marc Deslauriers (mdeslaur) |
|
| 2020-07-09 13:14:26 |
Marc Deslauriers |
nominated for series |
|
Ubuntu Bionic |
|
| 2020-07-09 13:14:26 |
Marc Deslauriers |
bug task added |
|
whoopsie (Ubuntu Bionic) |
|
| 2020-07-09 13:14:26 |
Marc Deslauriers |
nominated for series |
|
Ubuntu Groovy |
|
| 2020-07-09 13:14:26 |
Marc Deslauriers |
bug task added |
|
whoopsie (Ubuntu Groovy) |
|
| 2020-07-09 13:14:26 |
Marc Deslauriers |
nominated for series |
|
Ubuntu Xenial |
|
| 2020-07-09 13:14:26 |
Marc Deslauriers |
bug task added |
|
whoopsie (Ubuntu Xenial) |
|
| 2020-07-09 13:14:26 |
Marc Deslauriers |
nominated for series |
|
Ubuntu Focal |
|
| 2020-07-09 13:14:26 |
Marc Deslauriers |
bug task added |
|
whoopsie (Ubuntu Focal) |
|
| 2020-07-09 13:14:26 |
Marc Deslauriers |
nominated for series |
|
Ubuntu Eoan |
|
| 2020-07-09 13:14:26 |
Marc Deslauriers |
bug task added |
|
whoopsie (Ubuntu Eoan) |
|
| 2020-07-09 13:14:32 |
Marc Deslauriers |
whoopsie (Ubuntu Xenial): status |
New |
Confirmed |
|
| 2020-07-09 13:14:34 |
Marc Deslauriers |
whoopsie (Ubuntu Bionic): status |
New |
Confirmed |
|
| 2020-07-09 13:14:36 |
Marc Deslauriers |
whoopsie (Ubuntu Eoan): status |
New |
Confirmed |
|
| 2020-07-09 13:14:38 |
Marc Deslauriers |
whoopsie (Ubuntu Focal): status |
New |
Confirmed |
|
| 2020-07-09 13:14:40 |
Marc Deslauriers |
whoopsie (Ubuntu Xenial): importance |
Undecided |
Medium |
|
| 2020-07-09 13:14:41 |
Marc Deslauriers |
whoopsie (Ubuntu Bionic): importance |
Undecided |
Medium |
|
| 2020-07-09 13:14:43 |
Marc Deslauriers |
whoopsie (Ubuntu Eoan): importance |
Undecided |
Medium |
|
| 2020-07-09 13:14:45 |
Marc Deslauriers |
whoopsie (Ubuntu Focal): importance |
Undecided |
Medium |
|
| 2020-07-09 13:14:47 |
Marc Deslauriers |
whoopsie (Ubuntu Xenial): assignee |
|
Marc Deslauriers (mdeslaur) |
|
| 2020-07-09 13:14:48 |
Marc Deslauriers |
whoopsie (Ubuntu Bionic): assignee |
|
Marc Deslauriers (mdeslaur) |
|
| 2020-07-09 13:14:50 |
Marc Deslauriers |
whoopsie (Ubuntu Eoan): assignee |
|
Marc Deslauriers (mdeslaur) |
|
| 2020-07-09 13:14:52 |
Marc Deslauriers |
whoopsie (Ubuntu Focal): assignee |
|
Marc Deslauriers (mdeslaur) |
|
| 2020-07-09 23:17:25 |
Seth Arnold |
cve linked |
|
2020-11937 |
|
| 2020-07-10 15:53:28 |
Kai Kasurinen |
bug |
|
|
added subscriber Kai Kasurinen |
| 2020-08-04 17:08:17 |
Launchpad Janitor |
whoopsie (Ubuntu Focal): status |
Confirmed |
Fix Released |
|
| 2020-08-04 17:08:17 |
Launchpad Janitor |
cve linked |
|
2020-12135 |
|
| 2020-08-04 17:08:17 |
Launchpad Janitor |
cve linked |
|
2020-15570 |
|
| 2020-08-04 17:08:20 |
Launchpad Janitor |
whoopsie (Ubuntu Xenial): status |
Confirmed |
Fix Released |
|
| 2020-08-04 17:18:23 |
Launchpad Janitor |
whoopsie (Ubuntu Bionic): status |
Confirmed |
Fix Released |
|
| 2020-08-07 16:15:19 |
Launchpad Janitor |
whoopsie (Ubuntu Groovy): status |
Confirmed |
Fix Released |
|
| 2020-08-18 16:59:54 |
Brian Murray |
whoopsie (Ubuntu Eoan): status |
Confirmed |
Won't Fix |
|
| 2021-01-22 21:20:49 |
Launchpad Janitor |
branch linked |
|
lp:whoopsie |
|
