Call for testing - libxslt update
Hi, I have prepared an update for libxslt. There are several changes, so I'd appreciate some more testing. I have verified some of the fixes with the test cases from upstream or my own. However there were a couple of patches that require clang's address sanitizer, which is not available in wheezy (as it was only introduced in clang 3.1). There was another patch with no test case that I couldn't verify. For a potential Jessie update, all patches should apply cleanly except for 0011 which isn't needed there as it's already included in 1.1.28. For unstable, we should get 1.1.29 uploaded, which includes all the fixes. I have just reported a bug about that. Debdiff is at https://people.debian.org/~pochu/lts/libxslt/wheezy.debdiff Packages (amd64) and source at https://people.debian.org/~pochu/lts/libxslt/ Thanks, Emilio
Re: cacti LTS
Hi Paul,
> Just in case somebody starts working on it, I'd like to review proposed
> uploads of cacti to LTS. CVE-2016-2313 was initially wrongly fixed (a
> sledgehammer for a simple nail). CVE-2016-3659 still needs reproducing
> in Debian and a check if the fix by a contributer in the upstream bug
> report is causing other damage. The third CVE has a trivial patch.
I've had a look at this. I set up cacti on a wheezy VM, and I could reproduce
CVE-2016-3172. However, like you, I couldn't reproduce CVE-2016-3659. I don't
know if we are vulnerable or not, maybe we are and the attack needs some
changes. In any case, I think the fix is very safe, sanitizing parenthesis, so I
think we can just ship it. What do you think? Please see the attached debdiff.
Thanks,
Emilio
diff -Nru cacti-0.8.8a+dfsg/debian/changelog cacti-0.8.8a+dfsg/debian/changelog
--- cacti-0.8.8a+dfsg/debian/changelog 2016-02-24 21:00:15.0 +0100
+++ cacti-0.8.8a+dfsg/debian/changelog 2016-06-25 21:58:57.0 +0200
@@ -1,3 +1,13 @@
+cacti (0.8.8a+dfsg-5+deb7u9) wheezy-security; urgency=medium
+
+ * Non-maintainer upload.
+ * debian/patches/CVE-2016-3172-sql-injection.patch
++ CVE-2016-3172: Fix sql injection in tree.php.
+debian/patches/CVE-2016-3659-sql-injection.patch
++ CVE-2016-3659: Fix sql injection in graph_view.php.
+
+ -- Emilio Pozuelo Monfort Sat, 25 Jun 2016 21:57:43 +0200
+
cacti (0.8.8a+dfsg-5+deb7u8) wheezy-security; urgency=high
* CVE-2015-8377: Fix SQL Injection vulnerability in graphs_new.php
diff -Nru cacti-0.8.8a+dfsg/debian/patches/CVE-2016-3172-sql-injection.patch
cacti-0.8.8a+dfsg/debian/patches/CVE-2016-3172-sql-injection.patch
--- cacti-0.8.8a+dfsg/debian/patches/CVE-2016-3172-sql-injection.patch
1970-01-01 01:00:00.0 +0100
+++ cacti-0.8.8a+dfsg/debian/patches/CVE-2016-3172-sql-injection.patch
2016-06-25 21:57:13.0 +0200
@@ -0,0 +1,10 @@
+--- a/tree.php 2016/05/08 15:10:45 7804
a/tree.php 2016/05/08 15:35:30 7805
+@@ -153,6 +153,7 @@
+ /* = input validation = */
+ input_validate_input_number(get_request_var("id"));
+ input_validate_input_number(get_request_var("tree_id"));
++ input_validate_input_number(get_request_var("parent_id"));
+ /* */
+
+ if (!empty($_GET["id"])) {
diff -Nru cacti-0.8.8a+dfsg/debian/patches/CVE-2016-3659-sql-injection.patch
cacti-0.8.8a+dfsg/debian/patches/CVE-2016-3659-sql-injection.patch
--- cacti-0.8.8a+dfsg/debian/patches/CVE-2016-3659-sql-injection.patch
1970-01-01 01:00:00.0 +0100
+++ cacti-0.8.8a+dfsg/debian/patches/CVE-2016-3659-sql-injection.patch
2016-06-25 21:57:24.0 +0200
@@ -0,0 +1,13 @@
+--- a/lib/functions.php2016/03/06 23:29:28 7800
a/lib/functions.php2016/05/08 14:41:02 7801
+@@ -2138,8 +2138,8 @@
+@arg $string - the original raw search string
+@returns - the sanitized search string */
+ function sanitize_search_string($string) {
+- static $drop_char_match = array('^', '$', '<', '>', '`', '\'', '"',
'|', ',', '?', '+', '[', ']', '{', '}', '#', ';', '!', '=', '*');
+- static $drop_char_replace = array(' ', ' ', ' ', ' ', '', '', ' ', '
', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ');
++ static $drop_char_match = array('(',')','^', '$', '<', '>', '`',
'\'', '"', '|', ',', '?', '+', '[', ']', '{', '}', '#', ';', '!', '=', '*');
++ static $drop_char_replace = array('','',' ', ' ', ' ', ' ', '', '', '
', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ');
+
+ /* Replace line endings by a space */
+ $string = preg_replace('/[\n\r]/is', ' ', $string);
diff -Nru cacti-0.8.8a+dfsg/debian/patches/series
cacti-0.8.8a+dfsg/debian/patches/series
--- cacti-0.8.8a+dfsg/debian/patches/series 2016-02-24 21:00:15.0
+0100
+++ cacti-0.8.8a+dfsg/debian/patches/series 2016-06-25 21:55:31.0
+0200
@@ -28,3 +28,5 @@
CVE-2015-8369_sql_injection_in_graph.php.patch
CVE-2015-8377-sql-injection-in-graph-php-host_new_graphs_save.patch
CVE-2015-8604-sql-injection-in-graphs_new.patch
+CVE-2016-3172-sql-injection.patch
+CVE-2016-3659-sql-injection.patch
Re: claiming tiff
On 26/06/16 02:19, Bálint Réczey wrote: > Hi, > > There are newly discovered vulnerabilities in tiff [1]. > > I no one objects I plan looking into them and working with the > maintainer(s) to get them fixed in Wheezy LTS and in newer > releases. I looked at this yesterday. These CVEs aren't fixed upstream yet. I forwarded all the new CVEs (and some old ones) to upstream yesterday, so hopefully that will change. Cheers, Emilio
Re: cacti LTS
On 26/06/16 09:23, Paul Gevers wrote:
> Hi Emilio
>
> On 25-06-16 22:03, Emilio Pozuelo Monfort wrote:
>>> Just in case somebody starts working on it, I'd like to review proposed
>>> uploads of cacti to LTS. CVE-2016-2313 was initially wrongly fixed (a
>>> sledgehammer for a simple nail). CVE-2016-3659 still needs reproducing
>>> in Debian and a check if the fix by a contributer in the upstream bug
>>> report is causing other damage. The third CVE has a trivial patch.
>>
>> I've had a look at this. I set up cacti on a wheezy VM, and I could reproduce
>> CVE-2016-3172. However, like you, I couldn't reproduce CVE-2016-3659. I don't
>> know if we are vulnerable or not, maybe we are and the attack needs some
>> changes. In any case, I think the fix is very safe, sanitizing parenthesis,
>> so I
>> think we can just ship it. What do you think? Please see the attached
>> debdiff.
>
> The patch for CVE-2016-3659 is accepted by upstream, so should be OK to
> apply.
>
> The issue with CVE-2016-2313 has been resolved upstream, the
> sledgehammer has been replaced by an appropriate hammer for the size of
> the nail:
> https://github.com/Cacti/cacti/commit/6e5f3be49b3f52e30c88ec75a576f89bb72c4e52
>
> I believe CVE-2016-2313 should be included in this fix.
Certainly! I have backported the fix and included in this new debdiff.
Unfortunately I'm not sure how to trigger the bug.
> Please be advised that since my previous e-mail, I actually created a
> brute force regression test for cacti, see
> http://anonscm.debian.org/cgit/pkg-cacti/cacti.git/tree/debian/tests/check-all-pages
Ah, nice. I don't think we have ci.debian.net running for wheezy, but this can
be useful to do some basic testing after an update.
Cheers,
Emilio
diff -Nru cacti-0.8.8a+dfsg/debian/changelog cacti-0.8.8a+dfsg/debian/changelog
--- cacti-0.8.8a+dfsg/debian/changelog 2016-02-24 21:00:15.0 +0100
+++ cacti-0.8.8a+dfsg/debian/changelog 2016-06-26 10:18:07.0 +0200
@@ -1,3 +1,15 @@
+cacti (0.8.8a+dfsg-5+deb7u9) wheezy-security; urgency=medium
+
+ * Non-maintainer upload.
+ * debian/patches/CVE-2016-3172-sql-injection.patch:
++ CVE-2016-3172: Fix sql injection in tree.php.
+ * debian/patches/CVE-2016-3659-sql-injection.patch:
++ CVE-2016-3659: Fix sql injection in graph_view.php.
+ * debian/patches/CVE-2016-2313-authentication-bypass.patch:
++ CVE-2016-2313: Fix authentication bypass.
+
+ -- Emilio Pozuelo Monfort Sun, 26 Jun 2016 10:18:04 +0200
+
cacti (0.8.8a+dfsg-5+deb7u8) wheezy-security; urgency=high
* CVE-2015-8377: Fix SQL Injection vulnerability in graphs_new.php
diff -Nru
cacti-0.8.8a+dfsg/debian/patches/CVE-2016-2313-authentication-bypass.patch
cacti-0.8.8a+dfsg/debian/patches/CVE-2016-2313-authentication-bypass.patch
--- cacti-0.8.8a+dfsg/debian/patches/CVE-2016-2313-authentication-bypass.patch
1970-01-01 01:00:00.0 +0100
+++ cacti-0.8.8a+dfsg/debian/patches/CVE-2016-2313-authentication-bypass.patch
2016-06-26 10:16:50.0 +0200
@@ -0,0 +1,23 @@
+Backport fix for CVE-2016-2313.
+
+This is http://svn.cacti.net/viewvc?view=rev&revision=7770
+and
https://github.com/Cacti/cacti/commit/6e5f3be49b3f52e30c88ec75a576f89bb72c4e52
+
+Bug: http://bugs.cacti.net/view.php?id=2656
+
+--- a/auth_login.php
b/auth_login.php
+@@ -86,6 +86,13 @@
+ /* Locate user in database */
+ $user = db_fetch_row("SELECT * FROM user_auth WHERE username =
" . $cnn_id->qstr($username) . " AND realm = 2");
+
++ if (!$user && read_config_option('user_template') == '0') {
++ cacti_log("ERROR: User '" . $username . "'
authenticated by Web Server, but a Template User is not defined in Cacti.
Exiting.", false, 'AUTH');
++ $username = htmlspecialchars($username);
++ auth_display_custom_error_message("$username
authenticated by Web Server, but a Template User is not defined in Cacti.");
++ exit;
++ }
++
+ break;
+ case "3":
+ /* LDAP Auth */
diff -Nru cacti-0.8.8a+dfsg/debian/patches/CVE-2016-3172-sql-injection.patch
cacti-0.8.8a+dfsg/debian/patches/CVE-2016-3172-sql-injection.patch
--- cacti-0.8.8a+dfsg/debian/patches/CVE-2016-3172-sql-injection.patch
1970-01-01 01:00:00.0 +0100
+++ cacti-0.8.8a+dfsg/debian/patches/CVE-2016-3172-sql-injection.patch
2016-06-25 21:57:13.0 +0200
@@ -0,0 +1,10 @@
+--- a/tree.php 2016/05/08 15:10:45 7804
a/tree.php 2016/05/08 15:35:30 7805
+@@ -153,6 +153,7 @@
+ /* = input validation = */
+ input_validate_input_number(get_reque
Re: claiming tiff
On 26/06/16 16:10, Bálint Réczey wrote: > Added that information in dla-needed.txt. Thanks. I added links to each cve in data/CVE/list but forgot to add a note to dla-needed. > In that case I don't claim them yet. Let's see how upstream responds. OK. Cheers, Emilio
LTS report for June 2016
This month I was allocated 16 hours to work on Debian-LTS. I spent this time doing the following: - Prepared, tested and uploaded libxslt. - Prepared and tested an update for clamav. However the maintainer asked me to wait until a regression in the Jessie update can be addressed. - Prepared, tested and uploaded nss. - Triaged a lot of tiff security bugs, forwarding them upstream. - Prepared and tested an update for cacti. Thanks, Emilio
Re: Wheezy update of gdk-pixbuf?
Hi, On 15/07/16 00:26, b...@decadent.org.uk wrote: > Hello dear maintainer(s), > > the Debian LTS team would like to fix the security issues which are > currently open in the Wheezy version of gdk-pixbuf: > https://security-tracker.debian.org/tracker/source-package/gdk-pixbuf > > Would you like to take care of this yourself? As a gdk-pixbuf/GNOME maintainer, I'll take care of this, unless one of the other co-maintainers wants to look at it. Cheers, Emilio
Re: CVE-2016-2313 fix wrong
On 28/07/16 13:35, Matus UHLAR - fantomas wrote:
> Hello,
>
> i believe the fix for CVE-2016-2313 in
> CVE-2016-2313-authentication-bypass.patch is invalid.
>
> Quoting the authorization settings:
>
> Web Basic Authentication - Authentication is handled by the web server.
> Users can be added or created automatically on first login if the Template
> User is defined, otherwise the defined guest permissions will be used.
> this patch makes authentication fail when the template user is not set, but
> the guest user is set, while in such case guest user should be used.
>
> Unfortunely the original bug report does not have fix for this, and the last
> comment says:
>
> "
> (0007083)
> cigamit (developer)
> 2016-03-06 11:01
>
> agree and it's been re-fixed in 1.0. Will backport shortly. "
>
>
> I believe that the patch could be fixed simply by changing the test from:
>
>
> + if (!$user && read_config_option('user_template') == '0') {
>
> to something like:
>
> + if (!$user && read_config_option('user_template') == '0' &&
> read_config_option('guest_user') == '0') {
>
> and of course the error messages:
>
> + cacti_log("ERROR: User '" . $username . "'
> authenticated
> by Web Server, but a Template User is not defined in Cacti. Exiting.", false,
> 'AUTH');
> + $username = htmlspecialchars($username);
> + auth_display_custom_error_message("$username
> authenticated by Web Server, but a Template User is not defined in Cacti.");
>
> to:
>
> + cacti_log("ERROR: User '" . $username . "'
> authenticated
> by Web Server, but a Template User and a Guest User are not defined in Cacti.
> Exiting.", false, 'AUTH');
> + $username = htmlspecialchars($username);
> + auth_display_custom_error_message("$username
> authenticated by Web Server, but a Template User and a Guest User are not
> defined in Cacti.");
>
> this seems to work on our cacti installation.
Thanks for the report. I'll look at it later today.
Cheers,
Emilio
Re: CVE-2016-2313 fix wrong
On 28/07/16 14:59, Matus UHLAR - fantomas wrote: >> On 28/07/16 13:35, Matus UHLAR - fantomas wrote: >>> i believe the fix for CVE-2016-2313 in >>> CVE-2016-2313-authentication-bypass.patch is invalid. > > On 28.07.16 14:26, Emilio Pozuelo Monfort wrote: >> Thanks for the report. I'll look at it later today. > > I have posted cacti bug http://bugs.cacti.net/view.php?id=2697 > and attached patch > http://bugs.cacti.net/file_download.php?file_id=1229&type=bug > > that should fix the issue. The patch is to be applied to "fixed" version > in debian The patch looks sensible to me, but I'd like to give upstream a few days to comment. BTW you may want to send a pull request at https://github.com/Cacti/cacti Cheers, Emilio
Icedtea plugin
Hi,
Currently, icedtea-plugin depends on icedtea-6-plugin, i.e. Java6. Given
openjdk-6 is unsupported, we should change it to depend on icedtea-7-plugin
instead. See the attached source debdiff (the control file is autogenerated).
Thoughts?
If no-one objects, I will upload that soon.
Cheers,
Emilio
diff -Nru icedtea-web-1.4/debian/changelog icedtea-web-1.4/debian/changelog
--- icedtea-web-1.4/debian/changelog2013-10-02 17:16:31.0 +0200
+++ icedtea-web-1.4/debian/changelog2016-07-31 18:52:56.0 +0200
@@ -1,3 +1,9 @@
+icedtea-web (1.4-3~deb7u3) UNRELEASED; urgency=medium
+
+ * Default to icedtea-7-plugin. Java6 is unsupported.
+
+ -- Emilio Pozuelo Monfort Sun, 31 Jul 2016 18:52:19 +0200
+
icedtea-web (1.4-3~deb7u2) wheezy-security; urgency=high
* Non-maintainer upload by the Security Team.
diff -Nru icedtea-web-1.4/debian/control icedtea-web-1.4/debian/control
--- icedtea-web-1.4/debian/control 2013-10-02 17:16:31.0 +0200
+++ icedtea-web-1.4/debian/control 2016-07-31 19:17:43.0 +0200
@@ -27,18 +27,7 @@
Package: icedtea-plugin
Section: web
Architecture: all
-Depends: icedtea-6-plugin, ${misc:Depends}
-Description: web browser plugin to execute Java applets (dependency package)
- IcedTeaPlugin is a web browser plugin to execute Java applets, supporting
- LiveConnect/JavaScript. It is targeted for xulrunner-1.9 and compatible
- browsers that support the NPAPI.
- .
- This is a dependency package, it can be safely removed after upgrade.
-
-Package: icedtea6-plugin
-Section: web
-Architecture: all
-Depends: icedtea-6-plugin, ${misc:Depends}
+Depends: icedtea-7-plugin, ${misc:Depends}
Description: web browser plugin to execute Java applets (dependency package)
IcedTeaPlugin is a web browser plugin to execute Java applets, supporting
LiveConnect/JavaScript. It is targeted for xulrunner-1.9 and compatible
@@ -90,3 +79,14 @@
IcedTeaPlugin is a web browser plugin to execute Java applets, supporting
LiveConnect/JavaScript. It is targeted for xulrunner-1.9 and compatible
browsers that support the NPAPI.
+
+Package: icedtea6-plugin
+Section: web
+Architecture: all
+Depends: icedtea-6-plugin, ${misc:Depends}
+Description: web browser plugin to execute Java applets (dependency package)
+ IcedTeaPlugin is a web browser plugin to execute Java applets, supporting
+ LiveConnect/JavaScript. It is targeted for xulrunner-1.9 and compatible
+ browsers that support the NPAPI.
+ .
+ This is a dependency package, it can be safely removed after upgrade.
diff -Nru icedtea-web-1.4/debian/rules icedtea-web-1.4/debian/rules
--- icedtea-web-1.4/debian/rules2013-10-02 17:16:31.0 +0200
+++ icedtea-web-1.4/debian/rules2016-07-31 18:52:15.0 +0200
@@ -54,7 +54,7 @@
else
is7_default = yes
default_version = 7
- ifneq (,$(filter $(distrel), wheezy sid))
+ ifneq (,$(filter $(distrel), sid))
default_plugin_version = 6
else
default_plugin_version = 7
Re: Coordinating uploads with identical tarballs
On 01/08/16 21:29, Moritz Mühlenhoff wrote: > Hi, > when making uploads with an identical tarball in lts and stable-security > you really need to coordinate with t...@security.debian.org! Due to dak's > crappy orig tarball handling only of the uploads can be made with the > tarball included and if you race to the upload without coordination you're > only causing extra work on our side as it happened for the openjdk-7 > DLA :-/ Very sorry about that. I didn't think about it. Thanks for letting me know - I'll keep that in mind for future updates. Cheers, Emilio
Re: Icedtea plugin
On 31/07/16 19:41, Roberto C. Sánchez wrote: > On Sun, Jul 31, 2016 at 07:34:28PM +0200, Emilio Pozuelo Monfort wrote: >> Hi, >> >> Currently, icedtea-plugin depends on icedtea-6-plugin, i.e. Java6. Given >> openjdk-6 is unsupported, we should change it to depend on icedtea-7-plugin >> instead. See the attached source debdiff (the control file is autogenerated). >> >> Thoughts? >> >> If no-one objects, I will upload that soon. >> > > It looks good to me. Markus said on IRC that another option was to mark icedtea-plugin and icedtea-6-plugin as unsupported. However, I think we should only do that for icedtea-6-plugin, and update the metapackage to depend on Java7. Cheers, Emilio
Re: Icedtea plugin
On 01/08/16 23:26, Markus Koschany wrote: > On 01.08.2016 23:01, Emilio Pozuelo Monfort wrote: >> On 31/07/16 19:41, Roberto C. Sánchez wrote: >>> On Sun, Jul 31, 2016 at 07:34:28PM +0200, Emilio Pozuelo Monfort wrote: >>>> Hi, >>>> >>>> Currently, icedtea-plugin depends on icedtea-6-plugin, i.e. Java6. Given >>>> openjdk-6 is unsupported, we should change it to depend on icedtea-7-plugin >>>> instead. See the attached source debdiff (the control file is >>>> autogenerated). >>>> >>>> Thoughts? >>>> >>>> If no-one objects, I will upload that soon. >>>> >>> >>> It looks good to me. >> >> Markus said on IRC that another option was to mark icedtea-plugin and >> icedtea-6-plugin as unsupported. However, I think we should only do that for >> icedtea-6-plugin, and update the metapackage to depend on Java7. > > Yes, it wouldn't hurt to update the dependency package icedtea-plugin. > As far as I know it has no important reverse-dependencies though, for > instance OpenJDk 6 only suggests it. So we could also just mark it as > unsupported but I leave the decision up to you. I think icedtea-plugin should be kept updated and point to the supported version, so that people can keep it installed and automatically get the next supported version when/if it is changed again, whether in Wheezy or in future releases. Since the change is simple, I'll look at uploading it soon. Cheers, Emilio
Re: Redis not uploaded and timely security announcements
On 02/08/16 19:16, Chris Lamb wrote: > Chris Lamb wrote: > >>> DLA-577-1 has been issued two days ago but redis hasn't been uploaded >>> yet. > [..] >> Could these checks be automated instead of relying on a diligent >> front-desk..?) > > I've pushed such a script as bin/lts-missing-uploads.py. Please consider > it to be proof-of-concept right now. Cool. Maybe (once it's polished) we could run it in a cron job and send the output to the list? Also a lts-missing-dla could be another nice addition. Cheers, Emilio
Re: Bug#832908: mongodb: CVE-2016-6494: world-readable .dbshell history file: LTS update and upgrade handling
On 02/08/16 23:57, Ola Lundqvist wrote: > Hi Chris > > The reason I do not simply set the umask to a fixed value is to use the same > principle as upstream. That is honor the umask set bu the user. There may be > reasons why group read and/or write should be set for example. > > I agree with upstream that the umask should be honored, but not as strictly > as > upstream do. This is why I just override the "world readable" part and let > the > rest be controlled by the user. > > In the working patch you can see that I also set back the umask (just a > little > further down in the file) as it was to just change this specific case of > logging. > > More clear now? What do other programs do for similar files? My .bash_history is 0600 even though my umask is 0022. Having a umask that allows other users to read your files by default doesn't mean sensitive-information should be made available. So perhaps you should ignore if the umask allows the group to read files? Cheers, Emilio
LTS report for July 2016
This month I was allocated 14.70 hours to work on Debian-LTS. I spent 13h doing the following: - Pushed the update for cacti. Investigated regression, waiting for upstream to comment. - Prepared and uploaded update for tardiff - Investigated gdk-pixbuf vulnerability: wheezy not affected (jessie through sid affected) - Improved script to work with python3 - Investigated available tiff fixes. Still many unfixed bugs - Prepared and tested openjdk-7. Uploaded a broken .dsc (sigh), waiting for it to be removed before pushing the update - Checked libical, forwarded issues upstream - Prepared update to switch icedtea-plugin to icedtea-7-plugin - Forwarded extplorer issue upstream Thanks, Emilio
Re: Icedtea plugin
On 02/08/16 19:48, Emilio Pozuelo Monfort wrote: > On 01/08/16 23:26, Markus Koschany wrote: >> On 01.08.2016 23:01, Emilio Pozuelo Monfort wrote: >>> On 31/07/16 19:41, Roberto C. Sánchez wrote: >>>> On Sun, Jul 31, 2016 at 07:34:28PM +0200, Emilio Pozuelo Monfort wrote: >>>>> Hi, >>>>> >>>>> Currently, icedtea-plugin depends on icedtea-6-plugin, i.e. Java6. Given >>>>> openjdk-6 is unsupported, we should change it to depend on >>>>> icedtea-7-plugin >>>>> instead. See the attached source debdiff (the control file is >>>>> autogenerated). >>>>> >>>>> Thoughts? >>>>> >>>>> If no-one objects, I will upload that soon. >>>>> >>>> >>>> It looks good to me. >>> >>> Markus said on IRC that another option was to mark icedtea-plugin and >>> icedtea-6-plugin as unsupported. However, I think we should only do that for >>> icedtea-6-plugin, and update the metapackage to depend on Java7. >> >> Yes, it wouldn't hurt to update the dependency package icedtea-plugin. >> As far as I know it has no important reverse-dependencies though, for >> instance OpenJDk 6 only suggests it. So we could also just mark it as >> unsupported but I leave the decision up to you. > > I think icedtea-plugin should be kept updated and point to the supported > version, so that people can keep it installed and automatically get the next > supported version when/if it is changed again, whether in Wheezy or in future > releases. > > Since the change is simple, I'll look at uploading it soon. Uploaded. I'm not sure whether this deserves a DLA. Probably not, as openjdk-6 is already marked as unsupported, and there already was [1]. Though I could send something similar to that, without a DLA number, if that was deemed convenient. Thoughts, anyone? Cheers, Emilio [1] https://lists.debian.org/debian-lts-announce/2016/05/msg7.html
Re: Security update of firefox-esr for Wheezy
On 04/08/16 23:02, Mike Hommey wrote: > On Thu, Aug 04, 2016 at 07:50:28PM +0200, Guido Günther wrote: >> Hi, >> On Thu, Aug 04, 2016 at 06:32:14PM +0900, Mike Hommey wrote: >>> On Thu, Aug 04, 2016 at 11:04:47AM +0200, Markus Koschany wrote: Hello Mike, Thank you for preparing the security update of firefox-esr. I have just sent a security announcement for your update in Wheezy to the debian-lts-announce mailing list. If you want to take care of this next time, please follow our guidelines which we have outlined at [1]. If this is a burden for you, no problem, we will do our best and take care of the rest. In this case we would like to ask you to send a short reminder to debian-lts, so that we can prepare the announcement in a timely manner. >>> >>> Heh, I hadn't realized that wasn't handled by standard DSAs, sorry about >>> that. That these updates go through the same security-master doesn't >>> help making it obvious they are different. >>> >>> Anyways, I'd rather not have more work to do, so if can send >>> announcements, that works for me. Or you can deal with the backport >>> from back to back. >>> >>> Please note that the next ESR bump (52) will require GCC 4.8, which is >>> not in wheezy, so I won't be building ESR45 for wheezy past 45.8, >>> presumably some time in April next year. >> >> The same is true for icedove. Since this is way before the end of Wheezy >> LTS (31st May 2018) I wonder if we should EOL Firefox/Icedove then or >> try to support this for longer? >> >> I have no idea what features of gcc-4.8 would be required, Mike do you >> know? > > Some C++11 features it supports that GCC 4.7 doesn't. We may want / need to backport GCC 4.8 to Wheezy then. Chromium is already unsupported, so it's either that, or leave Wheezy with no supported browsers. We probably want the former. Cheers, Emilio
Re: Icedtea plugin
On 06/08/16 10:38, Markus Koschany wrote: > On 06.08.2016 10:18, Guido Günther wrote: >> Hi, >> On Fri, Aug 05, 2016 at 11:49:33PM +0200, Emilio Pozuelo Monfort wrote: >>> On 02/08/16 19:48, Emilio Pozuelo Monfort wrote: >>>> On 01/08/16 23:26, Markus Koschany wrote: >>>>> On 01.08.2016 23:01, Emilio Pozuelo Monfort wrote: >>>>>> On 31/07/16 19:41, Roberto C. Sánchez wrote: >>>>>>> On Sun, Jul 31, 2016 at 07:34:28PM +0200, Emilio Pozuelo Monfort wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Currently, icedtea-plugin depends on icedtea-6-plugin, i.e. Java6. >>>>>>>> Given >>>>>>>> openjdk-6 is unsupported, we should change it to depend on >>>>>>>> icedtea-7-plugin >>>>>>>> instead. See the attached source debdiff (the control file is >>>>>>>> autogenerated). >>>>>>>> >>>>>>>> Thoughts? >>>>>>>> >>>>>>>> If no-one objects, I will upload that soon. >>>>>>>> >>>>>>> >>>>>>> It looks good to me. >>>>>> >>>>>> Markus said on IRC that another option was to mark icedtea-plugin and >>>>>> icedtea-6-plugin as unsupported. However, I think we should only do that >>>>>> for >>>>>> icedtea-6-plugin, and update the metapackage to depend on Java7. >>>>> >>>>> Yes, it wouldn't hurt to update the dependency package icedtea-plugin. >>>>> As far as I know it has no important reverse-dependencies though, for >>>>> instance OpenJDk 6 only suggests it. So we could also just mark it as >>>>> unsupported but I leave the decision up to you. >>>> >>>> I think icedtea-plugin should be kept updated and point to the supported >>>> version, so that people can keep it installed and automatically get the >>>> next >>>> supported version when/if it is changed again, whether in Wheezy or in >>>> future >>>> releases. >>>> >>>> Since the change is simple, I'll look at uploading it soon. >>> >>> Uploaded. >>> >>> I'm not sure whether this deserves a DLA. Probably not, as openjdk-6 is >>> already >>> marked as unsupported, and there already was [1]. Though I could send >>> something >>> similar to that, without a DLA number, if that was deemed convenient. >>> Thoughts, >>> anyone? >> >> I was under the impression that every upload to wheezy-security gets a >> DLA since it's a security archive. That's why I e.g. put out DLAs for >> enigmail and mozilla-devscripts although these weren't security >> updates per se but rebuilds due to the new icedove. > > Now that the decision has been made to update icedtea-plugin I agree > that it needs some sort of announcement to inform LTS users. I would > have mentioned it as part of the OpenJDK 7 announcement as a side note > but a standalone DLA will also do. ftr, I have sent an announcement, which was reviewed on irc. Cheers, Emilio
Re: Security update of firefox-esr for Wheezy
On 07/08/16 22:17, Raphael Hertzog wrote: > On Sun, 07 Aug 2016, Guido Günther wrote: >> I too think I would be good to support Firefox & Icedove until Wheezy >> goes EOL. Wd could backport gcc 4.8 from Jessie with only C/C++ enabled. > > And obviously, we make no change to gcc-defaults. > > Shall we mark gcc-4.8 as unsupported in wheezy, explaining that its only > purpose is to enable build of other packages? That would make sense. I'll see if I can take a look at this. Cheers, Emilio
Re: CVE-2016-2313 fix wrong
On 29/07/16 20:05, Emilio Pozuelo Monfort wrote: > On 28/07/16 14:59, Matus UHLAR - fantomas wrote: >>> On 28/07/16 13:35, Matus UHLAR - fantomas wrote: >>>> i believe the fix for CVE-2016-2313 in >>>> CVE-2016-2313-authentication-bypass.patch is invalid. >> >> On 28.07.16 14:26, Emilio Pozuelo Monfort wrote: >>> Thanks for the report. I'll look at it later today. >> >> I have posted cacti bug http://bugs.cacti.net/view.php?id=2697 >> and attached patch >> http://bugs.cacti.net/file_download.php?file_id=1229&type=bug >> >> that should fix the issue. The patch is to be applied to "fixed" version >> in debian > > The patch looks sensible to me, but I'd like to give upstream a few days to > comment. > > BTW you may want to send a pull request at https://github.com/Cacti/cacti I have just uploaded a fix for this. Cheers, Emilio
Re: Security update of firefox-esr for Wheezy
On 08/08/16 10:20, Raphael Hertzog wrote: > On Mon, 08 Aug 2016, Emilio Pozuelo Monfort wrote: >>> Shall we mark gcc-4.8 as unsupported in wheezy, explaining that its only >>> purpose is to enable build of other packages? >> >> That would make sense. >> >> I'll see if I can take a look at this. > > The problematic part is likely libstdc++. I would expect the new gcc to > assume that you have the corresponding libstdc++. > > Mike once told that Firefox has special code to avoid the increased > dependency but that might not be the case of other packages that we might > want to build with a newer gcc. I had a look at this. Matthias pointed me to gcc-mozilla from Ubuntu, which is GCC 4.8.4 shipped in one package. I built that for Wheezy, then built firefox_49.0~b1-1 using that. I had to disable PIE, but other than that it built fine and seems to work well. So I think we could go this route. For GCC at least we need to drop the gfdl bits, and we may want to update to 4.8.5, but in general it seems to work well. I was hitting a build failure that I could workaround by using an interactive shell. No idea if it's a pbuilder problem or what. That would need a little investigation. For Firefox, I didn't look much at the PIE issue. I just saw that it fails on a simple configure test when enabled, at the linker stage. With pie disabled, everything went well. Cheers, Emilio
Re: Security update of firefox-esr for Wheezy
On 02/09/16 08:39, Guido Günther wrote: > On Fri, Sep 02, 2016 at 01:26:05AM +0200, Emilio Pozuelo Monfort wrote: >> On 08/08/16 10:20, Raphael Hertzog wrote: >>> On Mon, 08 Aug 2016, Emilio Pozuelo Monfort wrote: >>>>> Shall we mark gcc-4.8 as unsupported in wheezy, explaining that its only >>>>> purpose is to enable build of other packages? >>>> >>>> That would make sense. >>>> >>>> I'll see if I can take a look at this. >>> >>> The problematic part is likely libstdc++. I would expect the new gcc to >>> assume that you have the corresponding libstdc++. >>> >>> Mike once told that Firefox has special code to avoid the increased >>> dependency but that might not be the case of other packages that we might >>> want to build with a newer gcc. >> >> I had a look at this. Matthias pointed me to gcc-mozilla from Ubuntu, which >> is >> GCC 4.8.4 shipped in one package. I built that for Wheezy, then built >> firefox_49.0~b1-1 using that. I had to disable PIE, but other than that it >> built >> fine and seems to work well. So I think we could go this route. >> >> For GCC at least we need to drop the gfdl bits, and we may want to update to >> 4.8.5, but in general it seems to work well. I was hitting a build failure >> that >> I could workaround by using an interactive shell. No idea if it's a pbuilder >> problem or what. That would need a little investigation. >> >> For Firefox, I didn't look much at the PIE issue. I just saw that it fails >> on a >> simple configure test when enabled, at the linker stage. With pie disabled, >> everything went well. > > That sounds great. Did you put the packages somewhere? I don't think we'll > run into any extra issues with Icedove but it might be worth checking > this out before the current ESR versions go EOL. Packages are at https://people.debian.org/~pochu/lts/gcc/ gcc-mozilla is the one from [1], but putting it here for convenience (you can't dget from launchpad). Let me know if it works for you or if you have any issues. Cheers, Emilio [1] https://launchpad.net/ubuntu/+source/gcc-mozilla
LTS report for August 2016
Hi, This month I was allocated 14.75 hours to work on Debian-LTS. I spent 13.5 hours doing the following: - openjdk-7: after some back and forth, finally pushed the update for openjdk-7 - icedtea-web: pushed the update to make icedtea-plugin default to openjdk-7 - fontconfig: prepared, tested and uploaded security update - tiff: prepared, tested and uploaded an update fixing several vulnerabilities. there still are some unfixed vulnerabilities which I'll look at soon - cacti: prepared and tested and pushed package to fix regression - gcc-4.8 & firefox: looked at building gcc-4.8 (gcc-mozilla) for wheezy. built and tested firefox_49.0~b1-1 against it Thanks, Emilio
Re: updates to find-work
On 07/09/16 00:01, Brian May wrote: > Hello, > > Do we have any sort of handle formal updates to find-work? > > If not, does anybody have any objections if I were to commit the > following change? It adds a --unassigned command line option that only > lists packages that are not taken by anybody. Sounds useful! IOW, no objections. Emilio
Re: Security update of firefox-esr for Wheezy
On 30/09/16 12:21, Guido Günther wrote: > Hi Emilio, > On Sat, Sep 03, 2016 at 12:12:55PM +0200, Emilio Pozuelo Monfort wrote: >> On 02/09/16 08:39, Guido Günther wrote: >>> On Fri, Sep 02, 2016 at 01:26:05AM +0200, Emilio Pozuelo Monfort wrote: >>>> On 08/08/16 10:20, Raphael Hertzog wrote: >>>>> On Mon, 08 Aug 2016, Emilio Pozuelo Monfort wrote: >>>>>>> Shall we mark gcc-4.8 as unsupported in wheezy, explaining that its only >>>>>>> purpose is to enable build of other packages? >>>>>> >>>>>> That would make sense. >>>>>> >>>>>> I'll see if I can take a look at this. >>>>> >>>>> The problematic part is likely libstdc++. I would expect the new gcc to >>>>> assume that you have the corresponding libstdc++. >>>>> >>>>> Mike once told that Firefox has special code to avoid the increased >>>>> dependency but that might not be the case of other packages that we might >>>>> want to build with a newer gcc. >>>> >>>> I had a look at this. Matthias pointed me to gcc-mozilla from Ubuntu, >>>> which is >>>> GCC 4.8.4 shipped in one package. I built that for Wheezy, then built >>>> firefox_49.0~b1-1 using that. I had to disable PIE, but other than that it >>>> built >>>> fine and seems to work well. So I think we could go this route. >>>> >>>> For GCC at least we need to drop the gfdl bits, and we may want to update >>>> to >>>> 4.8.5, but in general it seems to work well. I was hitting a build failure >>>> that >>>> I could workaround by using an interactive shell. No idea if it's a >>>> pbuilder >>>> problem or what. That would need a little investigation. >>>> >>>> For Firefox, I didn't look much at the PIE issue. I just saw that it fails >>>> on a >>>> simple configure test when enabled, at the linker stage. With pie disabled, >>>> everything went well. >>> >>> That sounds great. Did you put the packages somewhere? I don't think we'll >>> run into any extra issues with Icedove but it might be worth checking >>> this out before the current ESR versions go EOL. >> >> Packages are at https://people.debian.org/~pochu/lts/gcc/ >> >> gcc-mozilla is the one from [1], but putting it here for convenience (you >> can't >> dget from launchpad). Let me know if it works for you or if you have any >> issues. > > I checked with current icedove and it builds a well when disabling > PIE. So with your proposed changed (disabling gfdl, updating to the > latest 4.8 version) we should be good. Are you going to look into this? Yes, I'll take care of that. Cheers, Emilio
Re: libarchive12: ldconfig warns that libarchive.so.12 is not a symbolic link
Version: 3.0.4-3+wheezy4 On 19/09/16 17:58, Jonas Meurer wrote: > Hello Bruce, > > Am 19.09.2016 um 14:47 schrieb Bruce Toll: >> I reported a bug with the recent (Sept. 10) libarchive12 security update >> (Debian BTS 838243) and heard back from Andreas Henriksson that I should >> reach out to the package uploader and Debian LTS team directly. >> >> I appreciate the great work that you and the LTS team are doing to keep >> wheezy secure. The issue seems fairly minor and is described in the bug >> tracker, https://bugs.debian.org/838243. Thanks! > > Thanks for your bugreport. Indeed, it looks like, something went wrong > with the build of libarchive12 3.0.4-3+wheezy3 on amd64. For the other > supported archs, everything seems fine. > > I suspect that this is due to me building the amd64 binaries inside a > virtualbox VM with the build directory mounted as vboxsf share mount. > Apparently, symlinks get screwed up up on vboxsf mounts. > > Another LTS update of libarchive is underway anyway, Emilio Pozuelo > Monfort is working on it. I suggest to wait until his upload, which will > fix the bug (except if he builds on a vboxsf share as well) :) Heh, I didn't. Sorry for the delay, but this is finally fixed. I forgot to mention this in the new DLA. I don't think sending another announcement is needed, as this was only causing a warning, but things were still working fine. Let me know if that was not the case and we can send a regression announcement. Thanks, Emilio
September report
Hi, September was a bad month for me, and I only managed to spend 1h out of 12.30h, working on the libarchive update. I am returning the rest of the time to the pool so it can be allocated among the contributors next month. Sorry for that and for the delay in the report, I should be back to normal now. Cheers, Emilio
Re: testing libxml2 for Wheezy LTS
Hi Thorsten, On 23/10/16 20:04, Thorsten Alteholz wrote: > Hi everybody, > > I uploaded version 2.8.0+dfsg1-7+wheezy7 of libxml2 to: > > https://people.debian.org/~alteholz/packages/wheezy-lts/libxml2/amd64/ > > Please give it a try and tell me about any problems you met. It would be nice > to > also test cases where "range-to" is really needed. I did some very basic and quick testing, mostly just running a few GNOME apps that I know use libxml, and things worked fine. I didn't really look for anything that specifically uses range-to, so I don't know if that got used. Cheers, Emilio
Re: status of tzdata packages in wheezy
Hi Erdem, On 26/10/16 08:31, Erdem Bayer wrote: > Hello > > As explained in debian bug 838781, Turkey choosed to change its DST policy > and > will not be updating the time at the end of this month. IANA released two > updates about Turkey, 2016g and 2016h, these packages hit the stable repos > yerterday. > > As this update is very important for Turkish debian users, is it possible to > take the 2016h update to wheezy, or are tzdata packages unsupported by LTS? It's very important to keep tzdata updated, but we failed to do so the last few months. I am already looking at the updates (I have tzdata ready, still working on libtimedate-timezone-perl) and will upload them ASAP (hopefully later today). I will also keep an eye on them so we don't miss any updates in the future. Cheers, Emilio
Re: ghostscript and evince/libspectre problem
On 25/10/16 21:54, Salvatore Bonaccorso wrote: > Hi Roberto > > Could you double-check/confirm if you see the same > https://bugs.debian.org/840691 in wheezy? Note although the bug is > still assigned to ghostscript I think the problem uncovered is > actually in libspectre as noted in the bug log. But I wonder if you > see the same issues in wheezy now that ghostscript is updated there. There also is #842154, which I have merged with #840691. Testing in a wheezy VM, I also get that "invalidaccess -7" and PS documents aren't rendered. I can't get evince to crash, but that's probably irrelevant. Cheers, Emilio
Re: status of tzdata packages in wheezy
On 26/10/16 10:58, Emilio Pozuelo Monfort wrote: > Hi Erdem, > > On 26/10/16 08:31, Erdem Bayer wrote: >> Hello >> >> As explained in debian bug 838781, Turkey choosed to change its DST policy >> and >> will not be updating the time at the end of this month. IANA released two >> updates about Turkey, 2016g and 2016h, these packages hit the stable repos >> yerterday. >> >> As this update is very important for Turkish debian users, is it possible to >> take the 2016h update to wheezy, or are tzdata packages unsupported by LTS? > > It's very important to keep tzdata updated, but we failed to do so the last > few > months. I am already looking at the updates (I have tzdata ready, still > working > on libtimedate-timezone-perl) and will upload them ASAP (hopefully later > today). I uploaded those a few hours ago. Cheers, Emilio
LTS Report for October 2016
Hi, In this month I was allocated 13h, which I spent doing the following: - Finished the update I had started to libarchive - Tested libxml2 packages - Updated X11 packages (libx11, libxi, libxtst), fixing some regressions in the security patches: https://cgit.freedesktop.org/xorg/lib/libXi/commit/?id=7ac03c6c1907a39b5b42b17ad331295b8c85154d https://cgit.freedesktop.org/xorg/lib/libXi/commit/?id=4c5c8d6246debc06a56120cff71bfdf1877884d0 https://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=20a3f99eba5001925b8b313da3accb7900eb1927 - updated tzdata and libdatetime-timezone-perl for the 2016h update - did a quick check for the ghostscript regression Cheers, Emilio
Re: tre package ready for testing
Hi Antoine, On 26/10/16 19:43, Antoine Beaupré wrote: > Hi Santiago (and others), > > I have prepared a wheezy LTS security upload for tre here: > > https://people.debian.org/~anarcat/debian/wheezy-lts/ > > The debdiff is attached to this message. I have also sent the ported > patch to the following bug report: +tre (0.8.0-3+deb7u1) UNRELEASED; urgency=high + + * Non-maintainer upload by the Security Team. + * new patch to fix CVE-2016-8859 + + -- Antoine Beaupré Wed, 26 Oct 2016 13:04:31 -0400 Probably s/Security/LTS/. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842169 > > I am not sure how to perform tests against tre, unfortunately, so I am > not in a good position to test that package. I don't know if there is a test case for this overflow, but at the very least, you could do some basic testing on tre-agrep, which seems like a grep clone, and make sure the basics still work? Cheers, Emilio
Re: Qemu CVEs in Xen
On 29/11/16 10:18, Hugo Lefeuvre wrote: > Hi, > > So far, I have triaged ~120 CVEs. I have used all my assigned hours, so > I won't be able to finish the work this month. > > I have marked Xen as affected by 45 'new' CVEs until now. Not all of > them deserve a DLA. > > Here are the remaining ones: > > CVE-2009-3616 > CVE-2010-0297 > CVE-2010-0431 > CVE-2010-2784 > CVE-2011-0011 > CVE-2011-1750 > CVE-2011-1751 > CVE-2011-2212 > CVE-2011-2512 > CVE-2011-2527 > CVE-2011-3346 > CVE-2012-2652 > CVE-2013-4149 > CVE-2013-4150 > CVE-2013-4526 > CVE-2013-4527 > CVE-2013-4529 > CVE-2013-4530 > CVE-2013-4531 > CVE-2013-4534 > CVE-2013-4535 > CVE-2013-4536 > CVE-2013-4539 > CVE-2013-4540 > CVE-2013-4541 > CVE-2014-0142 > CVE-2014-0143 > CVE-2014-0144 > CVE-2014-0145 > CVE-2014-0147 > CVE-2014-0150 > CVE-2014-0182 > CVE-2014-3461 > CVE-2014-3615 > CVE-2014-3689 > CVE-2014-7840 > CVE-2014-9718 > CVE-2015-8556 > CVE-2015-4037 > > Feel free to have a look at them. > Issues before 2009 are not affecting Xen in wheezy: > > CVE-2007-1321 > CVE-2007-1322 > CVE-2007-1366 > CVE-2007-5729 > CVE-2007-5730 > CVE-2007-6227 > CVE-2008-1945 > CVE-2008-4539 > CVE-2008-4553 > CVE-2008-5714 > > Should I mark Xen as unaffected by these issues in the tracker or should > we just ignore them ? They are not marked as affecting wheezy anyway (actually they aren't marked as affecting xen at all). Because of that and because they are so old, I would just leave them as they are. If you mark them as affecting xen, you need to dig which version fixed them in Debian so they are not "opened" for sid/jessie. Cheers, Emilio
Re: Versioning of new releases in (old)stable (Was: nss security update package ready for review)
On 01/12/16 16:25, Jonas Meurer wrote: > Hi Security and LTS folks, > > Am 01.12.2016 um 15:54 schrieb Salvatore Bonaccorso: >> On Wed, Nov 30, 2016 at 04:05:20PM -0500, Antoine Beaupré wrote: >>> +nss (2:3.26.2-1+debu7u1) UNRELEASED; urgency=high >>> + >>> + * Non-maintainer upload by the LTS Security Team. >>> + * New upstream release to fix CVE-2016-9074 >> >> Depending on what is done this should be either 2:3.26.2-0+debu7u1 or >> 2:3.26.2-1~debu7u1, but 2:3.26.2-1+debu7u1 is higher than 2:3.26.2-1. >> >> The former if you import new orig source on top of the previous >> packaging to indicate the new import and have a version which is >> before any possible such ones uploaded to unstable (which is even true >> in this case because 2:3.26.2-1 is currently in unstable). The later >> is often prefered if the package is mostly are build of :3.26.2-1 for >> Wheezy. (The later proposed version works obviously as well in the >> case of just a new upstream import, but Release team has often as well >> done that distinction for the ~debXuY suffix). > > With this topic being discussed again and again recently, I suggest that > we should agree on a defined standard regarding the versioning of new > upstream releases uploaded to (old)?stable(-security)? and document it > somewhere. What do you think? > > I don't have particular strong feelings on the exact versioning but I > think that the following should be considered: > > *) New upstream releases in (old)?stable should use lover version >numbers than their equivalent uploaded to unstable. This because >packages uploaded to unstable are built using more recent versions >of the build toolchain and libraries. Moreover, New upstream releases should use lower versions than the next suite. That means oldstable < stable < testing < sid. Not just oldstable < sid and stable < sid, as you worded it. That's why 2:3.26.2-1+debu7u1 would be bad even if unstable had 2:3.26.3-1 by now, if stable had 2:3.26.2-1~debu8u1. When doing an update in oldstable, we need to see if it has happened or is happening in stable to avoid having a higher version in oldstable. > *) The versioning should make it obvious whether the new release is >based on a similar upload to unstable or whether it's packaged >solely for (old)?stable. > > Consequently, the following (as already done for most uploads of new > releases to (old)?stable) is my suggestion: > > *) Uploads of new upstream releases to (old)?stable that were packaged >for unstable before should use the '~debXu1' suffix to the version >number from unstable as they're basically backports of the package >from unstable. > *) Uploads of new upstream releases that were not packaged for unstable >yet or will never be, should use the '1.2.3-0+debXu1' format (given >that '1.2.3' is the upstream version. That's the current practice, yes. As Salvatore pointed out, that's also what the SRMs require for (old)stable uploads. > If we can agree on this, what would be the proper place to document it > for the future? Ideally, this should be mandatory for any uploads of new > upstream releases to the (old)?stable suites, be it to > (old)?stable-security, to stable-proposed-updates or to stable-updates. Probably the developers-reference, which already mentions the +debXuY syntax in various places (including the security updates section, 5.8.5.4 [1]), but doesn't mention ~debXuY for the case of backports. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security Cheers, Emilio
LTS Report for November 2016
Hi, In this month I was allocated 11h, which I spent doing the following: - DLA-700-1: libxslt: fixed heap overread bug - DLA-702-1: tzdata: updated for the 2016i release - DLA-703-1: libdatetime-timezone-perl: updated for the 2016i release - DLA-704-1: openjdk-7: backported version in experimental to fix several vulnerabilities - DLA-712-1: gst-plugins-bad0.10: removed unsafe NSF plugin; fixed exploit in vmnc decoder - DLA-725-1: tzdata: updated for the 2016j release - DLA-726-1: libdatetime-timezone-perl: updated for the 2016j release - DLA-727-1: gst-plugins-good0.10: started to backport upstream patches to fix the flic/flx plugin, but the upstream patches basically rewrite the code using some newer APIs from GStreamer 1.0 not available in GStreamer 0.10. In the end and after talking to an upstream developer, I decided to remove the plugin as was done in DLA-712-1 and in the jessie update. - DLA-xxx-1: firefox-esr: started with the 45.5.0 update, and midway through it 45.5.1 was released, so released that instead. (Packages uploaded, will send a DLA later once they are built.) Cheers, Emilio
Re: Versioning of new releases in (old)stable (Was: nss security update package ready for review)
On 02/12/16 06:40, Salvatore Bonaccorso wrote: > Hi Emilio, Jonas, Antoine, > > Thanks for all feedback. > > On Thu, Dec 01, 2016 at 04:44:22PM +0100, Emilio Pozuelo Monfort wrote: >> On 01/12/16 16:25, Jonas Meurer wrote: >>> Hi Security and LTS folks, >>> >>> Am 01.12.2016 um 15:54 schrieb Salvatore Bonaccorso: >>>> On Wed, Nov 30, 2016 at 04:05:20PM -0500, Antoine Beaupré wrote: >>>>> +nss (2:3.26.2-1+debu7u1) UNRELEASED; urgency=high >>>>> + >>>>> + * Non-maintainer upload by the LTS Security Team. >>>>> + * New upstream release to fix CVE-2016-9074 >>>> >>>> Depending on what is done this should be either 2:3.26.2-0+debu7u1 or >>>> 2:3.26.2-1~debu7u1, but 2:3.26.2-1+debu7u1 is higher than 2:3.26.2-1. >>>> >>>> The former if you import new orig source on top of the previous >>>> packaging to indicate the new import and have a version which is >>>> before any possible such ones uploaded to unstable (which is even true >>>> in this case because 2:3.26.2-1 is currently in unstable). The later >>>> is often prefered if the package is mostly are build of :3.26.2-1 for >>>> Wheezy. (The later proposed version works obviously as well in the >>>> case of just a new upstream import, but Release team has often as well >>>> done that distinction for the ~debXuY suffix). >>> >>> With this topic being discussed again and again recently, I suggest that >>> we should agree on a defined standard regarding the versioning of new >>> upstream releases uploaded to (old)?stable(-security)? and document it >>> somewhere. What do you think? >>> >>> I don't have particular strong feelings on the exact versioning but I >>> think that the following should be considered: >>> >>> *) New upstream releases in (old)?stable should use lover version >>>numbers than their equivalent uploaded to unstable. This because >>>packages uploaded to unstable are built using more recent versions >>>of the build toolchain and libraries. >> >> Moreover, New upstream releases should use lower versions than the next >> suite. >> That means oldstable < stable < testing < sid. Not just oldstable < sid and >> stable < sid, as you worded it. >> >> That's why 2:3.26.2-1+debu7u1 would be bad even if unstable had 2:3.26.3-1 by >> now, if stable had 2:3.26.2-1~debu8u1. >> >> When doing an update in oldstable, we need to see if it has happened or is >> happening in stable to avoid having a higher version in oldstable. >> >>> *) The versioning should make it obvious whether the new release is >>>based on a similar upload to unstable or whether it's packaged >>>solely for (old)?stable. >>> >>> Consequently, the following (as already done for most uploads of new >>> releases to (old)?stable) is my suggestion: >>> >>> *) Uploads of new upstream releases to (old)?stable that were packaged >>>for unstable before should use the '~debXu1' suffix to the version >>>number from unstable as they're basically backports of the package >>>from unstable. >>> *) Uploads of new upstream releases that were not packaged for unstable >>>yet or will never be, should use the '1.2.3-0+debXu1' format (given >>>that '1.2.3' is the upstream version. >> >> That's the current practice, yes. As Salvatore pointed out, that's also what >> the >> SRMs require for (old)stable uploads. >> >>> If we can agree on this, what would be the proper place to document it >>> for the future? Ideally, this should be mandatory for any uploads of new >>> upstream releases to the (old)?stable suites, be it to >>> (old)?stable-security, to stable-proposed-updates or to stable-updates. >> >> Probably the developers-reference, which already mentions the +debXuY syntax >> in >> various places (including the security updates section, 5.8.5.4 [1]), but >> doesn't mention ~debXuY for the case of backports. > > Right it is spread around on various sections both for stable updates > and as well for security updates. Would it make sense to maybe add a > new section for handling versioning for (old)?stable(-securit)? > udpates, and then reference from both the security bug handling and > the stable-updates handling to it? Yes, I think that would make sense. > I do not have a wording right now for dev-ref, but I can look if I can > come up with something during the weekend (keep in mind though that it > will in any case need review, I'm not a native english speaker). Great! I'm not a native speaker either, but I'll happy to look at it. Maybe cc debian-release@ with the patch so the SRMs can look at it as well. Cheers, Emilio
Re: Wheezy update of imagemagick?
On 29/12/16 23:19, Ola Lundqvist wrote: > Hi again Emilio > > Sorry for the spam. A new CVE just arrived. I'll add back imagemagick > for you to check CVE-2016-10062 instead. Yes, that's right. Though there wasn't a complete fix as of yesterday (see Salvatore's comment in the upstream bug). https://github.com/ImageMagick/ImageMagick/issues/196 Cheers, Emilio
Re: Wheezy update of imagemagick?
On 28/12/16 23:08, Roberto C. Sánchez wrote: > Hi Ola, > > The issues CVE-2016-8677 and CVE-2016-9559 were fixed by Antione when he > uploaded that latest imagemagick update to LTS. However, the > announcement (DLA-756-1) did not list those issues among the issues that > were addressed by that update. I have already mentioned it to him a > couple of days ago via private email. Hmm, it seems to me that the CVE-2016-8677 fix is incomplete: Upstream fix: https://github.com/ImageMagick/ImageMagick/commit/6e48aa92ff4e6e95424300ecd52a9ea453c19c60 Our patch: https://anonscm.debian.org/cgit/collab-maint/debian-lts/imagemagick.git/tree/debian/patches/0127-CVE-2016-8677.patch?h=debian/8%256.7.7.10-5%2bdeb7u10 I have pushed a fix to the git repo, see: https://anonscm.debian.org/cgit/collab-maint/debian-lts/imagemagick.git/commit/?id=897f6693d7a98c93e813c0522effdbd69df4cd11 Does that look correct? Unfortunately there's no test case for this issue. How do you normally test imagemagick? Cheers, Emilio
LTS report for December
Hi, In this month I was allocated 13.5h. I spent 11h doing the following: - DLA-735-1: gst-plugins-base0.10 update - DLA-736-1: gst-plugins-bad0.10 update - DLA-743-1: firefox-esr update - DLA-750-1: game-music-emu update - DLA-685-2: libxi regression update - imagemagick: fixed a wrongly fixed security issue (in git, not uploaded yet) - gcc-mozilla (in NEW) Cheers, Emilio
Re: Fixing CVE-2017-5522 (stack buffer overflow) for mapserver in wheezy
On 19/01/17 08:14, Sebastiaan Couwenberg wrote: > On 01/18/2017 10:17 PM, Ola Lundqvist wrote: >> Yes they are ok for wheezy-security. Thank you for your support. > > I've updated the secure-testing repo for this issue and sent the DLA. I haven't seen the DLA. Did you gpg-sign it? If you sent it with Icedove/enigmail (which you seem to be using), you should make sure you use inline PGP signatures. PGP/MIME doesn't work well. Cheers, Emilio
Re: Accepted tcpdump 4.9.0-1~deb7u1 (amd64 source) into oldstable
On 30/01/17 22:19, Ola Lundqvist wrote: > Hi > > Will you send the DLA or do you want me to do that? Adding Romain to Cc. Cheers, Emilio > > // Ola > > On 30 January 2017 at 19:40, Romain Francoise wrote: > Format: 1.8 > Date: Sun, 29 Jan 2017 22:17:21 +0100 > Source: tcpdump > Binary: tcpdump > Architecture: amd64 source > Version: 4.9.0-1~deb7u1 > Distribution: wheezy-security > Urgency: high > Maintainer: Romain Francoise > Changed-By: Romain Francoise > Description: > tcpdump- command-line network traffic analyzer > Changes: > tcpdump (4.9.0-1~deb7u1) wheezy-security; urgency=high > . >* Backport to wheezy. >* Disable the pppoes_id test, and reset B-D on libpcap-dev to what it > was in wheezy. > Checksums-Sha1: > f9d5b9e50181e205fa1b713bf906cc9aaa311ddd 1952 tcpdump_4.9.0-1~deb7u1.dsc > c241ea71d658ea46edc1bb0a0867ab7cda59973a 12776 > tcpdump_4.9.0-1~deb7u1.debian.tar.xz > 90de03d602d41e824dd5073bffb510af74a5974c 484900 > tcpdump_4.9.0-1~deb7u1_amd64.deb > Checksums-Sha256: > f8d328894bf0e23c28d153a8ea10975579bdbc7ccb25e566d42fb8d071dec076 1952 > tcpdump_4.9.0-1~deb7u1.dsc > cfde49ea7cc7250571a76e1451cfe85d4adc80a86dbb1251720845b81f973253 12776 > tcpdump_4.9.0-1~deb7u1.debian.tar.xz > 11ec542ca49d79755637b41413205cb7158c01e4dd4f2bab9209b7aa439378f0 484900 > tcpdump_4.9.0-1~deb7u1_amd64.deb > Files: > 9e84eb9b5b63d542cd072b1c607706b8 1952 net optional tcpdump_4.9.0-1~deb7u1.dsc > ea4321a8ad585e590ee8f85db8c8dd9c 12776 net optional > tcpdump_4.9.0-1~deb7u1.debian.tar.xz > 1d2032e577c6aa2c9c6e375a04c4f1f5 484900 net optional > tcpdump_4.9.0-1~deb7u1_amd64.deb > >> > > >
Re: Accepted openjdk-7 7u121-2.6.8-1~deb7u1 (source all amd64) into oldstable
On 27/01/17 22:18, Ola Lundqvist wrote: > Hi Emilio > > I saw that you have uploaded a new openjdk-7 package. Were that > package supposed to fix the current issues reported for openjdk-7 or > was that corrections for earlier version? It doesn't fix the latest round of CVEs. > I'm asking because: > 1) I have not seen the DLA. It seems to have gone missing. afaics it's there: https://lists.debian.org/debian-lts-announce/2017/01/msg00037.html > 2) I would like to know whether I should (re-)add the openjdk-7 > package to dla-needed.txt or not. I did that. Still waiting for upstream to release the update. Cheers, Emilio
Re: Wheezy update of ikiwiki?
Hi Simon,
On 12/01/17 01:09, Simon McVittie wrote:
> On Wed, 11 Jan 2017 at 01:46:32 +, Simon McVittie wrote:
>> Subsequent manual testing of the fixes for all those revealed some tricky
>> issues in error recovery code paths which I fixed in 3.20170110. We'll
>> see whether that's the final version...
>
> While preparing the backport of this whole mess for jessie, I found
> another security issue which *is* serious (CVE-2017-0356, an authentication
> bypass).
>
>> I suspect the diff resulting from all this is going to be larger than the
>> rest of the differences between git.pm in wheezy and git.pm in sid, which
>> makes me very tempted to recommend backporting the entire git.pm from sid
>
> That is my recommendation, and is what went into jessie-security
> (a DSA should follow soon).
>
> Here is a rather large patch stack which pulls in all the fixes from
> jessie-security (including autopkgtest support and enough build-dependencies
> to run most of the tests at build-time), plus a couple of unrelated backports
> from jessie to get the tests to pass:
>
> git clone git://git.ikiwiki.info/ -b debian-wheezy
> http://source.ikiwiki.branchable.com/?p=source.git;a=shortlog;h=refs/heads/debian-wheezy
>
> It builds for wheezy in sbuild, and passes autopkgtests on a wheezy VM
> if you parachute in pkg-perl-autopkgtest_0.19_all.deb from jessie (sorry,
> making it work without that jessie package is a yak-shave too far). I
> have not installed it on an actual web server because I don't run
> oldstable anywhere, but there is a test for CVE-2017-0356, which passes.
>
> Alternatively, if you want to abandon the backport approach for this package,
> I expect that the jessie-security version (the debian-jessie branch in the
> same git repository) would work fine in wheezy.
>
> If you release an updated package for wheezy using git, please let me know
> where I can fetch the git commits (or I'll use git-import-dsc if necessary).
Thanks for preparing the update. I have given it some smoke testing and uploaded
it. My only change is attached as a git-format-patch patch.
Cheers,
Emilio
>From 84e9cf77f0d38ec4e380e696012e2a0e71559b2f Mon Sep 17 00:00:00 2001
From: Emilio Pozuelo Monfort
Date: Tue, 31 Jan 2017 21:30:01 +0100
Subject: [PATCH] Release to wheezy-security
---
debian/changelog | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 2d0134c49..1f4471a4d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,6 @@
-ikiwiki (3.20120629.2+deb7u2) UNRELEASED; urgency=medium
+ikiwiki (3.20120629.2+deb7u2) wheezy-security; urgency=medium
+ [ Simon McVittie ]
* Security: force CGI::FormBuilder->field to scalar context where
necessary, avoiding unintended function argument injection
analogous to CVE-2014-1572.
@@ -54,7 +55,10 @@ ikiwiki (3.20120629.2+deb7u2) UNRELEASED; urgency=medium
(patch from Lafayette Chamber Singers Webmaster, backported from
3.20140916)
- -- Simon McVittie Wed, 11 Jan 2017 15:22:38 +
+ [ Emilio Pozuelo Monfort ]
+ * Upload to wheezy-security.
+
+ -- Emilio Pozuelo Monfort Tue, 31 Jan 2017 19:00:50 +0100
ikiwiki (3.20120629.2+deb7u1) wheezy-security; urgency=medium
--
2.11.0
Re: graphicsmagick update
On 16/01/17 20:48, Antoine Beaupré wrote: > Hi, > > I've looked at updating the graphicsmagick (GM) update to fix the issues > outlined in a [recent discussion][1]. The fix to CVE-2016-5240.patch is > trivial. I can also confirm the current GM version in wheezy-security > segfaults with the POC. > > I've had difficulties fixing the pending CVE-2016-9830 in wheezy, > however. The patch depends on the fairly new heigth/width "magick > resource limit" management, which was introduced in [January > 2015][2]. The [patch][2] is rather intrusive and i don't think is a good > candidate for wheezy, especially because it probably breaks ABI > compatibility. Attached is my best shot at porting the patch for > CVE-2016-9830, which fails to comply, but may be useful for jessie or > others. > > So I don't see any choice but to mark that issue as no-dsa. The impact > of the patch is more of a DOS (memory exhaustion, from what I can tell) > than code execution, so I think it doesn't warrant major code changes. > > I have built a package for amd64 in the [usual location][3] and attached > the debdiff for the debu6 update. I confirm the patch here fixes > CVE-2016-5240 properly. > > I am not sure I should upload this directly now considering it's such a > small fix, but given that it crashes with the bad data, maybe it's worth > it? I'd say it makes sense to release a regression update. BTW I'm not sure about this change, which is not mentioned in your changelog entry: --- graphicsmagick-1.3.16/debian/rules 2016-09-20 23:52:26.0 +0200 +++ graphicsmagick-1.3.16/debian/rules 2017-01-16 19:22:54.0 +0100 @@ -36,7 +36,7 @@ CFLAGS = -Wall -g -fno-strict-aliasing LDFLAGS = -include /usr/share/hardening-includes/hardening.make +-include /usr/share/hardening-includes/hardening.make CFLAGS += $(HARDENING_CFLAGS) LDFLAGS += $(HARDENING_LDFLAGS) Cheers, Emilio
Re: [Secure-testing-commits] r48631 - in data: . CVE
Hi Balint, On 31/01/17 21:46, Balint Reczey wrote: > Log: > wavpack's issues don't affect wheezy > > The first part of the upstream patch is not needed since the > code is very different and not vulnerable. > The second part applies, but does not make any difference when > trying the exploits. Tested with valgrind on Wheezy. These issues were found with address sanitizer, so I don't think checking with valgrind is enough (it's not the same). May be worth checking with asan (it should be available in wheezy's llvm 3.1). Cheers, Emilio
openssl wheezy update
Hi Kurt,
I have prepared an update of openssl for wheezy based on 1.0.1t-1+deb8u6. I have
done some smoke testing on it and it seems fine, but I haven't been able to
verify the three fixes as I can't find exploits for them (there is mention of
one for CVE-2016-8610 in [1] but I can't find the actual file).
Do you have any suggestion for how to verify / test the update?
Do you want to upload this or should I take care of it?
Test packages at https://people.debian.org/~pochu/lts/openssl/ in case someone
can give them a try.
Thanks,
Emilio
[1] http://www.openwall.com/lists/oss-security/2016/10/24/3
diff -Nru openssl-1.0.1t/debian/changelog openssl-1.0.1t/debian/changelog
--- openssl-1.0.1t/debian/changelog 2016-09-25 11:19:14.0 +0200
+++ openssl-1.0.1t/debian/changelog 2017-01-31 22:04:44.0 +0100
@@ -1,3 +1,13 @@
+openssl (1.0.1t-1+deb7u2) wheezy-security; urgency=medium
+
+ * Non-maintainer upload by the LTS team.
+ * Backport changes from 1.0.1t-1+deb8u6:
+ * Fix CVE-2016-8610
+ * Fix CVE-2017-3731
+ * Fix CVE-2016-7056
+
+ -- Emilio Pozuelo Monfort Tue, 31 Jan 2017 22:04:44 +0100
+
openssl (1.0.1t-1+deb7u1) wheezy-security; urgency=medium
* New upstream version, based on the version in jessie.
diff -Nru openssl-1.0.1t/debian/patches/CVE-2016-7056.patch
openssl-1.0.1t/debian/patches/CVE-2016-7056.patch
--- openssl-1.0.1t/debian/patches/CVE-2016-7056.patch 1970-01-01
01:00:00.0 +0100
+++ openssl-1.0.1t/debian/patches/CVE-2016-7056.patch 2017-01-31
22:03:37.0 +0100
@@ -0,0 +1,12 @@
+--- a/crypto/ecdsa/ecs_ossl.c
b/crypto/ecdsa/ecs_ossl.c
+@@ -147,6 +147,8 @@ static int ecdsa_sign_setup(EC_KEY *eckey, BN_CTX *ctx_in,
BIGNUM **kinvp,
+ if (!BN_add(k, k, order))
+ goto err;
+
++BN_set_flags(k, BN_FLG_CONSTTIME);
++
+ /* compute r the x-coordinate of generator * k */
+ if (!EC_POINT_mul(group, tmp_point, k, NULL, NULL, ctx)) {
+ ECDSAerr(ECDSA_F_ECDSA_SIGN_SETUP, ERR_R_EC_LIB);
+
diff -Nru openssl-1.0.1t/debian/patches/CVE-2016-8610.patch
openssl-1.0.1t/debian/patches/CVE-2016-8610.patch
--- openssl-1.0.1t/debian/patches/CVE-2016-8610.patch 1970-01-01
01:00:00.0 +0100
+++ openssl-1.0.1t/debian/patches/CVE-2016-8610.patch 2017-01-31
22:03:37.0 +0100
@@ -0,0 +1,128 @@
+Subject: CVE-2016-8610
+
+This is a combination of commit 22646a075e75991b4e8f5d67171e45a6aead5b48 and
+f1185392189641014dca94f3fe7834bccb5f4c16
+
+index 7e3a7b480e..cb74d467bb 100644
+Index: openssl-1.0.1t/ssl/s3_pkt.c
+===
+--- openssl-1.0.1t.orig/ssl/s3_pkt.c
openssl-1.0.1t/ssl/s3_pkt.c
+@@ -1057,6 +1057,13 @@ int ssl3_read_bytes(SSL *s, int type, un
+ return (ret);
+ }
+
++/*
++ * Reset the count of consecutive warning alerts if we've got a non-empty
++ * record that isn't an alert.
++ */
++if (rr->type != SSL3_RT_ALERT && rr->length != 0)
++s->cert->alert_count = 0;
++
+ /* we now have a packet which can be read and processed */
+
+ if (s->s3->change_cipher_spec /* set when we receive ChangeCipherSpec,
+@@ -1271,6 +1278,14 @@ int ssl3_read_bytes(SSL *s, int type, un
+
+ if (alert_level == SSL3_AL_WARNING) {
+ s->s3->warn_alert = alert_descr;
++
++s->cert->alert_count++;
++if (s->cert->alert_count == MAX_WARN_ALERT_COUNT) {
++al = SSL_AD_UNEXPECTED_MESSAGE;
++SSLerr(SSL_F_SSL3_READ_BYTES, SSL_R_TOO_MANY_WARN_ALERTS);
++goto f_err;
++}
++
+ if (alert_descr == SSL_AD_CLOSE_NOTIFY) {
+ s->shutdown |= SSL_RECEIVED_SHUTDOWN;
+ return (0);
+@@ -1406,16 +1421,13 @@ int ssl3_read_bytes(SSL *s, int type, un
+
+ switch (rr->type) {
+ default:
+-#ifndef OPENSSL_NO_TLS
+ /*
+- * TLS up to v1.1 just ignores unknown message types: TLS v1.2 give
+- * an unexpected message alert.
++ * TLS 1.0 and 1.1 say you SHOULD ignore unrecognised record types,
but
++ * TLS 1.2 says you MUST send an unexpected message alert. We use the
++ * TLS 1.2 behaviour for all protocol versions to prevent issues where
++ * no progress is being made and the peer continually sends
unrecognised
++ * record types, using up resources processing them.
+ */
+-if (s->version >= TLS1_VERSION && s->version <= TLS1_1_VERSION) {
+-rr->length = 0;
+-goto start;
+-}
+-#endif
+ al = SSL_AD_UNEXPECTED_MESSAGE;
+ SSLerr(SSL_F_SSL3_READ_BYTES, SSL_R_UNEXPECTED_RECORD);
+ goto f_err;
+Index: openssl-1.0.1t/ssl/d1_pkt.c
+===
+--- openssl-1.0.1t.orig/ssl/d1_pkt.c
openssl
LTS report for January
Hi, This month I was allocated 12.75h (plus 2.5h carried from last month). I spent this time doing the following: - DLA 684-2: libx11 regression update - DLA 784-1: gcc-mozilla new package - DLA 800-1: firefox-esr security update - DLA 801-1: libxpm security update - DLA 802-1: openjdk-7 security update - DLA 803-1: lcms2 security update - DLA 811-1: libplist security update - DLA 812-1: ikiwiki security update - prepared and tested openssl update - reviewed pending graphicsmagick update Cheers, Emilio
Re: [Secure-testing-commits] r48631 - in data: . CVE
On 01/02/17 00:42, Bálint Réczey wrote: > Hi Emilio, > > 2017-01-31 22:23 GMT+01:00 Bálint Réczey : >> Hi Emilio, >> >> 2017-01-31 22:14 GMT+01:00 Emilio Pozuelo Monfort : >>> Hi Balint, >>> >>> On 31/01/17 21:46, Balint Reczey wrote: >>>> Log: >>>> wavpack's issues don't affect wheezy >>>> >>>> The first part of the upstream patch is not needed since the >>>> code is very different and not vulnerable. >>>> The second part applies, but does not make any difference when >>>> trying the exploits. Tested with valgrind on Wheezy. >>> >>> These issues were found with address sanitizer, so I don't think checking >>> with >>> valgrind is enough (it's not the same). >>> >>> May be worth checking with asan (it should be available in wheezy's llvm >>> 3.1). >> >> I was able to reproduce the heap issues on sid with valgrind but i >> give llvm a try, too. > > Llvm 3.1 supports ASAN, but I could not find clang in the llvm-3.1 packages. > What am I missing? :-) Ah, looks like in wheezy clang was in its own source, and stayed at 3.0: https://packages.debian.org/source/wheezy/clang So I guess we're out of luck. Cheers, Emilio
Re: openssl wheezy update
On 01/02/17 00:29, Kurt Roeckx wrote: > On Tue, Jan 31, 2017 at 11:13:55PM +0100, Emilio Pozuelo Monfort wrote: >> Hi Kurt, >> >> I have prepared an update of openssl for wheezy based on 1.0.1t-1+deb8u6. I >> have >> done some smoke testing on it and it seems fine, but I haven't been able to >> verify the three fixes as I can't find exploits for them (there is mention of >> one for CVE-2016-8610 in [1] but I can't find the actual file). >> >> Do you have any suggestion for how to verify / test the update? >> >> Do you want to upload this or should I take care of it? > > Feel free to upload this. > > The usptream version in jessie and wheezy, so the patches should > just apply. > > I only have a test for the 32 bit crashes. It would require to get > the fuzzers working in the 1.0.1 version, which should be that > hard. > > The other would be a cache timing attack, and I really have no > good way to test that. > > I suggest you just upload it. Thanks, I have uploaded it. Cheers, Emilio
Re: Print undetermined issues in lts-cve-triage
On 03/02/17 10:58, Guido Günther wrote: > Hi, > while looking at the recent changes in data/CVE/list I noticed a bunch > of gstreamer issues being added but not showing up in the output > produced by lts-cve-triage. Reason was that they're marked as > undetermined. The attached patch adds undetermined issues to the output > by default. O.k. to apply? > > I'll start triaging the most recent ones but I'll likely won't be able > to clear the full backlog of 26 issues. As a pkg-gstreamer maintainer, I can take care of triaging (and fixing) the gstreamer vulnerabilities if you want. Cheers, Emilio
Re: Print undetermined issues in lts-cve-triage
On 03/02/17 16:37, Guido Günther wrote: > On Fri, Feb 03, 2017 at 12:25:19PM +0100, Emilio Pozuelo Monfort wrote: >> On 03/02/17 10:58, Guido Günther wrote: >>> Hi, >>> while looking at the recent changes in data/CVE/list I noticed a bunch >>> of gstreamer issues being added but not showing up in the output >>> produced by lts-cve-triage. Reason was that they're marked as >>> undetermined. The attached patch adds undetermined issues to the output >>> by default. O.k. to apply? >>> >>> I'll start triaging the most recent ones but I'll likely won't be able >>> to clear the full backlog of 26 issues. >> >> As a pkg-gstreamer maintainer, I can take care of triaging (and fixing) the >> gstreamer vulnerabilities if you want. > > That would certainly be very welcome (although the gstreamer ones are the > certainly the ones I'm less worried about). I have checked and triaged all the gstreamer ones. Looks like most of the remaining ones are on libav and linux. Cheers, Emilio
Re: postponing php5 issue
On 20/02/17 23:19, Antoine Beaupré wrote: > It seems a bit too much to do a DLA for a single issue in the php5 > package (CVE-2016-7478, namely): > > https://security-tracker.debian.org/tracker/source-package/php5 > > I looked at the issue and the patch is easily ported, but i suggest we > postpone this DLA until we have piled up more important > issues... > > I attached the backported patch for future reference. I'll update the > security tracker with details as well. You should commit that to https://anonscm.debian.org/cgit/collab-maint/debian-lts/php5.git/ > PS: has someone notified the maintainer before triaging this issue? i > didn't see a mail go through... AFAIK we handle php5 ourselves. Cheers, Emilio
Re: postponing php5 issue
On 22/02/17 20:48, Antoine Beaupré wrote: > On 2017-02-21 21:57:23, Emilio Pozuelo Monfort wrote: >> On 20/02/17 23:19, Antoine Beaupré wrote: >>> It seems a bit too much to do a DLA for a single issue in the php5 >>> package (CVE-2016-7478, namely): >>> >>> https://security-tracker.debian.org/tracker/source-package/php5 >>> >>> I looked at the issue and the patch is easily ported, but i suggest we >>> postpone this DLA until we have piled up more important >>> issues... >>> >>> I attached the backported patch for future reference. I'll update the >>> security tracker with details as well. >> >> You should commit that to >> >> https://anonscm.debian.org/cgit/collab-maint/debian-lts/php5.git/ > > done. i also added a tag that was missing. > >>> PS: has someone notified the maintainer before triaging this issue? i >>> didn't see a mail go through... >> >> AFAIK we handle php5 ourselves. > > hmm... is there a place where this is documented? how does frontdesk > know whether to ping maintainers or not? There is data/packages/lts-do-not-call, but php5 is not there... So no idea. Emilio
Re: nvidia-graphics-drivers 304.135 proposed packages for wheezy-lts
Hi Andreas, On 26/02/17 00:03, Andreas Beckmann wrote: > Hi, > > here comes the next round: > > On 2017-01-10 16:13, Andreas Beckmann wrote: >> I've prepared a new upstream release of the proprietary nvidia graphics >> driver for wheezy-lts. This will fix several security bugs: > >* New upstream legacy 304xx branch release 304.135 (2017-02-14). > * Fixed CVE-2017-0309, CVE-2017-0310, CVE-2017-0311, CVE-2017-0318, >CVE-2017-0321. (Closes: #855277) >> * New upstream legacy 304xx branch release 304.134 (2016-12-14). >> * Fixed CVE-2016-8826. (Closes: #848195) >> * New upstream legacy 304xx branch release 304.132 (2016-09-26). >> * Fixed CVE-2016-7382, CVE-2016-7389. (Closes: #846331) >> >> Proposed packages (amd64, i386) are available for testing at >> > https://people.debian.org/~anbe/304.135/ Thanks for preparing this. Unfortunately we can't upload this to wheezy-security as non-free is not supported there. Given proposed-updates are closed for wheezy, I think the only way for this would be through wheezy-backports. So, can you upload this update there? Note I haven't tested it, as I have no NVIDIA hardware. Thanks, Emilio
LTS report for February
Hi,
Last month I was allocated 13h. I spent 12.5h doing the following:
- openssl: released update
- libplist: some issues not reproducible, code changed a lot. gdb somehow can't
load symbols - gave it back
- ntfs-3g: prepared and released update for CVE-2017-0358
- openjdk-7: backported newer version from experimental for recent security
fixes
- gstreamer triaging: investigated which of the recent gstreamer CVEs affected
gstreamer 0.10.
- gst-plugins-{base,good,ugly,bad}0.10: prepared and released gstreamer updates
- libice/libxdmcp/xorg-server: investigated recent vulnerabilities, marked as
no-dsa.
- gdk-pixbuf: started to look at the recent vulnerabilities
Cheers,
Emilio
Re: Wheezy update of ca-certificates?
On 25/03/17 09:32, Paul Wise wrote: > Hi all, > > I note that there have been some CA removals and additions that would > be nice to have in wheezy, in particular the ISRG Root for LE, thoughts? I was just thinking about an update of ca-certificates on wheezy yesterday, but due to the removal of StartCom / WoSign. Which isn't fixed in sid yet (see #858539), so we may want to wait for that and then get an updated ca-certificates package out. Cheers, Emilio
Re: Bug#858973: wheezy-pu: package ejabberd/2.1.10-4+deb7u2
On 29/03/17 10:12, Philipp Huebner wrote:
> Package: release.debian.org
> Severity: normal
> Tags: wheezy
> User: release.debian@packages.debian.org
> Usertags: pu
>
> Hi,
>
> I'm not sure if another point update for Wheezy is planned or if this is
> a case for the LTS team, but I would like to update ejabberd in Wheezy.
wheezy-proposed-updates is closed, closing this bug (-done Bcc'ed) and adding
debian-lts@ to Cc.
Cheers,
Emilio
>
> There are 2 minor security patches:
> * disable SSLv3 (Closes: #767521)
> * enforce the starttls_required setting (CVE-2014-8760, closes: #767535)
>
> Please advise. Complete diff from git repository is attached.
>
> Best wishes,
> Philipp
>
diff --git a/debian/changelog b/debian/changelog
index 2869431..55ede73 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+ejabberd (2.1.10-4+deb7u2) oldstable; urgency=high
+
+ * Disable SSLv3 (Closes: #767521)
+ * Add patch to fix CVE-2014-8760 (Closes: #767535)
+
+ -- Philipp Huebner Wed, 29 Mar 2017 10:05:39 +0200
+
ejabberd (2.1.10-4+deb7u1) stable-security; urgency=low
[ Konstantin Khomoutov ]
diff --git a/debian/patches/CVE-2014-8760.patch b/debian/patches/CVE-2014-8760.patch
new file mode 100644
index 000..cd8c08b
--- /dev/null
+++ b/debian/patches/CVE-2014-8760.patch
@@ -0,0 +1,27 @@
+Description: Make sure "starttls_required" can't be bypassed.
+ Don't allow clients to circumvent the "starttls_required" option by
+ enabling XMPP stream compression. (CVE-2014-8760)
+Author: Holger Weiss
+
+Index: ejabberd/src/ejabberd_c2s.erl
+===
+--- ejabberd.orig/src/ejabberd_c2s.erl
ejabberd/src/ejabberd_c2s.erl
+@@ -614,7 +614,7 @@ wait_for_feature_request({xmlstreameleme
+ TLSRequired = StateData#state.tls_required,
+ SockMod = (StateData#state.sockmod):get_sockmod(StateData#state.socket),
+ case {xml:get_attr_s("xmlns", Attrs), Name} of
+- {?NS_SASL, "auth"} when not ((SockMod == gen_tcp) and TLSRequired) ->
++ {?NS_SASL, "auth"} when TLSEnabled or not TLSRequired ->
+ Mech = xml:get_attr_s("mechanism", Attrs),
+ ClientIn = jlib:decode_base64(xml:get_cdata(Els)),
+ case cyrsasl:server_start(StateData#state.sasl_state,
+@@ -720,7 +720,7 @@ wait_for_feature_request({xmlstreameleme
+ end;
+ _ ->
+ if
+- (SockMod == gen_tcp) and TLSRequired ->
++ TLSRequired and not TLSEnabled ->
+ Lang = StateData#state.lang,
+ send_element(StateData, ?POLICY_VIOLATION_ERR(
+ Lang,
diff --git a/debian/patches/disable-insecure-ssl-cyphers.patch b/debian/patches/disable-insecure-ssl-cyphers.patch
index 4ff049f..dc678c5 100644
--- a/debian/patches/disable-insecure-ssl-cyphers.patch
+++ b/debian/patches/disable-insecure-ssl-cyphers.patch
@@ -3,32 +3,37 @@ Description: Disable old and insecure cyphers in TLS driver
* Export ciphers - broken by design, 40 and 56 bit encryption.
* Low encryption ciphers - 56 and 64 bit encryption.
* SSLv2 ciphers - some ciphers using MD5 MAC.
+ * SSLv3 ciphers
.
This patch is a backport of changes introduced by the commit
d2d51381ec3fea97d0bd968cd7ffed2364b644c6 in the upstream Git repository
to the ejabberd code base as of version 2.1.12.
+ It was later extended to also disable SSLv3.
Author: Janusz Dziemidowicz
Forwarded: not-needed
-Last-Update: 2013-09-29
+Last-Update: 2017-03-29
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
a/src/tls/tls_drv.c
-+++ b/src/tls/tls_drv.c
+Index: ejabberd/src/tls/tls_drv.c
+===
+--- ejabberd.orig/src/tls/tls_drv.c
ejabberd/src/tls/tls_drv.c
@@ -44,6 +44,8 @@ typedef unsigned __int32 uint32_t;
#define SSL_OP_NO_TICKET 0
#endif
-+#define CIPHERS "DEFAULT:!EXPORT:!LOW:!SSLv2"
++#define CIPHERS "DEFAULT:!EXPORT:!LOW:!SSLv2:!SSLv3"
+
/*
* R15B changed several driver callbacks to use ErlDrvSizeT and
* ErlDrvSSizeT typedefs instead of int.
-@@ -356,6 +358,8 @@ static ErlDrvSSizeT tls_drv_control(ErlDrvData handle,
+@@ -355,6 +357,9 @@ static ErlDrvSSizeT tls_drv_control(ErlD
+ die_unless(res > 0, "SSL_CTX_check_private_key failed");
SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2|SSL_OP_NO_TICKET);
-
-+ SSL_CTX_set_cipher_list(ctx, CIPHERS);
++ SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv3|SSL_OP_NO_TICKET);
+
++ SSL_CTX_set_cipher_list(ctx, CIPHERS);
+
SSL_CTX_set_session_cache_mode(ctx, SSL_SESS_CACHE_OFF);
SSL_CTX_set_default_verify_paths(ctx);
- #ifdef SSL_MODE_RELEASE_BUFFERS
diff --git a/debian/patches/series b/debian/patches/series
index 297e201..30f0424 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -12,3 +12,4 @@ fix-odbc-escaping.patch
disable-ssl2.patch
disable-insecure-ssl-cyphers.patch
fix-nicks-in-plaintext-muc-log.patch
+CVE-2014-8760.patch
LTS report for March
Hi, Last month I was allocated 14.75h and carried over 0.5h from the previous month. I spent 11.75h doing the following: - libice/libxdmcp/xorg-server: investigated and ended up marking all the vulnerabilities as no-dsa. - tzdata/libdatetime-timezone-perl: updated to tzdata 2017a. - firefox-esr: updated to Firefox 45.8.0 ESR. I also looked at Firefox 52 ESR, as 45 is soon to be end of life, and investigated and fixed some build issues. Also tested the resulting package, which works fine. - gdk-pixbuf: marked the issues as no-dsa. - libvpx: backported one of the fixes. The other issue is harder to backport as part of the code has been rewritten. I'm considering marking these issues as no-dsa, but still investigating that. Cheers, Emilio
Mysql 5.5.55
Hi Lars, I see that you already started preparing MySQL 5.5.55 for wheezy in https://anonscm.debian.org/cgit/pkg-mysql/mysql-5.5.git/log/?h=debian/wheezy If you want I can upload the package and send the announcement. Just let me know when you're done with the update (at least I think the changelog needs to be updated). Cheers, Emilio
Re: Wheezy update of batik?
On 23/04/17 21:50, Ola Lundqvist wrote: > Dear maintainer(s), > > The Debian LTS team would like to fix the security issues which are > currently open in the Wheezy version of batik: > https://security-tracker.debian.org/tracker/CVE-2017-5662 FWIW I investigated this a bit and there doesn't seem to be any details other than what is in the advisory: i.e. I couldn't find the commit that fixes this (looking at the svn repository) or an upstream bug report. I found a security-related one, reported by Lars Krapf (as mentioned in the oss-security mail) but that seemed different than CVE-2017-5662 and much older (see [1]). Also our 1.8 and the upstream 1.9 tarballs have different layouts so it's hard to compare them. Cheers, Emilio [1] https://issues.apache.org/jira/browse/BATIK-1139
testing Mysql 5.5.55 for LTS
On 24/04/17 07:41, Lars Tangvald wrote: > Hi, > > The debian/wheezy branch should now be updated. Thanks Lars. Test packages for amd64 are available at https://people.debian.org/~pochu/lts/mysql/ I did some smoke testing, but we have to wait for the jessie update, so if someone wants to give this some more testing that'd be nice. Thanks, Emilio
Re: testing jasper for Wheezy LTS
On 23/04/17 13:16, Thorsten Alteholz wrote: > Hi everybody, > > I uploaded version 1.900.1-13+deb7u6 of jasper to: > > https://people.debian.org/~alteholz/packages/wheezy-lts/jasper/amd64/ > > Please give it a try and tell me about any problems you met. If you use jasper > for your own projects, I would be also interested whether you can still build > it > with that new version. Gave this a quick try with some jp2 files I found, using eog (uses jasper through gdk-pixbuf I think) and gimp (uses jasper directly), and all seems fine. I didn't try building anything that uses jasper, but that should be fine unless you changed the API, which I hope you didn't? Cheers, Emilio
Re: testing Mysql 5.5.55 for LTS
On 25/04/17 13:26, Ola Lundqvist wrote: > Hi > > Just for my understanding what is the reason for waiting for the jessie > uplozd? Not having a higher version in wheezy than in jessie. Emilio
LTS report for April
Hi, Last month I was allocated 16h and carried over 3.5h from the previous month. I spent 17.5h doing the following: - tzdata/libdatetime-timezone-perl: updated to 2017b. - libxslt: investigated issue, no-dsa. - firefox-esr: updated to 45.9.0esr - firefox-esr 52: sent patches to maintainers for wheezy support. - libvpx: continued work from previous month, ended up marking them no-dsa after discussing it with carnil - libreoffice: took over Balint/Rene's work, backported missing code and released update - chicken: released update - libcroco: released update - mysql-5.5: tested and sponsored updated package - batik: investigated issue, not much information at this point - briefly tested jasper update - rtmpdump: released update - freetype: released update - weechat: released update Cheers, Emilio
Re: Wheezy update of kde4libs?
Hi Maxy,
> > Would you like to take care of this yourself?
>
> Currently no, sorry. If you manage to work on this, please send me the
> diff or the format-patch queue so I can record the upload in our vcs.
I don't have a format-patch-formatted patch (:P), but please find attached the
debdiff that I have just uploaded.
Cheers,
Emilio
diff -Nru kde4libs-4.8.4/debian/changelog kde4libs-4.8.4/debian/changelog
--- kde4libs-4.8.4/debian/changelog 2016-07-25 15:13:22.0 +0200
+++ kde4libs-4.8.4/debian/changelog 2017-05-23 21:10:51.0 +0200
@@ -1,3 +1,15 @@
+kde4libs (4:4.8.4-4+deb7u3) wheezy-security; urgency=medium
+
+ * Non-maintainer upload by the LTS team.
+ * Sanitize URLs before passing them to FindProxyForURL (CVE-2017-6410)
+(Closes: #856890)
+ * Verify that whoever is calling us is actually who he says he is
+(CVE-2017-8422)
+ * Don't show passwords contained in HTTP URLs in error messages
+ (CVE-2013-2074)
+
+ -- Emilio Pozuelo Monfort Tue, 23 May 2017 21:10:51 +0200
+
kde4libs (4:4.8.4-4+deb7u2) wheezy-security; urgency=medium
* Add new patch: cve-2016-6232.patch
diff -Nru kde4libs-4.8.4/debian/files kde4libs-4.8.4/debian/files
--- kde4libs-4.8.4/debian/files 1970-01-01 01:00:00.0 +0100
+++ kde4libs-4.8.4/debian/files 2017-05-23 21:10:51.0 +0200
@@ -0,0 +1 @@
+kde4libs_4.8.4-4+deb7u3_source.buildinfo libs optional
diff -Nru kde4libs-4.8.4/debian/patches/CVE-2013-2074-part-1.patch
kde4libs-4.8.4/debian/patches/CVE-2013-2074-part-1.patch
--- kde4libs-4.8.4/debian/patches/CVE-2013-2074-part-1.patch1970-01-01
01:00:00.0 +0100
+++ kde4libs-4.8.4/debian/patches/CVE-2013-2074-part-1.patch2017-05-23
21:10:51.0 +0200
@@ -0,0 +1,38 @@
+From 65d736dab592bced4410ccfa4699de89f78c96ca Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Gr=C3=A9gory=20Oestreicher?=
+Date: Wed, 8 May 2013 23:16:00 +0200
+Subject: Don't show passwords contained in HTTP URLs in error messages BUG:
+ 319428
+
+---
+ kioslave/http/http.cpp | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/kioslave/http/http.cpp b/kioslave/http/http.cpp
+index 2d139a9..129fc7b 100644
+--- a/kioslave/http/http.cpp
b/kioslave/http/http.cpp
+@@ -3056,7 +3056,7 @@ try_again:
+ ; // Ignore error
+ } else {
+ if (!sendErrorPageNotification()) {
+-error(ERR_INTERNAL_SERVER, m_request.url.url());
++error(ERR_INTERNAL_SERVER, m_request.url.prettyUrl());
+ return false;
+ }
+ }
+@@ -3072,9 +3072,9 @@ try_again:
+ // Tell that we will only get an error page here.
+ if (!sendErrorPageNotification()) {
+ if (m_request.responseCode == 403)
+-error(ERR_ACCESS_DENIED, m_request.url.url());
++error(ERR_ACCESS_DENIED, m_request.url.prettyUrl());
+ else
+-error(ERR_DOES_NOT_EXIST, m_request.url.url());
++error(ERR_DOES_NOT_EXIST, m_request.url.prettyUrl());
+ return false;
+ }
+ } else if (m_request.responseCode >= 301 && m_request.responseCode<= 303)
{
+--
+cgit v0.11.2
+
diff -Nru kde4libs-4.8.4/debian/patches/CVE-2013-2074-part-2.patch
kde4libs-4.8.4/debian/patches/CVE-2013-2074-part-2.patch
--- kde4libs-4.8.4/debian/patches/CVE-2013-2074-part-2.patch1970-01-01
01:00:00.0 +0100
+++ kde4libs-4.8.4/debian/patches/CVE-2013-2074-part-2.patch2017-05-23
21:10:51.0 +0200
@@ -0,0 +1,36 @@
+From 898135a59d91184692ed1bcee8bb4c6d80d6f7b9 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Gr=C3=A9gory=20Oestreicher?=
+Date: Wed, 15 May 2013 21:56:29 +0200
+Subject: Continue hiding passwords in URLs displayed to the user The fix
+ introduced by 65d736da missed two usages of url() instead of prettyUrl().
+ Thanks to Kevin Kofler for spotting those. BUG: 319428
+
+---
+ kioslave/http/http.cpp | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/kioslave/http/http.cpp b/kioslave/http/http.cpp
+index 129fc7b..0c887bd 100644
+--- a/kioslave/http/http.cpp
b/kioslave/http/http.cpp
+@@ -1581,7 +1581,7 @@ QString HTTPProtocol::davError( int code /* = -1 */,
const QString &_url )
+
+ QString url = _url;
+ if ( !url.isNull() )
+-url = m_request.url.url();
++url = m_request.url.prettyUrl();
+
+ QString action, errorString;
+ int errorCode = ERR_SLAVE_DEFINED;
+@@ -3464,7 +3464,7 @@ endParsing:
+ KUrl u(m_request.url, locationStr);
+ if(!u.isValid())
+ {
+-error(ERR_MALFORMED_URL, u.url());
++error(ERR_MALFORMED_URL, u.prettyUrl());
+ return false;
+ }
+
+--
+cgit v0.11.2
+
diff -Nru kde4libs-4.8.4/debian/patches/CVE-2017-6410.diff
kde4libs-4.8.4/debian/patches/CVE-2017-6410.diff
--- kde4libs-4.8.4/debian/patches/CVE-2017-6410.diff1970-01-01
01
Re: Firefox ESR large text file rendering problem
On 08/05/17 09:05, Jari Ruusu wrote: > On 5/7/17, Marc SCHAEFER wrote: >> I cannot reproduce that problem on: >> >> $ cat /etc/debian_version >> 7.11 >> >> firefox 52.1.1-ESR, installed manually from >> http://ftp.mozilla.org/pub/firefox/releases/52.1.1esr/linux-x86_64/en-US/firefox-52.1.1esr.tar.bz2 > > I can confirm that the Mozilla pre-compiled version works OK. But the Debian > pre-compiled stable or LTS version (45.9.0-ESR) does fail when when those > "offmainthread" setting are default TRUE. Self compiled version fails too, > same as Debian pre-compiled version. > > The difference seem to be that Mozilla pre-compiled version embeds one more > shared library. This is the diff of "ls *.so" files between self compiled > and mozilla pre-compiled version: > > --- foo1.txt2017-05-08 09:56:45.0 +0300 > +++ foo2.txt2017-05-08 09:56:51.0 +0300 > @@ -2,6 +2,7 @@ > liblgpllibs.so > libmozavcodec.so > libmozavutil.so > +libmozgtk.so > libmozsandbox.so > libmozsqlite3.so > libnspr4.so > > The menus also look little bit different on mozilla pre-compiled version. The difference is that the mozilla binaries are built against GTK+ 3, whereas the Debian 45esr binaries are built against GTK+ 2. I don't know whether that in itself causes the bug that you reported. What about your 52 builds? Were those built against GTK+ 2 or 3? I am building 52.1esr on wheezy now [1], which will be built against GTK+ 3 when we upload it (45esr is now discontinued, so we'll upload 52esr with the next round of updates in about three weeks). I'll test it and see if that helps. Cheers, Emilio [1] I had a build around, but removed it on a quest to free some disk space.
Re: Firefox ESR large text file rendering problem
On 26/05/17 10:40, Jari Ruusu wrote: > This problem is now solved. > > The problem was that "offmainthread" rendering requires that SKIA [1] > graphics library must be compiled-in at compile time. > > In firefox-45-esr SKIA appears to be disabled by default, and requires > opt-in at compile time to enable it. "offmainthread" is enabled by default > (but can be disabled by about:config entries). By using all defaults, you > end up with incorrectly working Firefox binary. > > In firefox-52-esr SKIA appears to be enabled by default, and can be opt-out > at compile time to disable it. "offmainthread" is hard-coded-enabled. By > using all defaults, you end up with correctly working Firefox binary. > > My problem with firefox-52-esr builds was that I had these in my .mozconfig > > ac_add_options --disable-skia > ac_add_options --disable-skia-gpu > ac_add_options --disable-skia-pdf Indeed, my 52.1esr works fine. Cheers, Emilio
Re: Wheezy update of pngquant?
Hi Andreas, On 31/05/17 08:31, Andreas Tille wrote: > Hi Raphael, > > thanks for working on Debian LTS. > > On Thu, May 25, 2017 at 01:02:27PM +0200, Raphael Hertzog wrote: >> >> The Debian LTS team would like to fix the security issues which are >> currently open in the Wheezy version of pngquant: >> https://security-tracker.debian.org/tracker/CVE-2016-5735 >> >> Would you like to take care of this yourself? >> >> If yes, please follow the workflow we have defined here: >> https://wiki.debian.org/LTS/Development >> >> If that workflow is a burden to you, feel free to just prepare an >> updated source package and send it to debian-lts@lists.debian.org >> (via a debdiff, or with an URL pointing to the source package, >> or even with a pointer to your packaging repository), and the members >> of the LTS team will take care of the rest. Indicate clearly whether you >> have tested the updated package or not. > > I admit pngquant is a too unimportant package for me to schedule extra > time for this. > >> If you don't want to take care of this update, it's not a problem, we >> will do our best with your package. Just let us know whether you would >> like to review and/or test the updated package before it gets released. >> >> You can also opt-out from receiving future similar emails in your >> answer and then the LTS Team will take care of pngquant updates >> for the LTS releases. > > I do not want to opt-out in general but please do not expect any action > from my side for this specific package. No worries. I already updated pngquant in wheezy. I also found another possible buffer overflow and reported it upstream, but it's not confirmed yet (and I don't have a test case to confirm it). BTW if you can fix this in sid that'd be nice. Or if you're too busy I can fix it for you there. The fix is pretty simple: https://github.com/pornel/pngquant/commit/b7c217680cda02dddced245d237ebe8c383be285 Cheers, Emilio
Please test freeradius for wheezy LTS
Hi, I have prepared an update for freeradius. The changelog is: freeradius (2.1.12+dfsg-1.2+deb7u1) wheezy-security; urgency=medium * Non-maintainer upload by the LTS team. * CVE-2014-2015: Stack-based buffer overflow in the normify function in the rlm_pap module. CVE-2015-4680: Properly check revocation of intermediate CA certificates. For this to happen, the check_all_crl option of the EAP TLS section needs to be enabled in eap.conf. CVE-2017-9148: Disable TLS session cache, since it fails to prevent resumption of unauthenticated sessions, allowing remote attackers (such as malicious 802.1X supplicants) to bypass authentication via PEAP or TTLS without sending valid credentials. -- Emilio Pozuelo Monfort Wed, 31 May 2017 18:31:47 +0200 Packages are available for amd64 from [1]. Source and debdiff are also included. [1] https://people.debian.org/~pochu/lts/freeradius/ I have done some basic testing. Some extra testing in more advanced setups would be apreciated. Note that the fix for CVE-2015-4680 doesn't include the template changes to the conffile, to avoid unnecessary prompts and as not everyone needs to enable this option. This will be explained in the advisory. I will upload freeradius in the next few days if there is no feedback. Thanks, Emilio
Re: Wheezy update of pngquant?
Control: tags -1 patch
Hi Andreas,
On 31/05/17 22:13, Andreas Tille wrote:
> Hi Emilio,
>
> On Wed, May 31, 2017 at 09:42:37AM +0200, Emilio Pozuelo Monfort wrote:
>>
>> No worries. I already updated pngquant in wheezy.
>
> Cool. Thanks a lot.
>
>> I also found another possible
>> buffer overflow and reported it upstream, but it's not confirmed yet (and I
>> don't have a test case to confirm it).
>>
>> BTW if you can fix this in sid that'd be nice. Or if you're too busy I can
>> fix
>> it for you there. The fix is pretty simple:
>>
>> https://github.com/pornel/pngquant/commit/b7c217680cda02dddced245d237ebe8c383be285
>
> Hmmm, are you sure that this patch applies to version 2.5.0 from sid?
> The code looks pretty different. I do not mind at all if you do a NMU -
> if you provide a patch that applies cleanly I can promise quick upload.
That's because in 2.5.0 the (wrong) overflow check hadn't been added. That
upstream patch removes the wrong check and adds the correct one. Since 2.5.0
doesn't have the wrong one, we just need to add it. See the attached patch,
which builds and works fine in a quick test (didn't test against a crafted
image).
Cheers,
Emilio
--- rwpng.c.old 2017-05-31 22:36:13.329067904 +0200
+++ rwpng.c 2017-05-31 22:37:37.697664350 +0200
@@ -278,6 +278,12 @@ pngquant_error rwpng_read_image24_libpng
rowbytes = png_get_rowbytes(png_ptr, info_ptr);
+// For overflow safety reject images that won't fit in 32-bit
+if (rowbytes > INT_MAX/mainprog_ptr->height) {
+png_destroy_read_struct(&png_ptr, &info_ptr, NULL);
+return PNG_OUT_OF_MEMORY_ERROR; /* not quite true, but whatever */
+}
+
if ((mainprog_ptr->rgba_data = malloc(rowbytes*mainprog_ptr->height)) ==
NULL) {
fprintf(stderr, "pngquant readpng: unable to allocate image data\n");
png_destroy_read_struct(&png_ptr, &info_ptr, NULL);
LTS report for May
Hi, This month I was allocated 24h and carried over 2h from the previous month. I spent 23h doing the following: - freetype: released update - gnome-shell: triaged issue, no-dsa - firefox-esr 52: updated patches for firefox 52esr on wheezy, investigated issue with -fPIC. patches got merged - firefox-esr regression: investigation regression reported on debian-lts@. Next update to firefox 52 will fix it - openjdk-7: released update. the builds now takes - lrzip / lzip / lzo2: triaged issues - kde4libs: released update - potrace: triaged, no-dsa - rzip: released update - pngquant: released update. investigated another potential buffer overflow, reported upstream at https://github.com/pornel/pngquant/issues/250 - exiv2: released update - gajim: released update - freeradius: prepared and tested update. called for testing - libreoffice regression: reproduced regression reported with last update. Need to investigate further. Cheers, Emilio
Re: Wheezy update of perl?
On 05/06/17 00:33, Dominic Hargreaves wrote: > wheezy packages are now available from > git+ssh://git.debian.org/git/perl/perl.git (branch wheezy-security). > The patch is essentially identical to the jessie one (and of course > the test suite passes), so it should be fairly safe to upload. I'd > be grateful if someone else could take care of this as I won't have > much more time to work on this. Thanks for preparing the update! I can look at it later today if nobody beats me to it. Cheers, Emilio
Re: Wheezy update of perl?
On 05/06/17 09:53, Emilio Pozuelo Monfort wrote: > On 05/06/17 00:33, Dominic Hargreaves wrote: >> wheezy packages are now available from >> git+ssh://git.debian.org/git/perl/perl.git (branch wheezy-security). >> The patch is essentially identical to the jessie one (and of course >> the test suite passes), so it should be fairly safe to upload. I'd >> be grateful if someone else could take care of this as I won't have >> much more time to work on this. > > Thanks for preparing the update! I can look at it later today if nobody beats > me > to it. And done! Thanks again, Emilio
Re: Wheezy update of tomcat6 and tomcat7?
On 07/06/17 23:27, Ola Lundqvist wrote: > Hi > > Great! Should I mark this CVE as no-dsa or something else? Not no-dsa, but end-of-life (for wheezy). Cheers, Emilio
Re: network-manager: CVE-2016-0764
On 17/06/17 16:04, Michael Biebl wrote: > On Thu, 7 Apr 2016 19:43:36 +0200 Salvatore Bonaccorso > wrote: >> Source: network-manager >> Version: 0.9.4.0-10 >> Conrol: fixed -1 1.1.91-1 >> >> Hi, >> >> On Wed, Apr 06, 2016 at 11:25:58PM +0200, Michael Biebl wrote: >>> Hi Moritz, >>> >>> Am 06.04.2016 um 22:08 schrieb Moritz Muehlenhoff: Hi Michael, there's CVE-2016-0764 for network-manager: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=60b7ed3bdc3941a3b7c56824fba4b7291e79041f (1.2-beta2) It's also fixed in 1.0.12: https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/NEWS?h=1.0.12 This doesn't warrant a DSA, but you can fix it through a jessie point update. >>> >>> Could you turn this into a bug report please, otherwise I'll most >>> certainly forget. >> >> Forwarding this to the BTS. > > With stretch being released any moment now, this will have to be handled > as a debian-lts / oldstable upload. > > CCing the debian-lts mailing list, in case they want to make an upload > for this issue (it's not DSA tracked) jessie is not handled by the LTS team yet. Besides it's still open, you can do a jessie-pu upload. Cheers, Emilio
LTS report for June
Hi, In June I was allocated 16h and carried over 3h from the previous month. I spent 11h doing the following: - perl update - investigating chicken issue - freeradius update - ming update, investigating further ming issues - firefox-esr update - continued working on the libreoffice regression - some triaging I will catch up with the remaining hours this month. Cheers, Emilio
Re: Wheezy update of ncurses?
Hi, On 11/07/17 20:58, Sven Joachim wrote: > On 2017-07-11 10:17 -0400, Roberto C. Sánchez wrote: > >> On Sun, Jul 09, 2017 at 03:14:33PM +0100, Chris Lamb wrote: >>> The Debian LTS team would like to fix the security issues which are >>> currently open in the Wheezy version of ncurses: >>> https://security-tracker.debian.org/tracker/source-package/ncurses >>> >> >> All the open ncurses issues are marked no-dsa for jessie and stretch. >> Should we do the same for wheezy? > > That would be logical. The bugs only affect the tic program and the tic > library which is used by about three programs in the world (tic, infocmp > and tack), and most of our users never run any of these programs. > > Anyway, I have attempted to backport the patches I sent to the release > team (bugs #867814 and #867817). The changes to the library applied > cleanly, but I had to edit progs/dump_entry.c by hand since two hunks > failed to apply there. If anybody wants to upload a fixed package to > wheezy (I won't), please review carefully. Thanks. I have taken a look at this. I have noticed the regression you mentioned on the pu bugs, and so I have tried to backport the termcap-fix.diff. Unfortunately most hunks fail to apply, and applying it manually I noticed the code has changed quite a bit, and as I don't know the code well, I'm worried we may not fix the regression properly or we may cause other issues. I wanted to get this fixed as it will be fixed in stretch and jessie, and we don't have a wheezy-proposed-updates suite, and given the comments from the reporter about one bug leading to arbitrary code execution. But given the risk of not fixing this properly, the few users of the library, the disputed severity of that bug, and that this was tagged no-dsa in the first place, I'm tempted to do that for wheezy too and move on. Thoughts? Cheers, Emilio
Re: Wheezy update of ncurses?
On 22/07/17 09:41, Sven Joachim wrote: > On 2017-07-20 22:32 +0200, Emilio Pozuelo Monfort wrote: > >> On 11/07/17 20:58, Sven Joachim wrote: >>> On 2017-07-11 10:17 -0400, Roberto C. Sánchez wrote: >>> >>>> On Sun, Jul 09, 2017 at 03:14:33PM +0100, Chris Lamb wrote: >>>>> The Debian LTS team would like to fix the security issues which are >>>>> currently open in the Wheezy version of ncurses: >>>>> https://security-tracker.debian.org/tracker/source-package/ncurses >>>>> >>>> >>>> All the open ncurses issues are marked no-dsa for jessie and stretch. >>>> Should we do the same for wheezy? >>> >>> That would be logical. The bugs only affect the tic program and the tic >>> library which is used by about three programs in the world (tic, infocmp >>> and tack), and most of our users never run any of these programs. >>> >>> Anyway, I have attempted to backport the patches I sent to the release >>> team (bugs #867814 and #867817). The changes to the library applied >>> cleanly, but I had to edit progs/dump_entry.c by hand since two hunks >>> failed to apply there. If anybody wants to upload a fixed package to >>> wheezy (I won't), please review carefully. >> >> Thanks. I have taken a look at this. I have noticed the regression you >> mentioned >> on the pu bugs, and so I have tried to backport the termcap-fix.diff. >> Unfortunately most hunks fail to apply, and applying it manually I noticed >> the >> code has changed quite a bit, and as I don't know the code well, I'm worried >> we >> may not fix the regression properly or we may cause other issues. > > You are not the only one, I have struggled with this code myself for the > Jessie upload, in vain so far :-(. The problem is that the regression > fix relies on additions made in the 20161001 and 20161113 patchlevels, > and those are pretty large. > > My hope is that a fix might come from Opensuse whose users are already > suffering from the regression[1]. > >> I wanted to get this fixed as it will be fixed in stretch and jessie, and we >> don't have a wheezy-proposed-updates suite, and given the comments from the >> reporter about one bug leading to arbitrary code execution. > > Upstream mentioned that the stack protection would probably prevent such > an exploit[2], but I am not a security expert. Attackers would also > have to trick a victim into running an affected program on their input > files, not exactly the most profitable social engineering compared to > sending them (say) a crafted Word or PDF document. > >> But given the risk of not fixing this properly, the few users of the >> library, the disputed severity of that bug, and that this was tagged >> no-dsa in the first place, I'm tempted to do that for wheezy too and >> move on. > > Looks reasonable to me. Let's do that. I don't think these issues in this tool warrant the update, specially given the regressions. Cheers, Emilio
mysql 5.5.57
Hi Lars, I see that you prepared mysql 5.5.57 for wheezy. Thanks! I'll take care of uploading it (after doing some testing) and announcing it, as usual. Cheers, Emilio
LTS report for July
Hi, Last month I spent 18.5h doing the following: - fixed environment (syscall/vbox) - evince: released security update - ncurses: prepared update, manually backporting patches. In the end there were some issues and the risk of regressions was too high (there were regressions in the packages for jessie/stretch) and the issues are not severe enough, so decided to mark this as no-dsa - poppler: investigated issues, not severe enough so wanted to upload a fix to sid first - mysql-5.5: tested and released update - libraw: hand-backported patches for wheezy (and jessie on maintainer request), and tested them - investigated and triaged some other issues (openjdk, chicken, firefox-esr, cairo...) Cheers, Emilio
Re: Security support for chromium in jessie
On 31/07/17 05:23, Michael Gilbert wrote: > Hi all, > > I do not have enough free time to be able to keep up with security > updates to chromium in jessie (oldstable) any more. It is technically > feasible to keep it working in a jessie environment, but each update > has been more and more work. I expect that to continue. > > Anyway, if anyone would like to take this on (perhaps the LTS team?) > please do so. You would need to either be a DD or have a regular > sponsor for it to be practical. If that doesn't happen within about a > month, I'll announce that security support for chromium in jessie has > been discontinued. I think we should do this for as long as it's reasonably possible, given firefox updates will get harder and harder (they will require newer versions of rustc, which may need to be bootstrapped) so having another supported browser is a good idea. So I may looking at this. Cheers, Emilio
LTS report for August
Hi, Last month I spent 20.5 doing the following: - libsoup2.4: investigated issue, doesn't affect wheezy. pushed the fix to sid while at it - firefox-esr: updated to 52.3.0 ESR - openjdk-7: updated to 7u151 - libraw: finished update in coordination with maintainer who will take care of jessie/stretch - poppler: released update. handled update in sid while at it - triaging (liblouis, jbigkit, jbig2dec, exiv2, krb5...) - jbig2dec: investigated problem and forwarded upstream, investigated upstream's claim that this is already fixed in a previous CVE - gdk-pixbuf and libgd2: started looking at the issues Cheers, Emilio
Re: Wheezy update of emacs23?
On 19/09/17 22:11, Salvatore Bonaccorso wrote: > Hi > > On Sun, Sep 17, 2017 at 01:36:16AM -0500, Rob Browning wrote: >> Rob Browning writes: >> >>> Just attempted source-only upload to wheezy-security. >> >> Forgot -sa for the source. I'll reupload tomorrow. > > FTR, this was updated in meanwhile, but if I see it correctly a DLA > needs yet to be send out. I have just sent the DLA. Thanks, Emilio
Re: Patch for newsbeuter - CVE-2017-14500
On 21/09/17 07:08, Nikos Tsipinakis wrote: > Hi, > > I've prepared a patch fixing CVE-2017-14500[1] in the wheezy version of > newsbeuter. Can someone push it to security-master? Thanks for preparing the update Nikos. I'll take a look at it. Cheers, Emilio
Re: Patch for newsbeuter - CVE-2017-14500
On 21/09/17 21:56, Emilio Pozuelo Monfort wrote: > On 21/09/17 07:08, Nikos Tsipinakis wrote: >> Hi, >> >> I've prepared a patch fixing CVE-2017-14500[1] in the wheezy version of >> newsbeuter. Can someone push it to security-master? > > Thanks for preparing the update Nikos. I'll take a look at it. Package uploaded and announced. Thanks again! Emilio
Re: Wheezy update of mosquitto?
Hi, On 10/07/17 16:32, Gianfranco Costamagna wrote: > Hello Roger, > >> Here you go. Build and runtime tested. Thanks for working on this. Does this take care of updating the permissions when the file already exists? Doesn't seem to from my quick standalone test with a simple C program. Maybe this ought to call chmod as well for existing installations. > we should really patch also jessie, stretch and sid, right? Yep, that'd be good. Currently this vulnerability is marked as no-dsa for stretch and jessie, so the security team may prefer that you fix this via a point release update, but please check with them. No excuse for not fixing this in sid though. :) Cheers, Emilio
Re: Wheezy update of mosquitto?
On 23/09/17 18:52, Emilio Pozuelo Monfort wrote: > Hi, > > On 10/07/17 16:32, Gianfranco Costamagna wrote: >> Hello Roger, >> >>> Here you go. Build and runtime tested. > > Thanks for working on this. Does this take care of updating the permissions > when > the file already exists? Doesn't seem to from my quick standalone test with a > simple C program. Maybe this ought to call chmod as well for existing > installations. Oh, upstream seems to call unlink() first, so this will always create a new file and so the umask will be taken into account. So no need for a chmod call there afaics, sorry for the noise. Cheers, Emilio > >> we should really patch also jessie, stretch and sid, right? > > Yep, that'd be good. Currently this vulnerability is marked as no-dsa for > stretch and jessie, so the security team may prefer that you fix this via a > point release update, but please check with them. No excuse for not fixing > this > in sid though. :) > > Cheers, > Emilio >
Call for testing: db
Hi, I've prepared fixes for CVE-2017-10140 which affects src:db (5.1), src:db4.7 and src:db4.8 in wheezy. Of those, the most important one is src:db, which is the one with actual reverse dependencies. However the other two also ship the shared library in db4.[78]-util, so I'll also fix those to be safe. I'll wait a few days to give a chance to get more testing on this, maybe even wait for the (old)stable point releases which will ship updates to their respective db versions containing this fix, to see if any regressions get reported. Though if you have a chance to test these in wheezy (especially libdb5.1) then all the better. Thanks! Emilio
Re: Wheezy update of trafficserver?
On 22/09/17 17:42, Jean Baptiste Favre wrote: > Hi Moritz, > As far as I can remember, HTTP2 support has been introduced in 5.3.0 > (https://cwiki.apache.org/confluence/display/TS/What%27s+New+in+v5.3.x) > > So, I guess 3.0.5 in Wheezy is safe :) I have verified this and indeed 3.0.5 in wheezy doesn't have HTTP2 support. I marked this as not-affected in the security tracker. Thanks! Emilio
Re: for LTS
On 30/09/17 11:03, Moritz Muehlenhoff wrote: > Hi, > when we're marking issues as for the suites supported > by the security team and if that issue is also marked in wheezy > (or whatever is LTS at the time), ok to also mark the LTS suite as > or do you want to do deal with that by yourself? > > Specific example of such a change: r56270 That would be alright. We can always change things later if an update happens and the uploader decides to include a fix for such an issue. So feel free to change those for wheezy while handling the others if it's not too much trouble. Thanks! Emilio
Re: Call for testing: db
On 29/09/17 20:55, Guido Günther wrote: > Hi, > On Wed, Sep 27, 2017 at 06:48:07PM +0200, Emilio Pozuelo Monfort wrote: >> Hi, >> >> I've prepared fixes for CVE-2017-10140 which affects src:db (5.1), src:db4.7 >> and >> src:db4.8 in wheezy. Of those, the most important one is src:db, which is the >> one with actual reverse dependencies. However the other two also ship the >> shared >> library in db4.[78]-util, so I'll also fix those to be safe. >> >> I'll wait a few days to give a chance to get more testing on this, maybe even >> wait for the (old)stable point releases which will ship updates to their >> respective db versions containing this fix, to see if any regressions get >> reported. Though if you have a chance to test these in wheezy (especially >> libdb5.1) then all the better. > > I just wanted to give these a spin but didn't see any URLs to packages > or attached patches. Did I miss s.th.? Sorry, forgot to add the URL, and your reply went to the spam folder. Here they are: https://people.debian.org/~pochu/lts/db/ Thanks! Emilio
LTS report for September
Hi, Last month I spent 27h doing the following: - gdk-pixbuf update - libgd2 update - jbig2dec: upstream claimed that this was already fixed. Investigated the claim and verified that this was indeed fixed with a previous security update that was already in all supported releases - apache2 update for optionsbleed vulnerability - emacs23 update - newsbeuter: reviewed/sponsored update - fontforge: investigated issues, no-dsa - bzr update - cacti: investigated issue, confusing as the CVE looks like a duplicate of older ones, which we already fixed in the past. Marked as such - weechat: investigated issue and ways to trigger it, determined a DLA was warranted and prepared it - db: prepared updates for db, db4.7 and db4.8 and called for testing - ruby: discussed current issues and potential solutions with Antoine - firefox-esr security update for 52.4esr - investigated and triaged lots of packages (eglibc, trafficserver, libarchive, libsndfile, libmad, binutils, ocaml, ledger, mosquitto, mcollective...) Cheers, Emilio
Re: [debian-mysql] Bug#878402: Bug#878402: Security fixes from the October 2017 CPU
On 18/10/17 20:46, Salvatore Bonaccorso wrote: > Hi lars, > > On Wed, Oct 18, 2017 at 03:51:26PM +0200, Lars Tangvald wrote: >> Hi, >> >> 5.5.58 packages for Debian 7 and 8 are built, and pass the test suite. >> Attached are debdiff files for Wheezy and Jessie (source is also pushed to >> https://anonscm.debian.org/cgit/pkg-mysql/mysql-5.5.git) >> As before, we unfortunately don't have a DD in our team that can sponsor the >> upload, so we need assistance with that. > > I will look into it for jessie-security then. > >> I'm not sure if the security team still handles Debian8, or if the lts team >> does now? > > Yes, Debian 8 Jessie is still yet handled by the security team. And I will take of Debian 7 (wheezy). Thanks for preparing the update! Cheers, Emilio
Re: libclamunrar7 i386 only deb7u1
On 21/10/17 12:08, Matus UHLAR - fantomas wrote: > Hello, > > debsecan reports that there's security update available for libclamunrar. > However there's no newer version available for my system: > > libclamunrar7: > Installed: 0.99-0+deb7u1 > Candidate: 0.99-0+deb7u1 > Version table: > *** 0.99-0+deb7u1 0 > 500 file:/mount/mirrors/debian/ wheezy/non-free i386 Packages > 500 file:/mount/mirrors/debian/ wheezy-updates/non-free i386 Packages > 100 /var/lib/dpkg/status > > > Looking at it there's version 0.99-0+deb7u2 available, but only for amd64 > architecture, my system is i386: > https://packages.debian.org/wheezy/libclamunrar7 > > I haven't found any reason in bug reports or changelog mentioning that this > bug would not affect i386 arch. > > Maybe I did not search thoroughly enough? > > Or should I fill a bug report for this? Chris released this update with packages for amd64, but since this package is from non-free, it didn't get auto-built for other release architectures. To get other binaries, a manual binary-only upload needs to happen. We don't support non-free, but since this upload happened, maybe we should finish it and upload the rest of the binaries... FWIW the same issue happened with unrar-nonfree. Cheers, Emilio
Re: About libreoffice CVE
On 14/11/17 17:02, Moritz Mühlenhoff wrote: > On Tue, Nov 14, 2017 at 04:48:48PM +0100, Raphael Hertzog wrote: >> Package: libreoffice >> Claimed-By: Emilio Pozuelo >> Claimed-Date: 2017-05-31 17:29 (166 days ago) > > There's some data error, CVE-2017-12607 and CVE-2017-12608 were only > disclosed on Oct 27. Yes, that was added back then due to a regression with the fix for https://security-tracker.debian.org/tracker/CVE-2017-3157 The regression causes some objects (e.g. charts) to not be shown, which may be annoying for users but should be safe. Unfortunately, upstream didn't fix this in 3.5 and the code there was quite different, so I had to manually backport the patch. IIRC Rene reviewed at it and it seemed fine and my testing didn't show any problems, but upstream wasn't helpful so I went with it. Looks like Red Hat had the same or a similar regression, fwiw: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-3157 At this point, I'm not sure what the best course of action is: - revert the patch, leaving LO vulnerable to the original problem - leave things as is, with the annoying effect of the regression, but a safe LO - spend more time to try to fix the regression The first option is probably unacceptable. I wonder which one of the other two is better at this point, given that wheezy will be EOL in a few months and that most LTS users at this point are likely for servers. Thoughts? Emilio PS: My apologies for not dealing with this earlier. I looked at it a while ago but couldn't fix it, and then wasn't motivated to look at it further.
Re: About libreoffice CVE
On 16/11/17 09:39, Raphael Hertzog wrote: > On Tue, 14 Nov 2017, Emilio Pozuelo Monfort wrote: >> Yes, that was added back then due to a regression with the fix for >> https://security-tracker.debian.org/tracker/CVE-2017-3157 > > When you add an entry back for some reason, please document that > reason... this entry in dla-needed.txt is useless if contributors don't > know why it sits there. > > I was just assuming that it was affected by vulnerabilities and looked up > the open CVE. Well, it's there... libreoffice (Emilio Pozuelo) NOTE: regression update, see: NOTE: https://lists.debian.org/debian-lts/2017/05/msg00012.html > >> https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-3157 >> >> At this point, I'm not sure what the best course of action is: >> - revert the patch, leaving LO vulnerable to the original problem >> - leave things as is, with the annoying effect of the regression, but a safe >> LO >> - spend more time to try to fix the regression >> >> The first option is probably unacceptable. I wonder which one of the other >> two >> is better at this point, given that wheezy will be EOL in a few months and >> that >> most LTS users at this point are likely for servers. > > Can you point us to the regression report that you got or saw ? > > When I look at the description of the problem, I'm tempted to revert the > patch because the original problem does not look too severe. It can be > used to get private data but the information leak is limited to whatever > can appear in a preview and it requires precise knowledge of the > location of the user's document that you want to retrieve. And then > getting someone to open, modify, save a document and send it back to you > is non-trivial. > > Still this looks bad so it also depends on how annoying the regression is. > Does it affect all embedded objects ? Yep, it's bad, though not critical. The regression is annoying and affects some objects, but not sure if it affects all of them. >> PS: My apologies for not dealing with this earlier. I looked at it a while >> ago >> but couldn't fix it, and then wasn't motivated to look at it further. > > When I read "wasn't motivated to look at it further" I think that you > should have really put the package back into the queue with the > appropriate explanations. I really should have done that, and claimed it back if I found the time and energy. I have freed it now. Cheers, Emilio
LTS report for October
Hi, Last month I only managed to work 7h on LTS, which I spent doing the following: - db, db4.8, db4.7 security updates - mysql-5.5 security update - tzdata and libdatetime-timezone-perl updates - CVE triaging Cheers, Emilio
Call for testing: xserver
Hi, I prepared an update for the X server. The changelog is: xorg-server (2:1.12.4-6+deb7u8) wheezy-security; urgency=medium * Cherry-pick changes from the jessie branch: * render: Fix out of boundary heap access * xkb: Escape non-printable characters correctly. * xkb: Handle xkb formated string output safely (CVE-2017-13723) * os: Make sure big requests have sufficient length. * Unvalidated lengths in - XFree86-VidModeExtension (CVE-2017-12180) - XFree86-DRI (CVE-2017-12182) - XFIXES (CVE-2017-12183) - XINERAMA (CVE-2017-12184) - MIT-SCREEN-SAVER (CVE-2017-12185) - RENDER (CVE-2017-12187) * Xi: Silence some tautological warnings * Xi: fix wrong extra length check in ProcXIChangeHierarchy (CVE-2017-12178) * dbe: Unvalidated variable-length request in ProcDbeGetVisualInfo (CVE-2017-12177) * Unvalidated extra length in ProcEstablishConnection (CVE-2017-12176) * Use timingsafe_memcmp() to compare MIT-MAGIC-COOKIES (CVE-2017-2624) -- Emilio Pozuelo Monfort Sun, 19 Nov 2017 20:27:35 +0100 These changes have been on stretch and jessie for a bit, and they work fine for me. Still if you could give them a try, that'd be appreciated. https://people.debian.org/~pochu/lts/xorg-server/ Thanks, Emilio
