Re: Serious regression in systemd 215-17+deb8u10
Am 11.03.19 um 19:17 schrieb Markus Koschany: > > Am 11.03.19 um 15:51 schrieb Dan Poltawski: >> Thanks for your responses. One of my colleagues has been looking into this >> trying to get the bottom of it and we do seem to have identified a memory >> leak which isn't present on stretch. I note the report posted to the list >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924060. > > [...] > > Thank you for sharing your analysis with us. I will prepare a regression > update shortly. > It appears the confusion stems from the fact that CVE-2018-16864 was already > addressed > by version 215-17+deb8u9. Thus nobody saw a connection between the memory > leak and the recent > upload which deals with another issue. Thanks, Markus. Also big thanks to the debian-lts team in general for backporting those security fixes for the systemd package in old-stable. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Time allocation per CVE
Hi, I spent the day reproducing (unbreaking) the sqlalchemy exploit, figuring out how to run the test suite, attempting a backport of the upstream fix, plus some communication. I did about the same for the gnutls/nettle issue last week (only to conclude with a no-dsa T_T). While I believe those were tricky (there's a reason why they were sitting for weeks), this still costs time. Does the above sounds a legitimate use of our sponsored time, or should I call it quits earlier when a fix is not straightforward? Cheers! Sylvain
Accepted zabbix 1:2.2.23+dfsg-0+deb8u1 (source amd64 all) into oldstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 11 Mar 2019 13:16:44 +0100 Source: zabbix Binary: zabbix-agent zabbix-frontend-php zabbix-java-gateway zabbix-proxy-mysql zabbix-proxy-pgsql zabbix-proxy-sqlite3 zabbix-server-mysql zabbix-server-pgsql Architecture: source amd64 all Version: 1:2.2.23+dfsg-0+deb8u1 Distribution: jessie-security Urgency: high Maintainer: Christoph Haas Changed-By: Markus Koschany Description: zabbix-agent - network monitoring solution - agent zabbix-frontend-php - network monitoring solution - PHP front-end zabbix-java-gateway - network monitoring solution - Java gateway zabbix-proxy-mysql - network monitoring solution - proxy (using MySQL) zabbix-proxy-pgsql - network monitoring solution - proxy (using PostgreSQL) zabbix-proxy-sqlite3 - network monitoring solution - proxy (using SQLite3) zabbix-server-mysql - network monitoring solution - server (using MySQL) zabbix-server-pgsql - network monitoring solution - server (using PostgreSQL) Changes: zabbix (1:2.2.23+dfsg-0+deb8u1) jessie-security; urgency=high . * Non-maintainer upload by the LTS team. * New upstream release of the 2.2 LTS branch. * Rebase patches for new release. Drop all previous security fixes because they are now included in version 2.2.23. * Fix CVE-2016-10742: Zabbix allowed remote attackers to redirect to external links by misusing the request parameter. * Fix CVE-2017-2826: An information disclosure vulnerability exists in the iConfig proxy request of Zabbix server. A specially crafted iConfig proxy request can cause the Zabbix server to send the configuration information of any Zabbix proxy, resulting in information disclosure. An attacker can make requests from an active Zabbix proxy to trigger this vulnerability. * This update also includes several other bug fixes and improvements. For more information please refer to the upstream changelog file. Checksums-Sha1: 07de8242ace39bedac86bb2340ed617227d0cc25 2952 zabbix_2.2.23+dfsg-0+deb8u1.dsc 1f32037be9457cf7e63f19e938c2e57d2870fabc 6078160 zabbix_2.2.23+dfsg.orig.tar.xz 328bbe1bd8d03fdfe1f3a5fb970906dea77b9906 189656 zabbix_2.2.23+dfsg-0+deb8u1.debian.tar.xz 38688010a6d66167d4ead5e383af5e664679dcfa 340406 zabbix-agent_2.2.23+dfsg-0+deb8u1_amd64.deb f898b01a12fc1b66fe2d7df240b0ef5f802839d1 3069738 zabbix-frontend-php_2.2.23+dfsg-0+deb8u1_all.deb 3f27da7bf59e53bce917ca9bf925849daa20fb34 205564 zabbix-java-gateway_2.2.23+dfsg-0+deb8u1_all.deb 59fee576352b6fa8a183d96708a98273bcd051c9 589982 zabbix-proxy-mysql_2.2.23+dfsg-0+deb8u1_amd64.deb aaf92afd1429bbf485dcfab5915f5e80c326b115 592406 zabbix-proxy-pgsql_2.2.23+dfsg-0+deb8u1_amd64.deb 3557e7089e10948a548845f5a2133b7aa082f2cf 575860 zabbix-proxy-sqlite3_2.2.23+dfsg-0+deb8u1_amd64.deb 02d9f581897dd0dc32176d9fc0f6dd4164b0fb3d 1768486 zabbix-server-mysql_2.2.23+dfsg-0+deb8u1_amd64.deb 4a043cfe5b45931d684709653808bc3b3c9d89ee 1769880 zabbix-server-pgsql_2.2.23+dfsg-0+deb8u1_amd64.deb Checksums-Sha256: b0279209eb3bb6c4694beef4af08ad63384122435d2ee0fe6f2a702098fd0e14 2952 zabbix_2.2.23+dfsg-0+deb8u1.dsc e1c73ea9ea813ca5b77a509dd0796af9293784ae402bbbe7de427faea6742eeb 6078160 zabbix_2.2.23+dfsg.orig.tar.xz 5f4b4a49adfa76449692d09236dead95452e6404baaeba67bd12fe1d1d85afd3 189656 zabbix_2.2.23+dfsg-0+deb8u1.debian.tar.xz 4104b4730463002bb59a114265ec272ee808d91e7865e6735e3517732d75527c 340406 zabbix-agent_2.2.23+dfsg-0+deb8u1_amd64.deb 31e0131d01b9cf2bb6ac77d0167747c55bce0223ee9e581f25ae79598594f6c3 3069738 zabbix-frontend-php_2.2.23+dfsg-0+deb8u1_all.deb 2cee62f0b5655be664f78bf68c7c9de16cb71f7a3d1692ad03de6a2fce9a30b0 205564 zabbix-java-gateway_2.2.23+dfsg-0+deb8u1_all.deb f50a5591ed3d6f8b1b0552e59403e91204441c101838d319bcfda39b24dc1a87 589982 zabbix-proxy-mysql_2.2.23+dfsg-0+deb8u1_amd64.deb 0f30d05068d2181141be21deb4a11035aab4e38acaa8dd197451a8c88d11934a 592406 zabbix-proxy-pgsql_2.2.23+dfsg-0+deb8u1_amd64.deb 087bbc5906bb1eecf48d626530d62b9dc1faed774590962a66579a2f757f967b 575860 zabbix-proxy-sqlite3_2.2.23+dfsg-0+deb8u1_amd64.deb 180d56fcb9fe9acf8da9fa00d3a1113f730d289998f59a2abd6e61432c9b859a 1768486 zabbix-server-mysql_2.2.23+dfsg-0+deb8u1_amd64.deb b62d7a19617c12aecb4b1b75b80aaacdb0046817506324400c756849d3e29e30 1769880 zabbix-server-pgsql_2.2.23+dfsg-0+deb8u1_amd64.deb Files: 85a552b03f384cfa5948d85a2e1dbbfc 2952 net optional zabbix_2.2.23+dfsg-0+deb8u1.dsc 543faf820fd790c7f7ef56d623bafef6 6078160 net optional zabbix_2.2.23+dfsg.orig.tar.xz 9dc874c9291c78e8cd378d7a09adab0d 189656 net optional zabbix_2.2.23+dfsg-0+deb8u1.debian.tar.xz 2e67b11bf51a35b45934150998222bff 340406 net optional zabbix-agent_2.2.23+dfsg-0+deb8u1_amd64.deb 1ed9c9ce310abb6b3733b36b488170d3 3069738 net optional zabbix-frontend-php_2.2.23+dfsg-0+deb8u1_all.deb 679d14966394aef15fc6001eca7d1ee4 205564 net optional zabbix-java-gateway_2.2.23+dfsg-0+deb8u1_all.deb
sqlalchemy testsuite
Hi, Here are some notes about running the sqlalchemy test suite on jessie. The document leaves a lot of the setup up to the user. I still have some failures with MySQL and Unicode, even when configuring everything in utf8... I'm aggregating test suite notes at https://wiki.debian.org/LTS/TestSuites # Base doc in README.unittests.rst apt install python-pytest python-mock python-setuptools python-dev python-mysqldb python-psycopg2 # python-pysqlite1.1 python-pysqlite2 # -> replaced by built-in sqlite3 module # sqlite tests apt install python-nose ./sqla_nose.py -v --write-profiles # Ran 6054 tests in 123.179s # OK (SKIP=198) # sqlite tests python setup.py test # 5939 passed, 727 skipped in 157.86 seconds # more DBs apt install mysql-server sed -i -e 's/\[mysqld\]/[mysqld]\ndefault_storage_engine=MyISAM/' /etc/mysql/my.cnf # -> documented but doesn't change test results #sed -i -e 's/\[mysqld\]/[mysqld]\ncharacter_set_server=utf8/' /etc/mysql/my.cnf # -> doesn't change test results (still 4 unicode-related failures) service mysql restart mysql -e "DROP DATABASE test;" mysql -e "DROP DATABASE test_schema;" mysql -e "CREATE DATABASE test;" mysql -e "CREATE DATABASE test_schema;" mysql -e "GRANT ALL PRIVILEGES ON test.* TO 'scott'@'localhost' IDENTIFIED BY 'tiger';" mysql -e "GRANT ALL PRIVILEGES ON test_schema.* TO 'scott'@'localhost' IDENTIFIED BY 'tiger';" apt install postgresql echo 'max_prepared_transactions = 100' >> /etc/postgresql/9.4/main/postgresql.conf sed -i -e 's/^lc_.*/#&/' /etc/postgresql/9.4/main/postgresql.conf service postgresql restart echo -e 'tiger\ntiger' | su - postgres -c 'createuser scott -l -P' su - postgres -c 'dropdb test' su - postgres -c 'createdb test' #su - postgres -c "psql -c 'GRANT ALL PRIVILEGES ON DATABASE test to scott;' su - postgres -c "psql -c 'CREATE SCHEMA test_schema AUTHORIZATION scott;' test" su - postgres -c "psql -c 'CREATE SCHEMA test_schema_2 AUTHORIZATION scott;' test" su - postgres -c 'psql -c "ALTER DATABASE test SET default_text_search_config = '\''pg_catalog.english'\'';"' py.test --db sqlite --db postgresql --db mysql # Note: apparently one needs to drop/recreate the pgsql DBs due to some test leftovers # MySQL: py.test --db mysql # 4 failed, 5967 passed, 695 skipped in 288.81 seconds # PostgreSQL: py.test --db postgresql # 6354 passed, 312 skipped in 333.16 seconds # All: py.test --db sqlite --db postgresql --db mysql # 4 failed, 8904 passed, 341 skipped in 312.66 seconds
Re: Serious regression in systemd 215-17+deb8u10
Am 11.03.19 um 15:51 schrieb Dan Poltawski: > Thanks for your responses. One of my colleagues has been looking into this > trying to get the bottom of it and we do seem to have identified a memory > leak which isn't present on stretch. I note the report posted to the list > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924060. [...] Thank you for sharing your analysis with us. I will prepare a regression update shortly. It appears the confusion stems from the fact that CVE-2018-16864 was already addressed by version 215-17+deb8u9. Thus nobody saw a connection between the memory leak and the recent upload which deals with another issue. Regards, Markus signature.asc Description: OpenPGP digital signature
Re: Serious regression in systemd 215-17+deb8u10
Thanks for your responses. One of my colleagues has been looking into this
trying to get the bottom of it and we do seem to have identified a memory leak
which isn't present on stretch. I note the report posted to the list
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924060.
Here are what my colleague Alan has documented about his findings, we're going
into this without much knowledge of the area, sharing in the hope it helps
someone more familiar with the situation:
We have run journald under Valgrind, putting system logs through logger - which
has identified several memory leaks, for example:
==9577== 1,298,665 bytes in 21,103 blocks are definitely lost in loss record 11
of 11
==9577== at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==9577== by 0x1272F0: strappend (in /lib/systemd/systemd-journald)
==9577== by 0x112849: dispatch_message_real.lto_priv.175 (in
/lib/systemd/systemd-journald)
==9577== by 0x131867: server_dispatch_message (in /lib/systemd/systemd-journald)
==9577== by 0x12F189: process_datagram.part.10.lto_priv.168 (in
==9577== by 0x12355F: source_dispatch (in /lib/systemd/systemd-journald)
==9577== by 0x12402E: sd_event_run (in /lib/systemd/systemd-journald)
==9577== by 0x10DFC3: main (in /lib/systemd/systemd-journald)
Note that CVE-2018-16864.patch applies to function "dispatch_message_real" in
journald-server.c,
which matches the leak found by Valgrind.
This patch changes calls to "strappenda" to "strappend".
"strappenda" calls "alloca(3)" which allocates memory on the stack, to be freed
on function return.
"strappend" calls internal function "new()", which ends up calling
"malloc_multiply()" and then "malloc(3)"
"malloc" normally allocates memory from the heap.
There are no corresponding calls to "free(3)" in the patch.
Red Hat's initial fix for CVE-2018-16864 introduced the same bug,
which has been assigned CVE-2019-3815
See
https://access.redhat.com/security/cve/cve-2019-3815
and
https://bugzilla.redhat.com/show_bug.cgi?id=146 (currently "Access Denied")
Centos has applied the RH patch in
0669-journald-free-cmdline-buffers-owned-by-iovec.patch from
http://vault.centos.org/7.6.1810/updates/Source/SPackages/systemd-219-62.el7_6.5.src.rpm
although the RH/Centos code is rather different in that they have backported
"set_iovec_field_free" from systemd v233
--
From: Chris Lamb
Sent: 06 March 2019 19:40
To: Dan Poltawski; debian-lts@lists.debian.org
Subject: Re: Serious regression in systemd 215-17+deb8u10
Hi Dan,
> We have discovered that the latest version of systemd uploaded to
> jessie is causing systemd-journald to use an ever increasing amount of
> memory, eventually leading to all available memory being consumed. This
> has been observed on multiple different systems we use which are
> logging quite heavily and have upgraded to the latest systemd package.
> We have some systems which haven't had the new security patches applied
> and are not observing this behaviour - there is a clear correlation
> with the latest version of the systemd package.
So, this is the patch that was applied in systemd 215-17+deb8u10:
Description: journald: do not store the iovec entry for process commandline
on stack
This fixes a crash (CVE-2018-16864) where we
would read the commandline, whose length is under control of the
sending program, and then crash when trying to create a stack
allocation for it.
.
This is a backport of
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsystemd%2Fsystemd%2Fcommit%2F084eeb865ca63887098e0945fb4e93c852b91b0fdata=02%7C01%7Cdan.poltawski%40tnp.net.uk%7Caa9f27e2dcc5426fff0e08d6a26b8bad%7C925e5e137a8344cbb28144e1c700f7e5%7C1%7C0%7C636874980116819527sdata=eXxpHC6N5HvqMm%2FANrXSTgJ%2B4TrmoXFouYnT8DYHbVg%3Dreserved=0
Author: Antoine Beaupré
Bug-Debian:
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.debian.org%2F918841data=02%7C01%7Cdan.poltawski%40tnp.net.uk%7Caa9f27e2dcc5426fff0e08d6a26b8bad%7C925e5e137a8344cbb28144e1c700f7e5%7C1%7C0%7C636874980116819527sdata=Nc%2FhVL6OtNP9xDC%2FDNd13UBCbGlJQQ%2Fpc5HcTeYegyM%3Dreserved=0
Origin: Debian
Bug:
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fshow_bug.cgi%3Fid%3D1653855data=02%7C01%7Cdan.poltawski%40tnp.net.uk%7Caa9f27e2dcc5426fff0e08d6a26b8bad%7C925e5e137a8344cbb28144e1c700f7e5%7C1%7C0%7C636874980116819527sdata=dxW4DrP2EZkKB2KwDIGp4ujl2j9GP0aGVDFlkco6k%2FY%3Dreserved=0
Forwarded: not-needed
Last-Update: 2019-01-22
--- systemd-215.orig/src/journal/journald-server.c
+++ systemd-215/src/journal/journald-server.c
@@ -602,7 +602,10 @@ static void dispatch_message_real(
r = get_process_cmdline(ucred->pid, 0, false, );
if (r >= 0) {
-x = strappenda("_CMDLINE=", t);
+/* At most _SC_ARG_MAX (2MB usually), which is
+
Re: Contacting maintainers about no-dsa
On Mon, Mar 11, 2019 at 10:48:24AM +0100, Sylvain Beucler wrote: > A few days passed, I assume we reached consensus :) :) indeed. > I rephrased to explain this is not required. Also added the "no-dsa" > keyword in the previous section and clarified that one can fix a no-dsa > if they want to. nice, thank you. -- tschau, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Contacting maintainers about no-dsa
Hi, On 08/03/2019 15:54, Holger Levsen wrote: > On Fri, Mar 08, 2019 at 12:22:40PM +0100, Sylvain Beucler wrote: >> I was about do contact the nettle and gnutls maintainers, but after >> discussing with Emilio on IRC it appears that we do not contact >> maintainers for this anymore. >> >> Should we delete the section? > yes, please. Maybe it should however mention that its possible to fix > non-dsa issues if one wants to? A few days passed, I assume we reached consensus :) I rephrased to explain this is not required. Also added the "no-dsa" keyword in the previous section and clarified that one can fix a no-dsa if they want to. Cheers! Sylvain
