[Group.of.nepali.translators] [Bug 1853832] Re: stress-ng --timer-slack option should be a zero arg option, it currently skips over the next arg
This bug was fixed in the package stress-ng - 0.09.25-1ubuntu8 --- stress-ng (0.09.25-1ubuntu8) bionic; urgency=medium * Ensure --aggressive mode terminates early (LP: #1858858) Add a waitpid NOHANG wait on each child process and if we get ESRCH on all the child pids we can terminate the loop early. * Fix --timer-slack arg handling (LP: #1853832) * Fix mwc8() being reset when using mwc1() (LP: #1855851) Fix Psuedo-random 8 bit numbers from mwc8() accidentally being zero'd when mwc1() is called. -- Colin King Tue, 10 Dec 2019 09:32:11 + ** Changed in: stress-ng (Ubuntu Bionic) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1853832 Title: stress-ng --timer-slack option should be a zero arg option, it currently skips over the next arg Status in stress-ng package in Ubuntu: Fix Released Status in stress-ng source package in Xenial: Fix Committed Status in stress-ng source package in Bionic: Fix Released Status in stress-ng source package in Disco: Fix Released Status in stress-ng source package in Eoan: Fix Released Bug description: == SRU [Bionic][Disco][Eoan] == stress-ng --timer 1 --timer-freq 10 --timer-slack -t 1 runs for a whole day and not 1 second. The timer-slack option eats the -t1 arg because it is defined as having an arg when in fact it is a zero arg option. == Fix == Upstream fix (in Focal): commit e044133ed6ebdbac16775d8ae0d130bc2dac96ea Author: Colin Ian King Date: Mon Nov 25 12:05:30 2019 + Fix --timer-slack from consuming the following arg (LP: #1853832) == Test == stress-ng --timer 1 --timer-freq 10 --timer-slack -t 1 Without the fix, this will run by default for 24 hours. With the fix the -t option is parsed and it will run for 1 second as intended. == Regression Potential == This is a one line arg parsing change so change set is really limited to this one --timer-slack option. Users may find the behaviour now changes because it no longer consumes the next arg and hence the next arg works and hence changes functionality. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/stress-ng/+bug/1853832/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1401532] Re: GRUB's Secure Boot implementation loads unsigned kernel without warning
Released in grub2-signed (1.66.26). ** Changed in: grub2-signed (Ubuntu Xenial) Status: In Progress => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1401532 Title: GRUB's Secure Boot implementation loads unsigned kernel without warning Status in grub2 package in Ubuntu: Fix Released Status in grub2-signed package in Ubuntu: Fix Released Status in grub2 source package in Trusty: Fix Released Status in grub2-signed source package in Trusty: Fix Released Status in grub2 source package in Xenial: Fix Released Status in grub2-signed source package in Xenial: Fix Released Status in grub2 source package in Bionic: Fix Released Status in grub2-signed source package in Bionic: Fix Released Bug description: [Rationale] GRUB should help us enforce that in UEFI mode, only signed kernels are loaded. It should not silently fall back to loading unsigned kernels. [Impact] All our users booting in UEFI; on all supported releases. [Test cases] = grub2 = Booting unsigned kernels: 1) Try to boot a custom kernel 2) Verify that the kernel will not be loaded by grub (you should see an error message about the signature) Booting signed kernels: 1) Try to boot an official signed kernel (from -release or -updates) 2) Verify that the system boots normally and no warnings are shown about signature. [Regression Potential] Any failure to boot presenting as a failure to load the kernel from within grub, with an "invalid signature" type error message or not, should be investigated as a potential regression of this stable update. --- Me and some other students have conducted some various experiments on Secure Boot enabled machines. The main focus of the tests was to circumvent Secure Boot and load unsigned kernels or kernels that have been signed with other keys. On your SecureBoot (https://wiki.ubuntu.com/SecurityTeam/SecureBoot) it is outlined that GRUB will boot unsigned kernels when the kernel is unsigned. During one of our experiments it seemed that this statement was true and that GRUB loads unsigned kernels as described on your page. We understand that for various reasons GRUB should still support the use-case when an unsigned kernel must be loaded, but with the current approach the user isn't aware if there is a whole chain of trust. For example, it could still be possible to load some malware before it boots the Operating System itself (bootkits). One of the many reasons that Secure Boot has been developed is to protect the user from these kind of attacks. With the current approach the purpose of Secure Boot is somewhat defeated, and the user doesn't know if the whole chain has been verified or not. It could easily be the case that an unsigned kernel has been loaded by Ubuntu without the user noticing. From our point of view, a better approach would be to inform the user that an unsigned kernel will be loaded and that the user can make a choice if he/she wants to proceed. The default action could be to accept the option, remember the user's option and sometimes remind the user of the fact that it is loading an unsigned kernel. This problem is of course related to GRUB itself and not to Ubuntu itself. The reason for filing this bug and informing the SecurityTeam of Ubuntu is to ask for their opinions and what your point of view is on the current approach and to see if other users classify this as a "bug". GRUB2 versions: grub-2.02~beta2, 1.34.1+2.02~beta2-9ubuntu1 Ubuntu version: Trusty (will also affect newer and older versions, GRUB specific problem) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1401532/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1872560] Re: integer overflow in whoopsie 0.2.69
This bug was fixed in the package whoopsie - 0.2.62ubuntu0.5
---
whoopsie (0.2.62ubuntu0.5) bionic-security; urgency=medium
* SECURITY UPDATE: integer overflow in bson parsing (LP: #1872560)
- lib/bson/*: updated to latest upstream release.
- CVE-2020-12135
* SECURITY UPDATE: resource exhaustion via memory leak (LP: #1881982)
- src/whoopsie.c, src/tests/test_parse_report.c: properly handle
GHashTable.
- CVE-2020-11937
* SECURITY UPDATE: DoS via large data length (LP: #1882180)
- src/whoopsie.c, src/whoopsie.h, src/tests/test_parse_report.c: limit
the size of a report file.
- CVE-2020-15570
-- Marc Deslauriers Fri, 24 Jul 2020
08:55:26 -0400
** Changed in: whoopsie (Ubuntu Bionic)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1872560
Title:
integer overflow in whoopsie 0.2.69
Status in whoopsie package in Ubuntu:
Confirmed
Status in whoopsie source package in Xenial:
Fix Released
Status in whoopsie source package in Bionic:
Fix Released
Status in whoopsie source package in Eoan:
Confirmed
Status in whoopsie source package in Focal:
Fix Released
Status in whoopsie source package in Groovy:
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/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1882180] Re: DoS vulnerability: fail to allocate
This bug was fixed in the package whoopsie - 0.2.62ubuntu0.5 --- whoopsie (0.2.62ubuntu0.5) bionic-security; urgency=medium * SECURITY UPDATE: integer overflow in bson parsing (LP: #1872560) - lib/bson/*: updated to latest upstream release. - CVE-2020-12135 * SECURITY UPDATE: resource exhaustion via memory leak (LP: #1881982) - src/whoopsie.c, src/tests/test_parse_report.c: properly handle GHashTable. - CVE-2020-11937 * SECURITY UPDATE: DoS via large data length (LP: #1882180) - src/whoopsie.c, src/whoopsie.h, src/tests/test_parse_report.c: limit the size of a report file. - CVE-2020-15570 -- Marc Deslauriers Fri, 24 Jul 2020 08:55:26 -0400 ** Changed in: whoopsie (Ubuntu Bionic) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1882180 Title: DoS vulnerability: fail to allocate Status in whoopsie package in Ubuntu: Confirmed Status in whoopsie source package in Xenial: Fix Released Status in whoopsie source package in Bionic: Fix Released Status in whoopsie source package in Eoan: Confirmed Status in whoopsie source package in Focal: Fix Released Status in whoopsie source package in Groovy: Confirmed Bug description: Hi, I have found a security issue on whoopsie 0.2.69 and earlier. # Vulnerability description In whoopsie 0.2.69 and earlier, there is a denial of service vulnerability in the parse_report function. A crafted input, i.e., crash report located in '/var/crash/', will lead to a denial of service attack. During the parsing of the crash report, the data length is not checked. The value of data length can be directly controlled by an input file. In the parse_report() function, the g_malloc or g_realloc is called based on data length. If we set the value of data length close to the amount of system memory, it will cause the daemon process to terminate unexpectedly, hang the system, or trigger the OOM killer. # PoC Please check the below whoopsie_killer2.py Sincerely, To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/whoopsie/+bug/1882180/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1881982] Re: DoS vulnerability: cause resource exhaustion
This bug was fixed in the package whoopsie - 0.2.62ubuntu0.5 --- whoopsie (0.2.62ubuntu0.5) bionic-security; urgency=medium * SECURITY UPDATE: integer overflow in bson parsing (LP: #1872560) - lib/bson/*: updated to latest upstream release. - CVE-2020-12135 * SECURITY UPDATE: resource exhaustion via memory leak (LP: #1881982) - src/whoopsie.c, src/tests/test_parse_report.c: properly handle GHashTable. - CVE-2020-11937 * SECURITY UPDATE: DoS via large data length (LP: #1882180) - src/whoopsie.c, src/whoopsie.h, src/tests/test_parse_report.c: limit the size of a report file. - CVE-2020-15570 -- Marc Deslauriers Fri, 24 Jul 2020 08:55:26 -0400 ** Changed in: whoopsie (Ubuntu Bionic) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1881982 Title: DoS vulnerability: cause resource exhaustion Status in whoopsie package in Ubuntu: Confirmed Status in whoopsie source package in Xenial: Fix Released Status in whoopsie source package in Bionic: Fix Released Status in whoopsie source package in Eoan: Confirmed Status in whoopsie source package in Focal: Fix Released Status in whoopsie source package in Groovy: 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/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1872560] Re: integer overflow in whoopsie 0.2.69
This bug was fixed in the package whoopsie - 0.2.69ubuntu0.1
---
whoopsie (0.2.69ubuntu0.1) focal-security; urgency=medium
* SECURITY UPDATE: integer overflow in bson parsing (LP: #1872560)
- lib/bson/*: updated to latest upstream release.
- CVE-2020-12135
* SECURITY UPDATE: resource exhaustion via memory leak (LP: #1881982)
- src/whoopsie.c, src/tests/test_parse_report.c: properly handle
GHashTable.
- CVE-2020-11937
* SECURITY UPDATE: DoS via large data length (LP: #1882180)
- src/whoopsie.c, src/whoopsie.h, src/tests/test_parse_report.c: limit
the size of a report file.
- CVE-2020-15570
-- Marc Deslauriers Fri, 24 Jul 2020
08:55:26 -0400
** Changed in: whoopsie (Ubuntu Focal)
Status: Confirmed => Fix Released
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-11937
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-15570
** Changed in: whoopsie (Ubuntu Xenial)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1872560
Title:
integer overflow in whoopsie 0.2.69
Status in whoopsie package in Ubuntu:
Confirmed
Status in whoopsie source package in Xenial:
Fix Released
Status in whoopsie source package in Bionic:
Fix Released
Status in whoopsie source package in Eoan:
Confirmed
Status in whoopsie source package in Focal:
Fix Released
Status in whoopsie source package in Groovy:
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/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1881982] Re: DoS vulnerability: cause resource exhaustion
This bug was fixed in the package whoopsie - 0.2.69ubuntu0.1 --- whoopsie (0.2.69ubuntu0.1) focal-security; urgency=medium * SECURITY UPDATE: integer overflow in bson parsing (LP: #1872560) - lib/bson/*: updated to latest upstream release. - CVE-2020-12135 * SECURITY UPDATE: resource exhaustion via memory leak (LP: #1881982) - src/whoopsie.c, src/tests/test_parse_report.c: properly handle GHashTable. - CVE-2020-11937 * SECURITY UPDATE: DoS via large data length (LP: #1882180) - src/whoopsie.c, src/whoopsie.h, src/tests/test_parse_report.c: limit the size of a report file. - CVE-2020-15570 -- Marc Deslauriers Fri, 24 Jul 2020 08:55:26 -0400 ** Changed in: whoopsie (Ubuntu Focal) Status: Confirmed => Fix Released ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-12135 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-15570 ** Changed in: whoopsie (Ubuntu Xenial) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1881982 Title: DoS vulnerability: cause resource exhaustion Status in whoopsie package in Ubuntu: Confirmed Status in whoopsie source package in Xenial: Fix Released Status in whoopsie source package in Bionic: Fix Released Status in whoopsie source package in Eoan: Confirmed Status in whoopsie source package in Focal: Fix Released Status in whoopsie source package in Groovy: 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/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1882180] Re: DoS vulnerability: fail to allocate
This bug was fixed in the package whoopsie - 0.2.69ubuntu0.1 --- whoopsie (0.2.69ubuntu0.1) focal-security; urgency=medium * SECURITY UPDATE: integer overflow in bson parsing (LP: #1872560) - lib/bson/*: updated to latest upstream release. - CVE-2020-12135 * SECURITY UPDATE: resource exhaustion via memory leak (LP: #1881982) - src/whoopsie.c, src/tests/test_parse_report.c: properly handle GHashTable. - CVE-2020-11937 * SECURITY UPDATE: DoS via large data length (LP: #1882180) - src/whoopsie.c, src/whoopsie.h, src/tests/test_parse_report.c: limit the size of a report file. - CVE-2020-15570 -- Marc Deslauriers Fri, 24 Jul 2020 08:55:26 -0400 ** Changed in: whoopsie (Ubuntu Focal) Status: Confirmed => Fix Released ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-11937 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-12135 ** Changed in: whoopsie (Ubuntu Xenial) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1882180 Title: DoS vulnerability: fail to allocate Status in whoopsie package in Ubuntu: Confirmed Status in whoopsie source package in Xenial: Fix Released Status in whoopsie source package in Bionic: Fix Released Status in whoopsie source package in Eoan: Confirmed Status in whoopsie source package in Focal: Fix Released Status in whoopsie source package in Groovy: Confirmed Bug description: Hi, I have found a security issue on whoopsie 0.2.69 and earlier. # Vulnerability description In whoopsie 0.2.69 and earlier, there is a denial of service vulnerability in the parse_report function. A crafted input, i.e., crash report located in '/var/crash/', will lead to a denial of service attack. During the parsing of the crash report, the data length is not checked. The value of data length can be directly controlled by an input file. In the parse_report() function, the g_malloc or g_realloc is called based on data length. If we set the value of data length close to the amount of system memory, it will cause the daemon process to terminate unexpectedly, hang the system, or trigger the OOM killer. # PoC Please check the below whoopsie_killer2.py Sincerely, To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/whoopsie/+bug/1882180/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded
** Changed in: mdadm (Ubuntu) Status: Confirmed => Opinion ** Changed in: initramfs-tools (Ubuntu) Status: Confirmed => In Progress ** Also affects: mdadm (Ubuntu Groovy) Importance: Medium Assignee: Guilherme G. Piccoli (gpiccoli) Status: Opinion ** Also affects: cryptsetup (Ubuntu Groovy) Importance: Medium Assignee: Guilherme G. Piccoli (gpiccoli) Status: In Progress ** Also affects: initramfs-tools (Ubuntu Groovy) Importance: Medium Assignee: Guilherme G. Piccoli (gpiccoli) Status: In Progress ** Also affects: mdadm (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: cryptsetup (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: initramfs-tools (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: mdadm (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: cryptsetup (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: initramfs-tools (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: mdadm (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: cryptsetup (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: initramfs-tools (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: mdadm (Ubuntu Xenial) Status: New => Opinion ** Changed in: mdadm (Ubuntu Bionic) Status: New => Opinion ** Changed in: cryptsetup (Ubuntu Xenial) Status: New => Opinion ** Changed in: cryptsetup (Ubuntu Bionic) Status: New => In Progress ** Changed in: cryptsetup (Ubuntu Bionic) Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli) ** Changed in: cryptsetup (Ubuntu Xenial) Importance: Undecided => Medium ** Changed in: cryptsetup (Ubuntu Xenial) Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli) ** Changed in: cryptsetup (Ubuntu Bionic) Importance: Undecided => Medium ** Changed in: cryptsetup (Ubuntu Xenial) Status: Opinion => Won't Fix ** Changed in: cryptsetup (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: cryptsetup (Ubuntu Focal) Status: New => In Progress ** Changed in: cryptsetup (Ubuntu Focal) Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli) ** Changed in: initramfs-tools (Ubuntu Xenial) Importance: Undecided => Medium ** Changed in: initramfs-tools (Ubuntu Xenial) Status: New => Won't Fix ** Changed in: initramfs-tools (Ubuntu Xenial) Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli) ** Changed in: initramfs-tools (Ubuntu Bionic) Importance: Undecided => Medium ** Changed in: initramfs-tools (Ubuntu Bionic) Status: New => In Progress ** Changed in: initramfs-tools (Ubuntu Bionic) Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli) ** Changed in: initramfs-tools (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: initramfs-tools (Ubuntu Focal) Status: New => In Progress ** Changed in: initramfs-tools (Ubuntu Focal) Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli) ** Changed in: mdadm (Ubuntu Xenial) Importance: Undecided => Medium ** Changed in: mdadm (Ubuntu Xenial) Status: Opinion => Won't Fix ** Changed in: mdadm (Ubuntu Xenial) Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli) ** Changed in: mdadm (Ubuntu Bionic) Importance: Undecided => Medium ** Changed in: mdadm (Ubuntu Bionic) Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli) ** Changed in: mdadm (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: mdadm (Ubuntu Focal) Status: New => Opinion ** Changed in: mdadm (Ubuntu Focal) Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1879980 Title: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded Status in cryptsetup package in Ubuntu: In Progress Status in initramfs-tools package in Ubuntu: In Progress Status in mdadm package in Ubuntu: Opinion Status in cryptsetup source package in Xenial: Won't Fix Status in initramfs-tools source package in Xenial: Won't Fix Status in mdadm source package in Xenial: Won't Fix Status in cryptsetup source package in Bionic: In Progress Status in initramfs-tools source package in Bionic: In Progress Status in mdadm source package in Bionic: Opinion Status in cryptsetup source package in Focal: In Progress Status in initramfs-tools source package in Focal: In Progress Status in mdadm source package in Focal: Opinion Status in cryptsetup source package in Groovy: In Progress Status in initramfs-tools source package in Groovy: In Progress Status in mdadm source package in Groovy:
[Group.of.nepali.translators] [Bug 1890201] Re: Depends on wireguard-modules | wireguard-dkms are inverted
This bug was fixed in the package wireguard - 1.0.20200513-1ubuntu1 --- wireguard (1.0.20200513-1ubuntu1) groovy; urgency=medium * Switch alternative dependency order for the wireguard-modules, wireguard-dkms alternative. Whichever is first is deemed the preferred installation candidate when neither is present. When this is wireguard-modules this is satisfied by installation of a random kernel which claims support for wireguard regardless of its applicability. Repeat after me, do not ever depend on a kernel. (LP: #1890201) -- Andy Whitcroft Mon, 03 Aug 2020 22:24:05 +0100 ** Changed in: wireguard (Ubuntu Groovy) Status: In Progress => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1890201 Title: Depends on wireguard-modules | wireguard-dkms are inverted Status in wireguard package in Ubuntu: Fix Released Status in wireguard source package in Xenial: New Status in wireguard source package in Bionic: New Status in wireguard source package in Focal: New Status in wireguard source package in Groovy: Fix Released Bug description: [Impact] Removal of the previously official PPA package can lead to installation of an unrelated (and unbootable) kernel in preference to the official DKMS package. [Test Case] Install wireguard from a old kernel (or a kernel such as linux-oem- osp1 which does not yet have builtin modules) and note that linux-gke or similar is an installation candidate. [Regression Potential] Watch out for installation of the wireguard-dkms package when a kernel which does support wireguard natively is installed. [Other Info] Wishing to expedite release of these packages as we are hitting this in the wild. === 8< === 8< === wireguard depends on wireguard-modules | wqireguard-dkms. This is inverted. This will default to installing wireguard-modules in preference to wireguard-dkms when neither is installed. In Ubuntu this leads us to install an unrelated kernel to resolve the lack. We should in that case install wireguard-dkms. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wireguard/+bug/1890201/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1880959] Re: Rules from the policy directory files are not reapplied after changes to the primary policy file
This bug was fixed in the package python-oslo.policy - 1.33.1-0ubuntu3
---
python-oslo.policy (1.33.1-0ubuntu3) bionic; urgency=medium
* d/p/reload-policy-files.patch: Cherry-picked from upstream review
to ensure policy directory files are reapplied after change to primary
policy file (LP: #1880959).
-- Corey Bryant Tue, 14 Jul 2020 09:43:55
-0400
** Changed in: python-oslo.policy (Ubuntu Bionic)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1880959
Title:
Rules from the policy directory files are not reapplied after changes
to the primary policy file
Status in Ubuntu Cloud Archive:
Fix Released
Status in Ubuntu Cloud Archive mitaka series:
Won't Fix
Status in Ubuntu Cloud Archive queens series:
Fix Committed
Status in Ubuntu Cloud Archive rocky series:
Fix Released
Status in Ubuntu Cloud Archive stein series:
Fix Released
Status in Ubuntu Cloud Archive train series:
Fix Released
Status in Ubuntu Cloud Archive ussuri series:
Fix Released
Status in oslo.policy:
Fix Released
Status in python-oslo.policy package in Ubuntu:
Fix Released
Status in python-oslo.policy source package in Xenial:
Won't Fix
Status in python-oslo.policy source package in Bionic:
Fix Released
Status in python-oslo.policy source package in Eoan:
Won't Fix
Status in python-oslo.policy source package in Focal:
Fix Released
Status in python-oslo.policy source package in Groovy:
Fix Released
Bug description:
[Impact]
Based on the investigation here
https://bugs.launchpad.net/charm-keystone/+bug/1880847 it was determined that
rules from policy files located in the directory specified in the policy_dirs
option (/etc//policy.d by default) are not re-applied after the
rules from the primary policy file is re-applied due to a change.
This leads to scenarios where incorrect rule combinations are active.
Example from the test case in 1880847:
* policy.json gets read with the following rule;
"identity:list_credentials": "rule:admin_required or user_id:%(user_id)s",
* rule.yaml from policy.d is read with the following rule;
{'identity:list_credentials': '!'}
* policy.json's mtime gets updated (with or without a content change) and
overrides the rule to be
"identity:list_credentials": "rule:admin_required or user_id:%(user_id)s",
* rule.yaml doesn't get reapplied since it hasn't changed.
[Test Case]
== ubuntu ==
The patches include unit tests that ensure the code is behaving as
expected and has not regressed. These tests are run during every
package build.
== upstream ==
For a particular version of oslo.policy:
* put the attached test (https://bugs.launchpad.net/ubuntu/+source
/python-
oslo.policy/+bug/1880959/+attachment/5377753/+files/test_1880959.py)
under oslo_policy/tests/test_1880959.py;
* run tox -e cover -- oslo_policy.tests.test_1880959.EnforcerTest;
* observe the failure;
# ...
testtools.matchers._impl.MismatchError: 'role:fakeA' != 'rule:admin'
Ran 1 tests in 0.005s (+0.001s)
FAILED (id=1, failures=1)
* apply the patch;
* run tox -e cover -- oslo_policy.tests.test_1880959.EnforcerTest
* observe that the failure is no longer there.
[Regression Potential]
The regression potential is low given that there is test coverage in the
olso.policy unit tests.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1880959/+subscriptions
___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1801338] Re: apt fails to properly handle server-side connection closure
I can't reproduce this anymore, so closing it. ** Changed in: apt (Ubuntu) Status: Triaged => Invalid ** Changed in: apt (Ubuntu) Status: Invalid => Incomplete ** Changed in: apt (Ubuntu) Status: Incomplete => Invalid ** Changed in: apt (Ubuntu Xenial) Status: Confirmed => Invalid ** Changed in: apt (Ubuntu Bionic) Status: Triaged => Invalid -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1801338 Title: apt fails to properly handle server-side connection closure Status in apt package in Ubuntu: Invalid Status in apt source package in Xenial: Invalid Status in apt source package in Bionic: Invalid Bug description: [Impact] In some cases, apt does not correctly handle server-side connection closure after a pipeline, and aborts the file being downloaded with an "Undetermined Error" when the connection has been closed. [Test case] This could be seen by running apt build-dep evince on cosmic with a recent apt with the pipelining fix (such as 1.6.6) against a local mirror running apache from trusty. It remains to be seen whether this is easily reproducible for anyone. [Regression potential] N/A yet. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1801338/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
