Re: Possible patch-backport problem for libphp-phpmailer (DLA-1591-1)
Hi Salvatore. > While preparing an update for libphp-phpmailer I noticed in the > patch/diff for DLA-1591-1 for libphp-phpmailer the following: Thanks for flagging. I will try and take a look at this over the next few days but I am pretty-solidly at a Reproducible Builds conference so if someone can jump in, please do so. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Possible patch-backport problem for libphp-phpmailer (DLA-1591-1)
Hi
While preparing an update for libphp-phpmailer I noticed in the
patch/diff for DLA-1591-1 for libphp-phpmailer the following:
+--- libphp-phpmailer-5.2.9+dfsg.orig/class.phpmailer.php
libphp-phpmailer-5.2.9+dfsg/class.phpmailer.php
+@@ -1022,10 +1022,12 @@ class PHPMailer
+
+ // Sign with DKIM if enabled
+ if (!empty($this->DKIM_domain)
+-&& !empty($this->DKIM_private)
+-&& !empty($this->DKIM_selector)
+-&& !empty($this->DKIM_domain)
+-&& file_exists($this->DKIM_private)) {
++and !empty($this->DKIM_selector)
++and (!empty($this->DKIM_private_string)
++or (!empty($this->DKIM_private)
++and self::isPermittedPath($this->DKIM_private)
++and file_exists($this->DKIM_private)
++))) {
+ $header_dkim = $this->DKIM_Add(
+ $this->MIMEHeader . $this->mailHeader,
+ $this->encodeHeader($this->secureHeader($this->Subject)),
The diff seem to add here just what was in the commit, and newly using
$this->DKIM_private_string . This is not used anywhere in the code in 5.2.9 as
it was added later, though.
That said, I have not followed the code further if it might raise a
real problem.
Regards,
Salvatore
LTS/ELTS Report for November 2018
For November I spent 13.75 hours on the following LTS tasks: - icu: triage CVE-2018-18928, vulnerable code was not present - libapache-mod-jk: prepared update for CVE-2018-11759 which involved backporting new upstream release; upload pending guidance from maintianers and security team on corresponding uploads for stable and unstable - symfony: multiple issues, backported patches to fix identified vulnerabilities; remaining task is to resolve build/unit test failures which likely depend on previous commits in history (i.e., identify those commits and add the necessary patches to the package) - php5: CVE-2018-19518, worked on reproducing I also spent 10 hours on the following ELTS tasks: - icu: triage CVE-2018-18928, vulnerable code was not present - libapache-mod-jk: prepared update for CVE-2018-11759 which involved backporting new upstream release; upload pending guidance from maintianers and security team on corresponding uploads for stable and unstable - nss: CVE-2018-12384, contacted Mozilla Security Team and they made upstream bug report public; began working on reproducing vulnerability - php5: CVE-2018-19518, worked on reproducing Regards, -Roberto -- Roberto C. Sánchez
Re: Addressing FreeRDP security issues in Debian jessie (and stretch)
On Mon, Dec 10, 2018 at 05:44:51PM +, Mike Gabriel wrote: > Hi, > > I'd like to discuss the possible pathways for getting FreeRDP fixed in > Debian jessie LTS (and Debian stretch, too). debian-security@ldo is not the proper contact address, I've fixed the recipient list. > Last week I talked to Bernhard Miklautz (one of the FreeRDP upsteam > maintainers and the actual packager of FreeRDPv2 in Debian). > > 1. Looking at fixing FreeRDP v1.1 in jessie / stretch > - > > He sketched up the following pathway for getting freerdp (v1.1) fixed in > Debian jessie (and stretch): What is the impact/scope of the individual issues? The individual commit messages are quite scarce. Are these exploitable by the server or a connecting client or vice versa? Cheers, Moritz
Addressing FreeRDP security issues in Debian jessie (and stretch)
Hi, I'd like to discuss the possible pathways for getting FreeRDP fixed in Debian jessie LTS (and Debian stretch, too). Last week I talked to Bernhard Miklautz (one of the FreeRDP upsteam maintainers and the actual packager of FreeRDPv2 in Debian). 1. Looking at fixing FreeRDP v1.1 in jessie / stretch - He sketched up the following pathway for getting freerdp (v1.1) fixed in Debian jessie (and stretch): * Backport https://github.com/FreeRDP/FreeRDP/pull/4499 -> required for FreeRDP in jessie/stretch to be able to connect to current RDP servers (not a security issue, but a functionality issue due to Microsoft updates rolled out during Q1 / 2018). -> estimated effort: 1-2h * CVE-2018-8785: not needed for jessie / stretch (code not present) * CVE-2018-8786, CVE-2018-8789: estimated hours for all three: 1-2h * CVE-2018-8787: estimated hours: 1-2h * CVE-2018-8788: can be become quite an effort, estimated time: 2h++ * CVE-2018-8784: not needed for jessie / stretch (code not present) While this sounds nice and feasible the underlying tone of investing so much work into FreeRDP v1.1 was a different one. E.g. the fix for CVE-2018-8789 should be quick and simple. But the surrounding code is buggy to a great extent, too. There have been so many stabilizing code fixes over the past 1-2 years. 2. Backporting FreeRDP v2 from buster to jessie and stretch Another approach, with a more stable and usable result is backporting FreeRDP v2 to jessie and stretch right away. Most people (I hope) are using freerdp2-x11 from stretch-backports (plus remmina from stretch-bpo) on Debian stable these days (freerdp 1.1 in stretch is broken with Windows RDP servers that are up-to-date with their patch levels). libfreerdp-client1.1 Reverse Depends: freerdp-x11 (>= 1.1.0~git20140921.1.440916e+dfsg1-4+deb8u1) Reverse Depends: libfreerdp-dbg (= 1.1.0~git20140921.1.440916e+dfsg1-4+deb8u1) Reverse Depends: libfreerdp-dev (= 1.1.0~git20140921.1.440916e+dfsg1-4+deb8u1) Reverse Depends: libguac-client-rdp0 (>= 0.8.3-1+b2) Reverse Depends: libxfreerdp-client1.1 (>= 1.1.0~git20140921.1.440916e+dfsg1-4+deb8u1) Reverse Depends: remmina-plugin-rdp (>= 1.1.1-2) Reverse Depends: vlc (>= 2.2.7-1~deb8u1) freerdp-x11 Reverse Depends: freerdp-x11-dbg (= 1.1.0~git20140921.1.440916e+dfsg1-4+deb8u1) Reverse Depends: ltsp-client (5.5.4-4) So the plan could be this: - rebuild freerdp (v1.1) as a shared libs package only, drop freerdp-x11 (which contains the command line tool) - backport freerdp2 from Debian unstable to jessie/stretch - backport remmina from Debian unstable to jessie/stretch - rebuild vlc in jessie (and possibly stretch, too) without RDP support - ltsp-client: adapt command line syntax to new FreeRDP2 cli style - libguac-client-rdp0: leave as is... Guacamole upstream still believes in FreeRDP v1.1 shared lib API... Summary --- Before going any deeper into this, I'd love to get some feedback from the LTS and the security team about the proposed strategies. Are there other possible pathways to go? If so, please share yours. The FreeRDP v1.1 backporting work (8-10 hours) would have to be outsourced to ThinCast in Austria (where most FreeRDP upstream devs work these days). Looking forward to your ideas and comments, Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby mobile: +49 (1520) 1976 148 landline: +49 (4354) 8390 139 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgp9LzgYB_zPq.pgp Description: Digitale PGP-Signatur
unclaiming packages and monthly reports
hi, I just ran the weekly "./bin/review-update-needed --lts --unclaim 1814400 --exclude linux linux-4.9" and no package was claimed for 3 weeks without work or documenting progress, very good. ( With lowering this to two weeks 4 packages would be unclaimed, but let's not go there yet. ) In related news, if you havent published your November reports, please do so *now*. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
