Re: nVidia drivers for kernel 3.2.96-3 (3.0.2-5)
On Mon, 2018-03-26 at 18:11 +0200, Camaleón wrote: > El 2018-03-26 a las 16:43 +0100, Ben Hutchings escribió: > > > On Mon, 2018-03-26 at 15:53 +0200, Camaleón wrote: > > > CC'ing also "debian-lts@lists.debian.org" > > > > > > Hello there, > > > > > > Any updates on this? > > > > > > http://lists.alioth.debian.org/pipermail/pkg-nvidia-devel/2018-Fe > > > bruary/015447.html > > > > That advice is still valid. > > Fine, thanks. > > Now the remaining question would be whether > "nvidia-kernel-3.2.0-5-amd64" package is expected to be available > any > soon or users not using DKMS are now promoted to start using it or > to > compile nvidia driver by themselves. > > Cheers! The binary kernel module will not be available, please use the DKMS packages. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: testing dovecot for Wheezy LTS
On 2018-03-26 22:40:38, Thorsten Alteholz wrote: > Hi everybody, > > I uploaded version 1:2.1.7-7+deb7u2 of dovecot to: > > https://people.debian.org/~alteholz/packages/wheezy-lts/dovecot/ > > It contains patches for CVE-2017-14461, CVE-2017-15130 and CVE-2017-15132. > > Please give it a try and tell me about any problems you met. I do not have a production Dovecot environment running wheezy anymore. I was able to reproduce CVE-2017-14461 in a Vagrant VM and can confirm that issue is fixed by your test packages. So consider this a working smoke test. For what it's worth, I have crafted this reproducer from the advisory: printf "From: attacker@nevermind\nSubject: test\nContent-Type: message/rfc822\n\nFrom: @(\nFrom: a(aa\n" | /usr/lib/dovecot/dovecot-lda -d vagrant Before, it crashes, now it delivers. Cheers! A. -- Nature hides her secret because of her essential loftiness, but not by means of ruse. - Albert Einstein
Re: [SECURITY] [DLA 1283-1] python-crypto security update
On 2018-03-27 07:38:43, Brian May wrote: > Antoine Beaupré writes: > >> I'm not sure. The security team marked that as "no-dsa (minor issue)" >> for jessie and stretch, and fixed in pycryptodome 3.4.11-1... Couldn't >> we reuse the fixes from cryptodome to get this working properly? Or is >> this what you say breaks API compatibility? > > I don't think I ever said anything about breaking API compatability. > > Rather the patch that was applied upstream was considered insufficient > (by the security researcher) to fix the problem. > > This is same patch I used for the LTS problem. > > Upstream was told about the problem: > https://github.com/Legrandin/pycryptodome/issues/90#issuecomment-362783537 > > "This indicates that, with your latest modification, ElGamal encryption > is now secure under the DDH assumption. However, this is not true. As I > mentioned in my previous comment, you must encode plaintexts as > quadratic residues, too (which is, I guess, what breaks compatibility)." > > ... but they didn't seem to care: > https://github.com/Legrandin/pycryptodome/issues/90#issuecomment-362907413 > > "Since the library itself does not support encryption officially, we > cannot make claim an implementation using the keys generated by the > library is secure or not." > > So it does look like fixing this properly might break API compatability, > but there are no known fixes we can apply. Hmm... so I guess the core question here is whether we expect our users to actually use cryptodome/pycrypto to do ElGamal-based encryption... I have the same problem trying to tackle the libgcrypt11 pending security issue: https://security-tracker.debian.org/tracker/CVE-2018-6829 My understanding of this issue is that it only affects consumers of the library that use ElGamal for encryption, a similar problem than what is described here. I was tempted to mark this as no-dsa, given how little elgamal is actually used in the wild. It was also my understanding that GnuPG wasn't vulnerable to this specific issue, but I haven't verified this deeply and it's been a while since I checked, so I am not exactly sure of that specific claim. CVE-2018-6594 is marked as no-dsa in Jessie/Stretch, for what that's worth... But the problem now is that we issued DLA-1283-1 to claim this was fixed, so at least an update on that should be provided to our users so we're clear this is *not* fixed. I'm not sure how to do that. Anyone else has suggestions here? A. -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan
Re: mercurial update ready for testing
I will upload the mercurial package as is (after checking the random_seed target stuff) tomorrow, unless someone tells me so. a. -- L'adversaire d'une vraie liberté est un désir excessif de sécurité. - Jean de la Fontaine
upload libvncserver
Hello.
I prepared LTS security update for libvncserver[1]. Please review and
upload. I have tested it with remmina-plugin-vnc.
[1]
https://mentors.debian.net/debian/pool/main/libv/libvncserver/libvncserver_0.9.9+dfsg-1+deb7u3.dsc
--abhijith
diff -Nru libvncserver-0.9.9+dfsg/debian/changelog
libvncserver-0.9.9+dfsg/debian/changelog
--- libvncserver-0.9.9+dfsg/debian/changelog2017-01-03 21:03:05.0
+0530
+++ libvncserver-0.9.9+dfsg/debian/changelog2018-03-29 22:55:20.0
+0530
@@ -1,3 +1,13 @@
+libvncserver (0.9.9+dfsg-1+deb7u3) wheezy-security; urgency=high
+
+ * Non-maintainer upload for the Debian LTS Team.
+ * CVE-2018-7225: rfbserver.c does not sanitize msg.cct.length, leading to
+access to uninitialized and potentially sensitive data or possibly
+unspecified other impact (e.g., an integer overflow) via specially crafted
+VNC packets (Closes: #894045)
+
+ -- Abhijith PA Thu, 29 Mar 2018 22:55:20 +0530
+
libvncserver (0.9.9+dfsg-1+deb7u2) wheezy-security; urgency=high
* CVE-2016-9941: Fix a heap-based buffer overflow that allows remote servers
diff -Nru libvncserver-0.9.9+dfsg/debian/patches/CVE-2018-7225.patch
libvncserver-0.9.9+dfsg/debian/patches/CVE-2018-7225.patch
--- libvncserver-0.9.9+dfsg/debian/patches/CVE-2018-7225.patch 1970-01-01
05:30:00.0 +0530
+++ libvncserver-0.9.9+dfsg/debian/patches/CVE-2018-7225.patch 2018-03-29
22:55:20.0 +0530
@@ -0,0 +1,48 @@
+Description: Fix CVE-2018-7225
+ rfbProcessClientNormalMessage() in rfbserver.c does not sanitize
msg.cct.length
+ , leading to access to uninitialized and potentially sensitive data or
possibly
+ unspecified other impact (e.g., an integer overflow) via specially crafted
VNC
+ packets.
+
+Author: Abhijith PA
+Bug-Debian: https://bugs.debian.org/894045
+Origin:
https://github.com/LibVNC/libvncserver/commit/b0c77391e6bd0a2305bbc9b37a2499af74ddd9ee
+Bug: https://github.com/LibVNC/libvncserver/issues/218
+Last-Update: 2018-03-29
+
+--- libvncserver-0.9.9+dfsg.orig/libvncserver/rfbserver.c
libvncserver-0.9.9+dfsg/libvncserver/rfbserver.c
+@@ -74,6 +74,8 @@
+ #include
+ /* strftime() */
+ #include
++/* PRIu32 */
++#include
+
+ #ifdef LIBVNCSERVER_WITH_WEBSOCKETS
+ #include "rfbssl.h"
+@@ -2487,7 +2489,23 @@ rfbProcessClientNormalMessage(rfbClientP
+
+ msg.cct.length = Swap32IfLE(msg.cct.length);
+
+- str = (char *)malloc(msg.cct.length);
++ /* uint32_t input is passed to malloc()'s size_t argument,
++ * to rfbReadExact()'s int argument, to rfbStatRecordMessageRcvd()'s int
++ * argument increased of sz_rfbClientCutTextMsg, and to setXCutText()'s
int
++ * argument. Here we impose a limit of 1 MB so that the value fits
++ * into all of the types to prevent from misinterpretation and thus
++ * from accessing uninitialized memory (CVE-2018-7225) and also to
++ * prevent from a denial-of-service by allocating to much memory in
++ * the server. */
++ if (msg.cct.length > 1<<20) {
++ rfbLog("rfbClientCutText: too big cut text length requested: %"
PRIu32 "\n",
++ msg.cct.length);
++ rfbCloseClient(cl);
++ return;
++ }
++
++ /* Allow zero-length client cut text. */
++ str = (char *)calloc(msg.cct.length ? msg.cct.length : 1, 1);
+ if (str == NULL) {
+ rfbLogPerror("rfbProcessClientNormalMessage: not enough
memory");
+ rfbCloseClient(cl);
diff -Nru libvncserver-0.9.9+dfsg/debian/patches/series
libvncserver-0.9.9+dfsg/debian/patches/series
--- libvncserver-0.9.9+dfsg/debian/patches/series 2017-01-03
21:08:12.0 +0530
+++ libvncserver-0.9.9+dfsg/debian/patches/series 2018-03-29
22:55:20.0 +0530
@@ -8,3 +8,4 @@
CVE-2015-6053.patch
CVE-2016-9942.patch
CVE-2016-9941.patch
+CVE-2018-7225.patch
Re: Bug#892590: Review graphite2
Drop rene@, jmm@, 892...@bugs.debian.org. On Tuesday 20 March 2018 01:47 AM, Moritz Mühlenhoff wrote: > On Mon, Mar 19, 2018 at 05:04:17PM +0100, Rene Engelhard wrote: >> I am not going over the .-release procedure for this, I'd have uploaded >> to security, though, but... >> >> I don't think we should special-case our oldest, >> soon-to-be-not-supported release. > > Agreed, it doesn't make sense to fix this bug on it's own. We can > simply piggyback it on the next more severe graphite update. > > Cheers, > Moritz > Anyway we have to upload this to wheezy-security. --
