** Changed in: whoopsie (Ubuntu)
     Assignee: Alex Murray (alexmurray) => Marc Deslauriers (mdeslaur)

-- 
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:
  DoS vulnerability: cause resource exhaustion

Status in whoopsie package in Ubuntu:
  Confirmed

Bug description:
  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,

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

Reply via email to