Re: MySQL 5.5 EOL before Debian 8 LTS ends
Hi, On 01/23/2018 10:32 PM, Markus Koschany wrote: Am 23.01.2018 um 11:41 schrieb Lars Tangvald: Hi, On 01/22/2018 04:35 PM, Markus Koschany wrote: [...] I also think it makes sense to take a smaller step and upgrade from 5.5 to 5.6. Are there any known issues with 5.6 or can you share any information about expected regressions with reverse-dependencies? I can't find much of anything that has changed from 5.5 to 5.6 in terms of default behavior, except for NO_ENGINE_SUBSTITUTION being the default sql_mode (https://dev.mysql.com/doc/refman/5.6/en/sql-mode.html#sqlmode_no_engine_substitution). I'll do some more digging, but I don't think there should be much impact on reverse-dependencies. Some options were removed https://dev.mysql.com/doc/refman/5.6/en/server-options.html (often renamed). We did see quite a few regressions of that type for users upgrading from 5.5 to 5.7, but almost all were because the default 5.5 config in Ubuntu packaging contained options that were removed in 5.7. What do you (and other on this list) think about the following plan: We could introduce a mysql-5.6 package already at the start of Jessie LTS in June, so that LTS users are able to test this new version without having to switch from 5.5. Then in 2019, when the security support for MySQL has ended, we perform an upgrade from 5.5 to 5.6. Is this a viable plan and could both packages coexist? Regards, Markus Ubuntu 14.04 something like this; 5.6 is available but 5.5 is the default. This works for the packages with versioned names: server, client and testsuite, while the rest would be dropped from the 5.6 source. Robie, this was implemented before my time, but I seem to remember comments about it causing some issues in Ubuntu. Do you recall what that was? -- Lars
Re: python-crypto / pycryptodome / CVE-2018-6594
Hi Brian On Thu, Feb 08, 2018 at 08:20:22AM +1100, Brian May wrote: > Hello, > > According to the upstream bug report: > https://github.com/dlitz/pycrypto/issues/253 > > "This bug is prevalent. It exists in PyCryptodome and libgcrypt (if used > directly to encrypt messages)." > > Anyone know what the connection is between these python libraries and > libgcrypt? Should libgcrypt be marked as vulnerable too? > > I believe python-crypto / pycryptodome are native Python implementations > that don't use gcrypt, while gcrypt is a native C library that doesn't > use python-crypto / pycryptodome. Just replying for the 'should libgcrypt be marked as vulnerable too' part. At first glance I would say the CVE should not be reused for libgcrypt, since it's different codebasis and if the issue is present there a new CVE for libgcrypt would possibly be appropriate (unless MITRE states otherwise). Regards, Salvatore
Re: Bug#889285: bind9: CVE-2017-3139 affects debian too: assertion failure in validator.c:1858
On Sat, Feb 03, 2018 at 05:17:01PM +0100, Salvatore Bonaccorso wrote: > > The bug was about CVE-2017-3137, it's never a good idea to mix up > things ;-). This is true. However, it appears that Ondrej Zary's comment to #860225 on 2017-09-02 is in fact related to CVE-2017-3139. Since one of the bind9 maintainers was the one to raise the issue of CVE-2017-3139 in that same bug, I don't see a related follow-up report from a user to be problematic. > Anyway thanks that you took action and filled a new bug > for this issue you are experiencing. > > JTR, since Red Hat does not provide much details on the CVE-2017-3139 > we cannot say Debian is affected as well by this very same CVE. Since > it's not clear, what CVE-2017-3139 is in detail, I have removed the > CVE in the subject of this bug. > It is true that there is information provided by RedHat regarding the details of the vulnerability. The RHSA mentioned in #860225 is also linked from this RedHat BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1447743 However, there are no useful details there either. I did some digging and located the bind9 source RPM references in RHSA-2017:1202 and its immediate predecessor. By comparing the packages, I was able to identify the specific patch that was associated with that RHSA. I have attached the patch to this email. The name of the patch refers to another RedHat BZ entry: https://bugzilla.redhat.com/show_bug.cgi?id=1447407 That one is not accessible to the public, so we have no way of knowing the details there. Additionally, the related upstream RT tickets are also not public. Note that the attached patch appears to be based on commit 07dbb507d2913fc35c7edbe3692a976e3248a911 from upstream's git repository: https://source.isc.org/git/bind9.git The upstream changes appear to include a hunk in resolver.c which does not appear in the RedHat patch. That chunk would also not apply to the wheezy version of bind9. > What seem clear is that apparently a fix in Debian wheezy's bind9 > version causes the regression you notices. Thus I suggest the LTS team > to try to find the defective patch introducing the issue and then > issue just a regression update (without referencing CVE-2017-3139. If > its on the other hand clear that Debian wheezy used the very same > patch for a previous issue, and CVE-2017-3139 applies as well for > Debian wheezy, then obviously it's fine to use the CVE). > I examined the changes made from 9.8.4.dfsg.P1-6+nmu2+deb7u15 to 9.8.4.dfsg.P1-6+nmu2+deb7u16, which included fixes for CVE-2017-3136, CVE-2017-3137, and CVE-2017-3138. After examining the changes and comparing them to the related upstream commits, I am convinced that the fix for CVE-2017-3137 in 9.8.4.dfsg.P1-6+nmu2+deb7u16 is correct and complete. I would consider my examination thorough, but not exhaustive owing to the large volume of change and some departures that are clearly a result of the upsteam changes being backported to the bind9 in wheezy. I am further convinced that the problem reported by Ondrej Zary in #860225 and by Vladislav Kurz are both identical occurrences of CVE-2017-3139. In order to confirm the latter hypothesis, I built the current wheezy version of bind9 and ran the dnssec test. The test passed. I then stripped the changes to validator.c from the attached patch and applied the remainder to the current wheezy version of bind9, built, and ran the dnssec test again. This time the test failed. This seems to indicate that the version of bind9 in wheezy is vulnerable to CVE-2017-3139. I then applied the remaining validator.c changes, rebuilt, and ran the dnssec test again. This time the test passed. Based on these findings, I conclude that wheezy bind9 is vulnerable to CVE-2017-3139. I propose to do the following: - Mark CVE-2017-3139 as affecting wheezy in the security tracker - Prepare and upload a version 9.8.4.dfsg.P1-6+nmu2+deb7u20 upload that incorporates the CVE-2017-3139 patch from RedHat (and which closes this bug, #889285) - Release a DLA per the normal procedure I am now in the process of preparing the package for upload, but I will wait a couple of days to allow for any objections and/or suggestions. Regards, -Roberto -- Roberto C. Sánchez >From 1d31a0cf1712d3eb001a686c06fe1225ba48fd04 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Sat, 6 Oct 2012 14:56:33 +1000 Subject: [PATCH] 3391. [bug] DNSKEY that encountered a CNAME failed. [RT #31262] (original commit 07dbb507d2913fc35c7edbe3692a976e3248a911) --- bin/tests/system/dnssec/clean.sh | 1 + bin/tests/system/dnssec/ns3/secure.example.db.in | 4 ++ bin/tests/system/dnssec/ns3/sign.sh | 4 +- bin/tests/system/dnssec/tests.sh | 66 lib/dns/validator.c | 4 ++ 5 files changed, 78 insertions(+), 1 deletion(-) diff --git a/bin/tests/system/dnssec/clean.sh b/bin/tests/system/dnssec/clean.sh index a1c5752..a6b1212 100644
krb5 security vulnerabilities
CVE-2018-5709 points to https://github.com/poojamnit/Kerberos-V5-1.16-Vulnerabilities/tree/master/Integer%20Overflow CVE-2018-5710 points to https://github.com/poojamnit/Kerberos-V5-1.16-Vulnerabilities/tree/master/Denial%20Of%20Service(DoS) Both these pages have the same text: "We have removed all confidential data for security concern. Government organisation or product owner can request for the data regarding the vulnerabilities." Ok, I don't think there is anything we can do about it is this case... -- Brian May
python-crypto / pycryptodome / CVE-2018-6594
Hello, According to the upstream bug report: https://github.com/dlitz/pycrypto/issues/253 "This bug is prevalent. It exists in PyCryptodome and libgcrypt (if used directly to encrypt messages)." Anyone know what the connection is between these python libraries and libgcrypt? Should libgcrypt be marked as vulnerable too? I believe python-crypto / pycryptodome are native Python implementations that don't use gcrypt, while gcrypt is a native C library that doesn't use python-crypto / pycryptodome. Regards -- Brian May https://linuxpenguins.xyz/brian/
Re: [Secure-testing-commits] [Git][security-tracker-team/security-tracker][master] add python2.6, 2.7 and claim 2.7
Abhijith PA writes: >> Do you have any objections to marking python2.6 and python2.7 as no-DSA >> in wheezy too? > > No, I don't have any objection. :) > I tried to reproduce this CVE with the given POC from upstream bug > report. But 8 out of 10 I didn't see any. As security team already > marked it as no-dsa we can do the same. Done. -- Brian May
Re: [Secure-testing-commits] [Git][security-tracker-team/security-tracker][master] Readd krb5 to dla-needed.txt
On Wed, 7 Feb 2018, Brian May wrote: Abhijith PA writes: On Wednesday 07 February 2018 12:38 PM, Brian May wrote: Markus Koschany writes: +krb5 + NOTE: lts-do-not-call +-- What does lts-do-not-call mean? See security-tracker/data/packages/lts-do-not-call . krb5 doesn't appear to be in this list? But you can find its maintainer, Sam Hartman, at the beginning of that file. Thorsten
[SECURITY] [DLA-1271-1] postgresql-9.1 security update
Package: postgresql-9.1 Version: 9.1.24lts2-0+deb7u2 CVE ID : CVE-2018-1053 A vulnerabilities has been found in the PostgreSQL database system: CVE-2018-1053 Tom Lane discovered that pg_upgrade, a tool used to upgrade PostgreSQL database clusters, creates temporary files containing password hashes that are world-readable. For Debian 7 "Wheezy", this problem has been fixed in version 9.1.24lts2-0+deb7u2. We recommend that you upgrade your postgresql-9.1 packages. Further information about Debian LTS security advisories, how to apply these updates to your system and frequently asked questions can be found at: https://wiki.debian.org/LTS signature.asc Description: PGP signature
January Report
Hi, January 2018 was my 17th month as a payed Debian LTS contributor. I was allocated 18.25 hours. I have spent all of them doing the following tasks: * Continue my libav work: - Continue to investigate libav CVE-2015-8216: Probably affected, but I am still unable to take final conclusions. If I can't conclude on this issue next month, I will probably have to let it by side and continue on other problems. - Investigate FPE (reported last month) and propose to merge a ffmpeg commit apperently addressing this issue: https://lists.debian.org/debian-lts/2018/01/msg00077.html Diego later had a look at the issue, confirmed it and merged the ffmpeg commit addressing it. However the status of this vulnerability in other branches could not be clearly characterized. Status of libav in Wheezy: The backlog is still very high and I clearly doubt that I will be able to handle all of it until the end of Wheezy LTS. There are several reasons for that, but the most important one is that I don't have most of the reproducers, and fixing/investigating these issues without them is going to be way more time expensive. Unfortunately I doubt to be ever able to get these reproducers because the Google team that reported the issues couldn't find them anymore. * Continue my Ming work: - Finish to test my patch for ming CVE-2017-16898, get it merged by upstream and ship it in ming 1:0.4.4-1.1+deb7u6 (DLA 1240-1) together with patches for CVE-2017-11732 and CVE-2017-16883 from last month. - Investigate ming CVEs CVE-2018-5294, CVE-2018-5251, CVE-2018-6315 and CVE-2018-6359, request CVE IDs when needed, write patches fixing these issues and get patches merged. I will upload these fixes as part of 1:0.4.4-1.1+deb7u7 next month. - Investigate ming issue #102, which is actually a duplicate of CVE-2017-9988 (already fixed in Wheezy). - Find lots of code duplication in listfdb module. Probably more than 5+ vulnerabilities involved: Document and report them: CVE-2018-6358 (#104), #106 and #107. * Continue my work on lame: - It turned out that Fabian wasn't aware that we were waiting for his patch, but after getting in touch with him he kindly submitted a patch draft (thanks Fabian !). - I have tested the patch draft with my set of test samples and couldn't find any regressions, but nevertheless I still consider these changes to be regression-risky and I'll only upload them if the security team agrees to update Jessie at the same time. * Investigate CVE-2018-6544 in mupdf: Could not reproduce the issue, codebase is very different. Start to analyse the issue, probably not affected. I'll publish the result of my work in the next days. Best Regards, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com 4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA
Re: Upload mailman
Hi, On Wed, February 7, 2018 06:02, Abhijith PA wrote: > I prepared a LTS security update for mailman. Debdiff is attached. > link: > https://mentors.debian.net/debian/pool/main/m/mailman/mailman_2.1.15-1+deb7u3.dsc Looks good to me. Cheers, Thijs
