[Touch-packages] [Bug 1881982] Re: memory exhaustion in parse_report()

2020-06-19 Thread Seong-Joong Kim
** Description changed:

  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. 
+ # 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.
  
- ## 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
+ # 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.
  
- ## Attack
+ [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
+ 
+ # 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,
- 
- [1] https://developer.gnome.org/glib/stable/glib-Hash-Tables.html#g
- -hash-table-insert

** Summary changed:

- memory exhaustion in parse_report()
+ DoS vulnerability: cause resource exhaustion

-- 
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:
  New

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 

[Touch-packages] [Bug 1881982] Re: memory exhaustion in parse_report()

2020-06-17 Thread Seong-Joong Kim
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


[Touch-packages] [Bug 1872560] Re: integer overflow in whoopsie 0.2.69

2020-06-17 Thread Seong-Joong Kim
I am utilizing the 8GB of RAM and pre-compiled version of Ubuntu 18.04.

Could you tell me how much ram do you have in that machine?

-- 
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/1872560

Title:
  integer overflow in whoopsie 0.2.69

Status in whoopsie package in Ubuntu:
  Confirmed

Bug 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 heap-based buffer overflow 
vulnerability. 
  - An attacker can cause a denial of service (memory corruption and 
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.
  After the creation of '.crash' file, whoopsie extracts the above information 
from the '.crash' file and encodes it into binary json (bson) format.
  Lastly, whoopsie forwards the data to a remotely connected Ubuntu Error 
Report system.

   
  ## Vulnerability
  Unfortunately, we have found a heap-based buffer overflow vulnerability 
during the encoding, when whoopsie attempts to bsonify with crafted crash file.
  The data in '.crash' file is stored in key-value form and the whoopsie 
separately measures the length of 'key' and 'value' to allocate memory region 
during the encoding. 
  A heap-based buffer overflow can occur when an integer overflow happens on a 
variable that contains length of 'key'. 
  FYI, a issue to that raised by 'value' is well covered by performing 
exception handling.

  
@[bson.c:663][https://git.launchpad.net/ubuntu/+source/whoopsie/tree/lib/bson/bson.c?h=applied/0.2.69#n663]

  const uint32_t len = strlen( name ) + 1;

  - Integer overflow occurs when length of ‘name’ exceeds INT32_MAX value. 
  - Here, ‘name’ indicates the ‘key’ data in ‘.crash’ file.

  
@[bson.c:627][https://git.launchpad.net/ubuntu/+source/whoopsie/tree/lib/bson/bson.c?h=applied/0.2.69#n627]

  b->data = bson_realloc( b->data, new_size );

  - Unexpected small memory region is allocated due to above integer
  overflow.

  
@[bson.c:680][https://git.launchpad.net/ubuntu/+source/whoopsie/tree/lib/bson/bson.c?h=applied/0.2.69#n680]

  bson_append( b, name, len );

  - Memory corruption happens when unexpected small memory region is
  allocated.

  
  ## Attack Scenario
  1) Create a fake.crash file
  - '.crash' file is composed of the following format: 'key : value'.
  - To cause the overflow attack, the size of 'key' should be in double amount 
of INT32_MAX.
  - The size of 'value' doesn’t matter, but not zero length.

  $ python -c "print('A' * 0x + ' : ' + 'B')" > /var/crash/fake.crash
  $ cat fake.crash
  AAA … AA : B

  
  2) Trigger the whoopsie to read the fake.crash file
  - Just create 'fake.upload' file by touch command.
  - Or launch apport-gtk gui or apport-bug cli application.

  3) Check out the result
  - After a while, the whoopsie has been killed by segmentation fault.

  Sincerely,

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/whoopsie/+bug/1872560/+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


[Touch-packages] [Bug 1881982] Re: memory exhaustion in parse_report()

2020-06-15 Thread Seong-Joong Kim
** Description changed:

  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.
+ - 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) 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.
+ 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

-- 
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 

[Touch-packages] [Bug 1881982] Re: memory exhaustion in parse_report()

2020-06-15 Thread Seong-Joong Kim
** Summary changed:

- Memory leak in parse_report()
+ memory exhaustion in parse_report()

-- 
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
  - 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

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


[Touch-packages] [Bug 1881982] Re: Memory leak in parse_report()

2020-06-15 Thread Seong-Joong Kim
This vulnerability may cause a memory exhaustion vulnerability in the
function parse_report() in whoopsie.c, which allows attackers to cause a
denial of service.

-- 
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 leak 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
  - 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

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


[Touch-packages] [Bug 1881982] Re: Memory leak in parse_report()

2020-06-10 Thread Seong-Joong Kim
** Information type changed from Private Security to Public Security

-- 
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 leak 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
  - 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

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


[Touch-packages] [Bug 1876659] Re: Unhandled exception in run_hang()

2020-05-19 Thread Seong-Joong Kim
** Also affects: apport
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1876659

Title:
  Unhandled exception in run_hang()

Status in Apport:
  New
Status in apport package in Ubuntu:
  New

Bug description:
  ## Description
  When we start apport-cli without PID, an unhandled exception in apport 
2.20.11 and earlier may allow an authenticated user to potentially enable a 
denial of service via local access.

  The following command may cause an application crash due to an
  unhandled exception.

  $ apport-cli --hanging

  *** Send problem report to the developers?

  After the problem report has been sent, please fill out the form in the
  automatically opened web browser.

  What would you like to do? Your options are:
S: Send report (24.0 KB)
V: View report
K: Keep report file for sending later or copying to somewhere else
I: Cancel and ignore future crashes of this program version
C: Cancel
  Please choose (S/V/K/I/C): K
  Problem report file: /tmp/apport.apport.uc0_znhj.apport
  Traceback (most recent call last):
File "/usr/bin/apport-cli", line 387, in 
  if not app.run_argv():
File "/usr/lib/python3/dist-packages/apport/ui.py", line 690, in run_argv
  self.run_hang(self.options.pid)
File "/usr/lib/python3/dist-packages/apport/ui.py", line 410, in run_hang
  os.kill(int(pid), signal.SIGKILL)
  TypeError: int() argument must be a string, a bytes-like object or a number, 
not 'NoneType'

  
  Above command generates the following application crash file in /var/crash/ 
directory.

  ProblemType: Crash
  CurrentDesktop: ubuntu:GNOME
  Date: Sun May  3 19:09:41 2020
  ExecutablePath: /usr/bin/apport-cli
  ExecutableTimestamp: 1585099033
  InterpreterPath: /usr/bin/python3.6
  ProcCmdline: /usr/bin/python3 /usr/bin/apport-cli --hanging
  ProcCwd: /home/user/apport/bin
  ProcEnviron:
   ...
  ProcMaps:
   ...
  ProcStatus:
   ...
  PythonArgs: ['/usr/bin/apport-cli', '--hanging']
  Traceback:
   Traceback (most recent call last):
 File "/usr/bin/apport-cli", line 387, in 
   if not app.run_argv():
 File "/usr/lib/python3/dist-packages/apport/ui.py", line 690, in run_argv
   self.run_hang(self.options.pid)
 File "/usr/lib/python3/dist-packages/apport/ui.py", line 410, in run_hang
   os.kill(int(pid), signal.SIGKILL)
   TypeError: int() argument must be a string, a bytes-like object or a number, 
not 'NoneType'
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
  _LogindSession: 6

  
  Many thanks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1876659/+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


[Touch-packages] [Bug 1877023] Re: Unhandled exception in check_ignored()

2020-05-19 Thread Seong-Joong Kim
** Also affects: apport
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1877023

Title:
  Unhandled exception in check_ignored()

Status in Apport:
  New
Status in apport package in Ubuntu:
  Confirmed

Bug description:
  Hi,

  I have found a security issue on apport 2.20.11 and earlier.

  ## Vulnerability 
  apport 2.20.11 and earlier have an unhandled exception vulnerability during 
parsing apport-ignore.xml.
  An attacker can cause a denial of service (i.e., application crash) via a 
crafted apport-ignore.xml file.

  ## Description
  Reports can be suppressed by blacklisting in apport-ignore.xml.

  This is an example of apport-ignore.xml

  
  
    
    
    
  

  Unfortunately, it may cause an unhandled exception when 'mtime'
  attribute is specified as a string value, not a number like this.

  
  
    
  

  It may disrupt apport service and allow an attacker to potentially
  enable a denial of service via local access.

  The flaw lies in improper exception handling of 'mtime' attribute in
  apport-ignore.xml (see
  
https://git.launchpad.net/ubuntu/+source/apport/tree/apport/report.py?h=applied/ubuntu/devel#n1104).

  ## Log
  Here is /var/log/apport.log when the above exception occurs.

  ERROR: apport (pid 25904) Tue May  5 18:38:21 2020: Unhandled exception:
  Traceback (most recent call last):
    File "/usr/share/apport/apport", line 629, in 
  if info.check_ignored():
    File "/usr/lib/python3/dist-packages/apport/report.py", line 1082, in 
check_ignored
  if float(ignore.getAttribute('mtime')) >= cur_mtime:
  ValueError: could not convert string to float: 'string'

  Sincerely,

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1877023/+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


[Touch-packages] [Bug 1877023] Re: Unhandled exception in check_ignored()

2020-05-18 Thread Seong-Joong Kim
** Project changed: apport => apport (Ubuntu)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1877023

Title:
  Unhandled exception in check_ignored()

Status in apport package in Ubuntu:
  New

Bug description:
  Hi,

  I have found a security issue on apport 2.20.11 and earlier.

  ## Vulnerability 
  apport 2.20.11 and earlier have an unhandled exception vulnerability during 
parsing apport-ignore.xml.
  An attacker can cause a denial of service (i.e., application crash) via a 
crafted apport-ignore.xml file.

  ## Description
  Reports can be suppressed by blacklisting in apport-ignore.xml.

  This is an example of apport-ignore.xml

  
  
    
    
    
  

  Unfortunately, it may cause an unhandled exception when 'mtime'
  attribute is specified as a string value, not a number like this.

  
  
    
  

  It may disrupt apport service and allow an attacker to potentially
  enable a denial of service via local access.

  The flaw lies in improper exception handling of 'mtime' attribute in
  apport-ignore.xml (see
  
https://git.launchpad.net/ubuntu/+source/apport/tree/apport/report.py?h=applied/ubuntu/devel#n1104).

  ## Log
  Here is /var/log/apport.log when the above exception occurs.

  ERROR: apport (pid 25904) Tue May  5 18:38:21 2020: Unhandled exception:
  Traceback (most recent call last):
    File "/usr/share/apport/apport", line 629, in 
  if info.check_ignored():
    File "/usr/lib/python3/dist-packages/apport/report.py", line 1082, in 
check_ignored
  if float(ignore.getAttribute('mtime')) >= cur_mtime:
  ValueError: could not convert string to float: 'string'

  Sincerely,

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1877023/+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


[Touch-packages] [Bug 1872560] Re: integer overflow in whoopsie 0.2.69

2020-05-06 Thread Seong-Joong Kim
Sure. This issue is also reproducible with pre-compiled version of
0.2.62ubuntu0.4.

-- 
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/1872560

Title:
  integer overflow in whoopsie 0.2.69

Status in whoopsie package in Ubuntu:
  Confirmed

Bug 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 heap-based buffer overflow 
vulnerability. 
  - An attacker can cause a denial of service (memory corruption and 
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.
  After the creation of '.crash' file, whoopsie extracts the above information 
from the '.crash' file and encodes it into binary json (bson) format.
  Lastly, whoopsie forwards the data to a remotely connected Ubuntu Error 
Report system.

   
  ## Vulnerability
  Unfortunately, we have found a heap-based buffer overflow vulnerability 
during the encoding, when whoopsie attempts to bsonify with crafted crash file.
  The data in '.crash' file is stored in key-value form and the whoopsie 
separately measures the length of 'key' and 'value' to allocate memory region 
during the encoding. 
  A heap-based buffer overflow can occur when an integer overflow happens on a 
variable that contains length of 'key'. 
  FYI, a issue to that raised by 'value' is well covered by performing 
exception handling.

  
@[bson.c:663][https://git.launchpad.net/ubuntu/+source/whoopsie/tree/lib/bson/bson.c?h=applied/0.2.69#n663]

  const uint32_t len = strlen( name ) + 1;

  - Integer overflow occurs when length of ‘name’ exceeds INT32_MAX value. 
  - Here, ‘name’ indicates the ‘key’ data in ‘.crash’ file.

  
@[bson.c:627][https://git.launchpad.net/ubuntu/+source/whoopsie/tree/lib/bson/bson.c?h=applied/0.2.69#n627]

  b->data = bson_realloc( b->data, new_size );

  - Unexpected small memory region is allocated due to above integer
  overflow.

  
@[bson.c:680][https://git.launchpad.net/ubuntu/+source/whoopsie/tree/lib/bson/bson.c?h=applied/0.2.69#n680]

  bson_append( b, name, len );

  - Memory corruption happens when unexpected small memory region is
  allocated.

  
  ## Attack Scenario
  1) Create a fake.crash file
  - '.crash' file is composed of the following format: 'key : value'.
  - To cause the overflow attack, the size of 'key' should be in double amount 
of INT32_MAX.
  - The size of 'value' doesn’t matter, but not zero length.

  $ python -c "print('A' * 0x + ' : ' + 'B')" > /var/crash/fake.crash
  $ cat fake.crash
  AAA … AA : B

  
  2) Trigger the whoopsie to read the fake.crash file
  - Just create 'fake.upload' file by touch command.
  - Or launch apport-gtk gui or apport-bug cli application.

  3) Check out the result
  - After a while, the whoopsie has been killed by segmentation fault.

  Sincerely,

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/whoopsie/+bug/1872560/+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


[Touch-packages] [Bug 1872560] Re: integer overflow in whoopsie 0.2.69

2020-05-05 Thread Seong-Joong Kim
Thank you for your reply.

Please check the following video.
https://youtu.be/pGfOzcgd5CU

It also affects on whoopsie 0.2.69.

Thanks.

-- 
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/1872560

Title:
  integer overflow in whoopsie 0.2.69

Status in whoopsie package in Ubuntu:
  Confirmed

Bug 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 heap-based buffer overflow 
vulnerability. 
  - An attacker can cause a denial of service (memory corruption and 
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.
  After the creation of '.crash' file, whoopsie extracts the above information 
from the '.crash' file and encodes it into binary json (bson) format.
  Lastly, whoopsie forwards the data to a remotely connected Ubuntu Error 
Report system.

   
  ## Vulnerability
  Unfortunately, we have found a heap-based buffer overflow vulnerability 
during the encoding, when whoopsie attempts to bsonify with crafted crash file.
  The data in '.crash' file is stored in key-value form and the whoopsie 
separately measures the length of 'key' and 'value' to allocate memory region 
during the encoding. 
  A heap-based buffer overflow can occur when an integer overflow happens on a 
variable that contains length of 'key'. 
  FYI, a issue to that raised by 'value' is well covered by performing 
exception handling.

  
@[bson.c:663][https://git.launchpad.net/ubuntu/+source/whoopsie/tree/lib/bson/bson.c?h=applied/0.2.69#n663]

  const uint32_t len = strlen( name ) + 1;

  - Integer overflow occurs when length of ‘name’ exceeds INT32_MAX value. 
  - Here, ‘name’ indicates the ‘key’ data in ‘.crash’ file.

  
@[bson.c:627][https://git.launchpad.net/ubuntu/+source/whoopsie/tree/lib/bson/bson.c?h=applied/0.2.69#n627]

  b->data = bson_realloc( b->data, new_size );

  - Unexpected small memory region is allocated due to above integer
  overflow.

  
@[bson.c:680][https://git.launchpad.net/ubuntu/+source/whoopsie/tree/lib/bson/bson.c?h=applied/0.2.69#n680]

  bson_append( b, name, len );

  - Memory corruption happens when unexpected small memory region is
  allocated.

  
  ## Attack Scenario
  1) Create a fake.crash file
  - '.crash' file is composed of the following format: 'key : value'.
  - To cause the overflow attack, the size of 'key' should be in double amount 
of INT32_MAX.
  - The size of 'value' doesn’t matter, but not zero length.

  $ python -c "print('A' * 0x + ' : ' + 'B')" > /var/crash/fake.crash
  $ cat fake.crash
  AAA … AA : B

  
  2) Trigger the whoopsie to read the fake.crash file
  - Just create 'fake.upload' file by touch command.
  - Or launch apport-gtk gui or apport-bug cli application.

  3) Check out the result
  - After a while, the whoopsie has been killed by segmentation fault.

  Sincerely,

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/whoopsie/+bug/1872560/+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


[Touch-packages] [Bug 1876659] [NEW] Unhandled exception in run_hang()

2020-05-03 Thread Seong-Joong Kim
Public bug reported:

## Description
When we start apport-cli without PID, an unhandled exception in apport 2.20.11 
and earlier may allow an authenticated user to potentially enable a denial of 
service via local access.

The following command may cause an application crash due to an unhandled
exception.

$ apport-cli --hanging

*** Send problem report to the developers?

After the problem report has been sent, please fill out the form in the
automatically opened web browser.

What would you like to do? Your options are:
  S: Send report (24.0 KB)
  V: View report
  K: Keep report file for sending later or copying to somewhere else
  I: Cancel and ignore future crashes of this program version
  C: Cancel
Please choose (S/V/K/I/C): K
Problem report file: /tmp/apport.apport.uc0_znhj.apport
Traceback (most recent call last):
  File "/usr/bin/apport-cli", line 387, in 
if not app.run_argv():
  File "/usr/lib/python3/dist-packages/apport/ui.py", line 690, in run_argv
self.run_hang(self.options.pid)
  File "/usr/lib/python3/dist-packages/apport/ui.py", line 410, in run_hang
os.kill(int(pid), signal.SIGKILL)
TypeError: int() argument must be a string, a bytes-like object or a number, 
not 'NoneType'


Above command generates the following application crash file in /var/crash/ 
directory.

ProblemType: Crash
CurrentDesktop: ubuntu:GNOME
Date: Sun May  3 19:09:41 2020
ExecutablePath: /usr/bin/apport-cli
ExecutableTimestamp: 1585099033
InterpreterPath: /usr/bin/python3.6
ProcCmdline: /usr/bin/python3 /usr/bin/apport-cli --hanging
ProcCwd: /home/user/apport/bin
ProcEnviron:
 ...
ProcMaps:
 ...
ProcStatus:
 ...
PythonArgs: ['/usr/bin/apport-cli', '--hanging']
Traceback:
 Traceback (most recent call last):
   File "/usr/bin/apport-cli", line 387, in 
 if not app.run_argv():
   File "/usr/lib/python3/dist-packages/apport/ui.py", line 690, in run_argv
 self.run_hang(self.options.pid)
   File "/usr/lib/python3/dist-packages/apport/ui.py", line 410, in run_hang
 os.kill(int(pid), signal.SIGKILL)
 TypeError: int() argument must be a string, a bytes-like object or a number, 
not 'NoneType'
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_LogindSession: 6


Many thanks.

** Affects: apport (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1876659

Title:
  Unhandled exception in run_hang()

Status in apport package in Ubuntu:
  New

Bug description:
  ## Description
  When we start apport-cli without PID, an unhandled exception in apport 
2.20.11 and earlier may allow an authenticated user to potentially enable a 
denial of service via local access.

  The following command may cause an application crash due to an
  unhandled exception.

  $ apport-cli --hanging

  *** Send problem report to the developers?

  After the problem report has been sent, please fill out the form in the
  automatically opened web browser.

  What would you like to do? Your options are:
S: Send report (24.0 KB)
V: View report
K: Keep report file for sending later or copying to somewhere else
I: Cancel and ignore future crashes of this program version
C: Cancel
  Please choose (S/V/K/I/C): K
  Problem report file: /tmp/apport.apport.uc0_znhj.apport
  Traceback (most recent call last):
File "/usr/bin/apport-cli", line 387, in 
  if not app.run_argv():
File "/usr/lib/python3/dist-packages/apport/ui.py", line 690, in run_argv
  self.run_hang(self.options.pid)
File "/usr/lib/python3/dist-packages/apport/ui.py", line 410, in run_hang
  os.kill(int(pid), signal.SIGKILL)
  TypeError: int() argument must be a string, a bytes-like object or a number, 
not 'NoneType'

  
  Above command generates the following application crash file in /var/crash/ 
directory.

  ProblemType: Crash
  CurrentDesktop: ubuntu:GNOME
  Date: Sun May  3 19:09:41 2020
  ExecutablePath: /usr/bin/apport-cli
  ExecutableTimestamp: 1585099033
  InterpreterPath: /usr/bin/python3.6
  ProcCmdline: /usr/bin/python3 /usr/bin/apport-cli --hanging
  ProcCwd: /home/user/apport/bin
  ProcEnviron:
   ...
  ProcMaps:
   ...
  ProcStatus:
   ...
  PythonArgs: ['/usr/bin/apport-cli', '--hanging']
  Traceback:
   Traceback (most recent call last):
 File "/usr/bin/apport-cli", line 387, in 
   if not app.run_argv():
 File "/usr/lib/python3/dist-packages/apport/ui.py", line 690, in run_argv
   self.run_hang(self.options.pid)
 File "/usr/lib/python3/dist-packages/apport/ui.py", line 410, in run_hang
   os.kill(int(pid), signal.SIGKILL)
   TypeError: int() argument must be a string, a bytes-like object or a number, 
not 'NoneType'
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
  _LogindSession: 6

  
  Many thanks.

To manage notifications about this bug go to:

[Touch-packages] [Bug 1872560] Re: integer overflow in whoopsie 0.2.69

2020-04-22 Thread Seong-Joong Kim
** Summary changed:

- heap-based buffer overflow in bson.c
+ integer overflow in whoopsie 0.2.69

-- 
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/1872560

Title:
  integer overflow in whoopsie 0.2.69

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
  - whoopsie 0.2.69 and earlier have a heap-based buffer overflow 
vulnerability. 
  - An attacker can cause a denial of service (memory corruption and 
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.
  After the creation of '.crash' file, whoopsie extracts the above information 
from the '.crash' file and encodes it into binary json (bson) format.
  Lastly, whoopsie forwards the data to a remotely connected Ubuntu Error 
Report system.

   
  ## Vulnerability
  Unfortunately, we have found a heap-based buffer overflow vulnerability 
during the encoding, when whoopsie attempts to bsonify with crafted crash file.
  The data in '.crash' file is stored in key-value form and the whoopsie 
separately measures the length of 'key' and 'value' to allocate memory region 
during the encoding. 
  A heap-based buffer overflow can occur when an integer overflow happens on a 
variable that contains length of 'key'. 
  FYI, a issue to that raised by 'value' is well covered by performing 
exception handling.

  
@[bson.c:663][https://git.launchpad.net/ubuntu/+source/whoopsie/tree/lib/bson/bson.c?h=applied/0.2.69#n663]

  const uint32_t len = strlen( name ) + 1;

  - Integer overflow occurs when length of ‘name’ exceeds INT32_MAX value. 
  - Here, ‘name’ indicates the ‘key’ data in ‘.crash’ file.

  
@[bson.c:627][https://git.launchpad.net/ubuntu/+source/whoopsie/tree/lib/bson/bson.c?h=applied/0.2.69#n627]

  b->data = bson_realloc( b->data, new_size );

  - Unexpected small memory region is allocated due to above integer
  overflow.

  
@[bson.c:680][https://git.launchpad.net/ubuntu/+source/whoopsie/tree/lib/bson/bson.c?h=applied/0.2.69#n680]

  bson_append( b, name, len );

  - Memory corruption happens when unexpected small memory region is
  allocated.

  
  ## Attack Scenario
  1) Create a fake.crash file
  - '.crash' file is composed of the following format: 'key : value'.
  - To cause the overflow attack, the size of 'key' should be in double amount 
of INT32_MAX.
  - The size of 'value' doesn’t matter, but not zero length.

  $ python -c "print('A' * 0x + ' : ' + 'B')" > /var/crash/fake.crash
  $ cat fake.crash
  AAA … AA : B

  
  2) Trigger the whoopsie to read the fake.crash file
  - Just create 'fake.upload' file by touch command.
  - Or launch apport-gtk gui or apport-bug cli application.

  3) Check out the result
  - After a while, the whoopsie has been killed by segmentation fault.

  Sincerely,

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/whoopsie/+bug/1872560/+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


[Touch-packages] [Bug 1872560] Re: heap-based buffer overflow in bson.c

2020-04-22 Thread Seong-Joong Kim
I would like to update the contents of 'Attack Scenario'.

from:
$ python -c "print('A' * 0x + ' : ' + 'B')" > /var/crash/fake.crash

to:
$ python -c "print('A' * 0xFFFE + ' : ' + 'B')" > /var/crash/fake.crash

Segfault can arise when the following requirements are met, as I mentioned 
above.
- length of ‘value’ in .crash file => 0 < {length of ‘value’} < 1024
- length of ‘key’ in .crash file => UINT32_MAX - {length of ‘value’} - 7 < 
{length of ‘key’} < UINT32_MAX

Please check this issue.

-- 
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/1872560

Title:
  heap-based buffer overflow in bson.c

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
  - whoopsie 0.2.69 and earlier have a heap-based buffer overflow 
vulnerability. 
  - An attacker can cause a denial of service (memory corruption and 
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.
  After the creation of '.crash' file, whoopsie extracts the above information 
from the '.crash' file and encodes it into binary json (bson) format.
  Lastly, whoopsie forwards the data to a remotely connected Ubuntu Error 
Report system.

   
  ## Vulnerability
  Unfortunately, we have found a heap-based buffer overflow vulnerability 
during the encoding, when whoopsie attempts to bsonify with crafted crash file.
  The data in '.crash' file is stored in key-value form and the whoopsie 
separately measures the length of 'key' and 'value' to allocate memory region 
during the encoding. 
  A heap-based buffer overflow can occur when an integer overflow happens on a 
variable that contains length of 'key'. 
  FYI, a issue to that raised by 'value' is well covered by performing 
exception handling.

  
@[bson.c:663][https://git.launchpad.net/ubuntu/+source/whoopsie/tree/lib/bson/bson.c?h=applied/0.2.69#n663]

  const uint32_t len = strlen( name ) + 1;

  - Integer overflow occurs when length of ‘name’ exceeds INT32_MAX value. 
  - Here, ‘name’ indicates the ‘key’ data in ‘.crash’ file.

  
@[bson.c:627][https://git.launchpad.net/ubuntu/+source/whoopsie/tree/lib/bson/bson.c?h=applied/0.2.69#n627]

  b->data = bson_realloc( b->data, new_size );

  - Unexpected small memory region is allocated due to above integer
  overflow.

  
@[bson.c:680][https://git.launchpad.net/ubuntu/+source/whoopsie/tree/lib/bson/bson.c?h=applied/0.2.69#n680]

  bson_append( b, name, len );

  - Memory corruption happens when unexpected small memory region is
  allocated.

  
  ## Attack Scenario
  1) Create a fake.crash file
  - '.crash' file is composed of the following format: 'key : value'.
  - To cause the overflow attack, the size of 'key' should be in double amount 
of INT32_MAX.
  - The size of 'value' doesn’t matter, but not zero length.

  $ python -c "print('A' * 0x + ' : ' + 'B')" > /var/crash/fake.crash
  $ cat fake.crash
  AAA … AA : B

  
  2) Trigger the whoopsie to read the fake.crash file
  - Just create 'fake.upload' file by touch command.
  - Or launch apport-gtk gui or apport-bug cli application.

  3) Check out the result
  - After a while, the whoopsie has been killed by segmentation fault.

  Sincerely,

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/whoopsie/+bug/1872560/+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


[Touch-packages] [Bug 1872560] Re: heap-based buffer overflow in bson.c

2020-04-22 Thread Seong-Joong Kim
** Information type changed from Private Security to Public Security

-- 
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/1872560

Title:
  heap-based buffer overflow in bson.c

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
  - whoopsie 0.2.69 and earlier have a heap-based buffer overflow 
vulnerability. 
  - An attacker can cause a denial of service (memory corruption and 
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.
  After the creation of '.crash' file, whoopsie extracts the above information 
from the '.crash' file and encodes it into binary json (bson) format.
  Lastly, whoopsie forwards the data to a remotely connected Ubuntu Error 
Report system.

   
  ## Vulnerability
  Unfortunately, we have found a heap-based buffer overflow vulnerability 
during the encoding, when whoopsie attempts to bsonify with crafted crash file.
  The data in '.crash' file is stored in key-value form and the whoopsie 
separately measures the length of 'key' and 'value' to allocate memory region 
during the encoding. 
  A heap-based buffer overflow can occur when an integer overflow happens on a 
variable that contains length of 'key'. 
  FYI, a issue to that raised by 'value' is well covered by performing 
exception handling.

  
@[bson.c:663][https://git.launchpad.net/ubuntu/+source/whoopsie/tree/lib/bson/bson.c?h=applied/0.2.69#n663]

  const uint32_t len = strlen( name ) + 1;

  - Integer overflow occurs when length of ‘name’ exceeds INT32_MAX value. 
  - Here, ‘name’ indicates the ‘key’ data in ‘.crash’ file.

  
@[bson.c:627][https://git.launchpad.net/ubuntu/+source/whoopsie/tree/lib/bson/bson.c?h=applied/0.2.69#n627]

  b->data = bson_realloc( b->data, new_size );

  - Unexpected small memory region is allocated due to above integer
  overflow.

  
@[bson.c:680][https://git.launchpad.net/ubuntu/+source/whoopsie/tree/lib/bson/bson.c?h=applied/0.2.69#n680]

  bson_append( b, name, len );

  - Memory corruption happens when unexpected small memory region is
  allocated.

  
  ## Attack Scenario
  1) Create a fake.crash file
  - '.crash' file is composed of the following format: 'key : value'.
  - To cause the overflow attack, the size of 'key' should be in double amount 
of INT32_MAX.
  - The size of 'value' doesn’t matter, but not zero length.

  $ python -c "print('A' * 0x + ' : ' + 'B')" > /var/crash/fake.crash
  $ cat fake.crash
  AAA … AA : B

  
  2) Trigger the whoopsie to read the fake.crash file
  - Just create 'fake.upload' file by touch command.
  - Or launch apport-gtk gui or apport-bug cli application.

  3) Check out the result
  - After a while, the whoopsie has been killed by segmentation fault.

  Sincerely,

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/whoopsie/+bug/1872560/+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


[Touch-packages] [Bug 1822590] Re: Found storing user fingerprints without encryption

2019-04-15 Thread Seong-Joong Kim
In Ubuntu, that would be good.

Btw, I would like to request escalate importance.

I think that this issue can be even more important than password
exposure in cleartext.

Once fingerprint has been leaked, victims are leaked for the rest of
life since it lasts for a life.

Then, it severely affects applications beyond the package responsible
for the root cause.

What do you think of it?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1822590

Title:
  Found storing user fingerprints without encryption

Status in fprintd:
  New
Status in apparmor package in Ubuntu:
  New
Status in fprintd package in Ubuntu:
  Triaged

Bug description:
  Dear all,

  I would like to report a new issue as follows.
  ‘fprintd’ saves a fingerprint data, ISO/IEC 19794-2 formatted, to a file on 
the host without any encryption.
  Though fprintd generates fingerprint image with root permission for 
protecting the file from attackers, it is not of itself sufficient.
  It is well known threat model that a formatted fingerprint data can be 
restored to original image about a decade ago.
  [1-4] are presented to create sophisticated and natural-looking fingerprints 
only from the numerical template data format as defined in ISO/IEC 19794-2.
  They also successfully evaluated these approaches against a number of 
undisclosed state-of-the-art algorithms and the NIST Fingerprint Image Software.

  We need improvements of those issues.

  [1] R. Cappelli et al., “Fingerprint Image Reconstruction from Standard 
Templates”, IEEE Trans. on Pattern Analysis and Machine Intelligence, vol.29, 
no.9, pp.1489-1503, 2007.
  [2] A. Ross et al., “From template to image: Reconstructing fingerprints from 
minutiae points”, IEEE Trans on Pattern Analysis and Machine Intelligence, 
vol.29, no.4, pp.544-560, 2007.
  [3] R. Cappelli et al., “Can Fingerprints be reconstructed from ISO 
Templates?”, IEEE ICARCV 2006.
  [4] J. Feng et al., “Fingerprint Reconstruction: From Minutiae to Phase”, 
IEEE Trans on Pattern Analysis and Machine Intelligence, vol.33, no.2, 
pp.209-223, 2011.

  Sincerely,
  Seong-Joong Kim

To manage notifications about this bug go to:
https://bugs.launchpad.net/fprintd/+bug/1822590/+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