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. Please check the following PoC: whoopsie_killer.py
** Attachment removed: "memory leak poc" https://bugs.launchpad.net/ubuntu/+source/whoopsie/+bug/1881982/+attachment/5380170/+files/memory_leak_poc.py ** Attachment added: "whoopsie_killer.py" https://bugs.launchpad.net/ubuntu/+source/whoopsie/+bug/1881982/+attachment/5384875/+files/whoopsie_killer.py -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to whoopsie in Ubuntu. https://bugs.launchpad.net/bugs/1881982 Title: memory exhaustion in parse_report() Status in whoopsie package in Ubuntu: New Bug 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/whoopsie/+bug/1881982/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
