Accepted libtirpc 0.2.5-1+deb8u2 (source amd64) into oldstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 31 Aug 2018 19:13:02 +0200 Source: libtirpc Binary: libtirpc-dev libtirpc1 Architecture: source amd64 Version: 0.2.5-1+deb8u2 Distribution: jessie-security Urgency: medium Maintainer: Anibal Monsalve Salazar Changed-By: Thorsten Alteholz Description: libtirpc-dev - transport-independent RPC library - development files libtirpc1 - transport-independent RPC library Changes: libtirpc (0.2.5-1+deb8u2) jessie-security; urgency=medium . * Non-maintainer upload by the LTS team. * CVE-2018-14622 Segmentation fault due to pointer becoming NULL. Checksums-Sha1: 24bd0be8944b046e564da53e8471c453f06b8eb7 2034 libtirpc_0.2.5-1+deb8u2.dsc 4bb728ecbab16ed510eb8deeedb58c24772cad96 367840 libtirpc_0.2.5.orig.tar.xz 381c3b60c760ee729b93489c96e9cfeb6d7b5eb8 15528 libtirpc_0.2.5-1+deb8u2.debian.tar.xz 25b9d518afa6823524f9e2c7eda1e6d98573271f 159452 libtirpc-dev_0.2.5-1+deb8u2_amd64.deb d9ce763127afac452f89bd48ca49255076895d53 80568 libtirpc1_0.2.5-1+deb8u2_amd64.deb Checksums-Sha256: 6313d770fb1abe2e6c26ad23501e8f8dea8b22963ae36400801a145a080fb540 2034 libtirpc_0.2.5-1+deb8u2.dsc 2cb03e95cb8c88c47b43e67c86ed83ff7ab991eb84d0a0102d2c3c982d68f44b 367840 libtirpc_0.2.5.orig.tar.xz ea246e07388ca798428a17bd1829fe1319f5064f9f746e2febe924adcc2c141f 15528 libtirpc_0.2.5-1+deb8u2.debian.tar.xz d1b4d30eb8e6a37e04a8c1a93d7e51cd2cf7ba4dd01d9b652b8c3882cd85ef43 159452 libtirpc-dev_0.2.5-1+deb8u2_amd64.deb 6cf8179911a3b740d4d9232b764bff31aef93d1a1f08b9499fffeee2047d5154 80568 libtirpc1_0.2.5-1+deb8u2_amd64.deb Files: 45051520f20c86be6532e4e1606bca71 2034 libs standard libtirpc_0.2.5-1+deb8u2.dsc 4995aa165a2d5a8b2bdbd2d696376c40 367840 libs standard libtirpc_0.2.5.orig.tar.xz 3e77dad74ac83f3d83e02e67ba5f6895 15528 libs standard libtirpc_0.2.5-1+deb8u2.debian.tar.xz c262bb155ee24800bec8f7eaf4b181eb 159452 libdevel extra libtirpc-dev_0.2.5-1+deb8u2_amd64.deb 49e0ae57b1c7d7157a8b7d489a03a405 80568 libs standard libtirpc1_0.2.5-1+deb8u2_amd64.deb -BEGIN PGP SIGNATURE- iQKnBAEBCgCRFiEEYgH7/9u94Hgi6ruWlvysDTh7WEcFAluJfQhfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDYy MDFGQkZGREJCREUwNzgyMkVBQkI5Njk2RkNBQzBEMzg3QjU4NDcTHGRlYmlhbkBh bHRlaG9sei5kZQAKCRCW/KwNOHtYR6p9EACXnMeg7xIuInmWRV1smB5FXSIHuxBa n4e+vUh91zHURzU/ouqHXqd7v7rSYuUI1Io8iuonAUbEVMg/J0L1O8Yv81HTBgOH m4YlwyonDHbPWjPdiDBXzwIDGxNFXQ+8w2xr2ICqxU+LfrOfVvmhQe80n2lTVXe0 Nftp7Ea1VkDBr/4Dx1WVKs5e59+MhPzO3pQK1XhtrUQ3zCC/CQCqM4cBygmOOZKj nTdP0GvvZBDiJD/ECBU9E4fON/kgaLnnPEvwZ9B2cEaMS5QUgr6dyJSv7eDN7VeR TwE5IZ3EzyE/aQy8fKoCBpEkUXC2OtIPubFtVgM+LQdtQY6uO7w8+P76M+qVkgxl u+m5BlW77Q3FHuN6ZmetFkklXLbmh4ocTm+EmLG6N/h5W88V7t3BNvpn7Vaaulz1 v9yyEdO/+OqnDbXEW8RpWdb+RbC1OaaZLhEeAKktN0JXIeYShYDsYN/n32X9uVSH GbNE7vz46joXZJQ2h6lfU8gwLpHMiZxtdvJrcBIlNqv04CcGmYESmL7JmjW5u4CQ YddoHIdTPp/FL2nL1e5PUjmxHPXcGf69AtZ9zlNERgzjAAFCKsTrrEumHXuUHdiC Ky6kIdiOektqL7JQSNU7JjgzqMI/B4OM8C2HztOB/iup1yVtHYEMLNsiNwR2Tuy5 6FNitzWisno8zQ== =QuqZ -END PGP SIGNATURE-
Re: Gnutls investigation and request for advice for Jessie
On 2018-08-31 16:18:39, Antoine Beaupré wrote: > On 2018-08-31 21:30:14, Ola Lundqvist wrote: >> Hi Antoine >> >> Thank you for the input this is valuable. I have some comments below. >> >> On Fri, 31 Aug 2018 at 21:03, Antoine Beaupré >> wrote: >>> >>> On 2018-08-31 13:29:29, Ola Lundqvist wrote: >>> > Hi all LTS contributors >>> > >>> > My question is whether removing default ciphers and introducing new >>> > options is acceptable so late in the release cyckle. My assumption is >>> > no, but let me know if you have another opinion. More details below. >>> >>> A priori, I think it is if it fixes serious security vulnerabilities and >>> there is no easier way to do so. >> >> I'm not so sure this is a serious issue as it is only exploitable in a >> rather uncommon case, that is when Encrypt-then-MAC (RFC7366) is >> unsupported by the peer. >> Most software do have that support as I understand it. > > That's the crucial part, I guess. :) I am not sure. The paper actually makes that claim which seems important: > The “Encrypt-then-MAC” countermeasure from RFC 7366 is supported in > mbed TLS and GnuTLS, but requires client-side support and has seen > little uptake elsewhere (e.g. neither Firefox nor Chrome supports the > EtM extension). In other words, EtM is not well supported in clients at all, and just forcing that mode does not seem to be a good strategy for mitigation. The paper does refer to a good source for TLS adoption numbers. https://notary.icsi.berkeley.edu/ With that as a source, it says that 10% of TLS traffic is still in CBC mode. The site does not load here so I cannot make further research, unfortunately. [...] > If you are unsure about updates, upload a test package somewhere and ask > people for feedback. I do it all the time and it actually works, if you > give people time (sometimes a week or more). For an update as critical, > it would certainly be warranted. Also, I would be happy to review patches and packages you propose, unless that wasn't clear already. :) >>> It seems that upstream did the right thing here and backported a bunch >>> of stuff for us already - it'd be too bad to waste that effort and skip >>> those CVEs. ;) >> >> :-D on the other hand maybe we break backwards compatibility. If it >> wasn't for the backwards compatibility I would not have asked. :-) > > Yeah, I guess I don't know what's in those updates exactly, that's a > good point. Another important point I found while (finally) reading the whole paper is that: > However, we believe that the GnuTLS code is still vulnerable to > variants of the attacks presented in our paper due to its > padding-dependent memory accesses. We notified the GnuTLS team of our > concerns about this on June 13th 2018. Our understanding is that the > GnuTLS team does not plan to address the issues, but prefers to > promote the use of Encrypt-then-MAC (as specified in RFC 7366) when > legacy cipher suites are required. Considering this and the lack of EtM support in the wild, I'm starting to seriously question the claims of the GnuTLS upstream. It does not seem like they really have fixed this at all, again, I should add. I'm sorry I am not bringing a more positive note here, but it does seem like things are a mess on GnuTLS' side. Maybe we should consider asking upstream for more information about their stance on the paper author's claims to get a clearer picture. Finally, the paper mentions that the Red Hat security team issued those CVEs, so they might have something up their sleeve as well, although a look at their Bugzilla does not yield anything conclusive. Good luck! A. -- If it's important for you, you'll find a way. If it's not, you'll find an excuse. - Unknown
Re: Gnutls investigation and request for advice for Jessie
On 2018-08-31 13:29:29, Ola Lundqvist wrote: > Hi all LTS contributors > > My question is whether removing default ciphers and introducing new > options is acceptable so late in the release cyckle. My assumption is > no, but let me know if you have another opinion. More details below. A priori, I think it is if it fixes serious security vulnerabilities and there is no easier way to do so. > If you have seen my email to ELTS then you may read faster. It is not > identical as the Jessie version is significantly easier to port than > the wheezy version. I'm not on the ELTS mailing list, so hopefully this email has all the information I need. :) > I think I need some advice. I have investigated the following issues for > gnutls. > CVE-2018-10844 > CVE-2018-10845 > CVE-2018-10846 > > I hope to spare you the time to read the full scientific paper on this matter. Did you actually read it? :) It's pretty interesting... > The overall problem is that by running some piece of software on the > same CPU as the gnutls software is running it is possible to decrypt > the plaintext by very smart techniques to deduce things from timing > differences. OpenSSL has fully addressed this by always taking exactly > the same time regardless of the input data but this was not properly > done for gnutls. Or rather, they took a "pseudo-constant time" approach, which the paper demonstrates as exploitable. > Upstream do in fact not even plan to do this as the problem only occur > in the following cases: > - CBC cipher > - If Encrypt-then-MAC (RFC7366) is unsupported by the peer > > Instead upstream have done the following: > 1) Introduced a new option to enforce Encrypt-then-MAC (for CVE-2018-10846) > 2) Do a fix with SHA384 (for CVE-2018-10845) > 3) Remove SHA256 and SHA384 from the default MAC ciphers (for > CVE-2018-10844 and CVE-2018-10845) > 4) A try to fix the problem (CVE-2018-10844 and potentially CVE-2018-10845) > > 1: I do not think we can do 1 such late in the release cycle. I mean > new options now would be rather pointless. I will mark CVE-2018-10846 > as ignored due to this. Or do you think new options is ok also in > Jessie? I looked at the upstream patch (MR#657) for this and it doesn't look that invasive. According to GitLab, it is "21 files with 738 additions and 148 deletions", which seems fairly small considering the scope of the change: https://gitlab.com/gnutls/gnutls/merge_requests/657.patch > 2: 2 is easy to do but as SHA384 is not part of the default ciphers I > see limited value. I do not think it is worth it on its own. Upstream issue says this "should addressed in [...] 3.3" which means they might have rolled out a patch for our precious jessie release on this: https://gitlab.com/gnutls/gnutls/issues/455 So I think it would make sense do backport that work - according to the security tracker, there's a minimal patch that might fix this in: https://gitlab.com/gnutls/gnutls/commit/cc14ec5ece856cb083d64e6a5a8657323da661cb But that is also part of the the larger fix in CVE-2018-10846 from what I understand, that is MR#657. > 3: Should we remove SHA256 and SHA384 from the default MAC ciphers? It > add some extra protection against this but it is a backwards > compatibility problem and therefore may not be good from an > availability perspective. I'm not sure how good it is to remove > ciphers such late in the release cycle either. SHA256 and SHA384 is > mostly deprecated now when AEAD cipher is available but still the peer > could be an old version (for example AEAD was not supported in > wheezy). This is an interesting question. On the one hand, it would be good to fix this, but on the other hand, one of the reasons people run LTS is exactly that kind of stuff. I am not sure it would be a good idea to completely remove a *protocol* from the supported list, unless we have a better idea of how frequently used it is. GnuTLS is a particularly sticky problem because it's not as widely used as OpenSSL, and it's not clear to me *where* exactly it's used. I know we used to link against it in the Charybdis IRCd, for example, but that caused all sorts of problems so I switched the Debian package to mbedtls in 3.5.5 and above, which means buster and later, which means stretch and jessie and before still all link to gnutls and would suffer from those issues. I would look at what upstream did for earlier releases here. > 4: Will do this and I do not think the backporting work is that > complicated. I will investigate a little more. It does look like there's a simpler fix that's usable for only fixing CVE-2018-10844, if the security tracker is accurate: https://gitlab.com/gnutls/gnutls/commit/c32a8690f9f9b05994078fe9d2e7a41b18da5b09 This, again, is also part of the larger fix in MR#657. Combined, those last two patches make about +- 50 lines of diff, compared to the 700+ lines of diff for the larger merge request. But do consider that a large part of MR#657 (+400 lines) is the introduction of
[SECURITY] [DLA 1487-1] libtirpc security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package: libtirpc Version: 0.2.5-1+deb8u2 CVE ID : CVE-2018-14622 CVE-2018-14622 Fix for egmentation fault due to pointer becoming NULL. For Debian 8 "Jessie", this problem has been fixed in version 0.2.5-1+deb8u2. We recommend that you upgrade your libtirpc packages. Further information about Debian LTS security advisories, how to apply these updates to your system and frequently asked questions can be found at: https://wiki.debian.org/LTS -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQJ8BAEBCgBmBQJbia96XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2MjAxRkJGRkRCQkRFMDc4MjJFQUJCOTY5 NkZDQUMwRDM4N0I1ODQ3AAoJEJb8rA04e1hHGh4QAK1+Ya9Rgm0/Q1rig+3HFwbU 6bOmDfsVQMPDkzu1An5YZr/PIfyQwbr8dhPpHnwef/3F7IJfcVsYQrjlpxrXv4GZ TSWoJqfRu2NXHFDwcORmA11fvuxnXHff5HW27XXJ1fcousIDG61NKyW4cJx5zS9c 1jEAq6uF9b+ad8DVyNsGl7SVRviqTkkTmbrm14blkirD2qk1cUB/DGsNCBrsBXTz 32ojQi0cdovz3Ymk+fjxQmvqbMa8WjY2UZtTUHi7cX6/PU+VfYhlOa5G6Fv5RWKj 8m1OKf0gWs3xHL5IzohEYLWe91sSnB9u9Zn/lOb1TbpvAX6iMMJ7UbnwKf7yB2wz 96qPQZGvL3nwDwXASqyuzmPa4gnMALr8hY6ayDk6joLKUifjsgpjytJJtbAL/24E 53G0dg2Kvn/dNzdKdU/FE5r287+wf4C1kcl1gsTg6jSRW8b4zQ+ylS81Np81T4aV v8Oh207b+naVoiw+yypUT4DvGH0XkOqXO8TLi5uz98DWRi8YSm2s2+OvGUG452p8 PDiIQTE3peTnGpGbDCYzmchY3gyFWORUelmBBS2PPMPOVKu6JwdvQMRGe4TXagQn w6Yh5TX3epenwSCywZsN6xnu7pET2WRm/UWow7O9cXvhD6Rlracz59dMimvLPdGx VrypMy3N1n0SNHCisMb7 =cV7N -END PGP SIGNATURE-
[SECURITY] [DLA 1488-1] spice security update
Package: spice Version: 0.12.5-1+deb8u6 CVE ID : CVE-2018-10873 Debian Bug : #906315 A vulnerability was discovered in SPICE before version 0.14.1 where the generated code used for demarshalling messages lacked sufficient bounds checks. A malicious client or server, after authentication, could send specially crafted messages to its peer which would result in a crash or, potentially, other impacts. The issue has been fixed by upstream by bailing out with an error if the pointer to the start of some message data is strictly greater than the pointer to the end of the message data. For Debian 8 "Jessie", this problem has been fixed in version 0.12.5-1+deb8u6. We recommend that you upgrade your spice packages. Further information about Debian LTS security advisories, how to apply these updates to your system and frequently asked questions can be found at: https://wiki.debian.org/LTS -- mike gabriel aka sunweaver (Debian Developer) fon: +49 (1520) 1976 148 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: sunwea...@debian.org, http://sunweavers.net signature.asc Description: PGP signature
Re: tiff / CVE-2018-15209
On 2018-08-29 12:24:30, Brian May wrote: > Antoine Beaupré writes: > >> Brian, are you sure you're getting those failures in jessie? Which >> architecture? Here my tests were done in a VirtualBox VM using an up to >> date Debian jessie amd64 box. > > My tests were done in a schroot. Not sure if I used i386 or amd64 now. Well, as I can't reproduce any issue at all with this, I've left it as N/A for jessie. A. -- Secrecy is the keystone to all tyranny. Not force, but secrecy and censorship. - Robert A. Heinlein
Re: Gnutls investigation and request for advice for Jessie
Hi Antoine Thank you for the input this is valuable. I have some comments below. On Fri, 31 Aug 2018 at 21:03, Antoine Beaupré wrote: > > On 2018-08-31 13:29:29, Ola Lundqvist wrote: > > Hi all LTS contributors > > > > My question is whether removing default ciphers and introducing new > > options is acceptable so late in the release cyckle. My assumption is > > no, but let me know if you have another opinion. More details below. > > A priori, I think it is if it fixes serious security vulnerabilities and > there is no easier way to do so. I'm not so sure this is a serious issue as it is only exploitable in a rather uncommon case, that is when Encrypt-then-MAC (RFC7366) is unsupported by the peer. Most software do have that support as I understand it. More on this below. > > If you have seen my email to ELTS then you may read faster. It is not > > identical as the Jessie version is significantly easier to port than > > the wheezy version. > > I'm not on the ELTS mailing list, so hopefully this email has all the > information I need. :) It should. I copied that email and adjusted it to suite Jessie. > > I think I need some advice. I have investigated the following issues for > > gnutls. > > CVE-2018-10844 > > CVE-2018-10845 > > CVE-2018-10846 > > > > I hope to spare you the time to read the full scientific paper on this > > matter. > > Did you actually read it? :) It's pretty interesting... Yes and it was really interesting. I must say that I'm impressed with what they have achieved. It must have been a rather comprehensive analysis. > > The overall problem is that by running some piece of software on the > > same CPU as the gnutls software is running it is possible to decrypt > > the plaintext by very smart techniques to deduce things from timing > > differences. OpenSSL has fully addressed this by always taking exactly > > the same time regardless of the input data but this was not properly > > done for gnutls. > > Or rather, they took a "pseudo-constant time" approach, which the paper > demonstrates as exploitable. Precisely, the "pseudo-constant time" was not the proper solution. In fact OpenSSL had its problem in the beginning as well as I understood from the paper. > > Upstream do in fact not even plan to do this as the problem only occur > > in the following cases: > > - CBC cipher > > - If Encrypt-then-MAC (RFC7366) is unsupported by the peer > > > > Instead upstream have done the following: > > 1) Introduced a new option to enforce Encrypt-then-MAC (for CVE-2018-10846) > > 2) Do a fix with SHA384 (for CVE-2018-10845) > > 3) Remove SHA256 and SHA384 from the default MAC ciphers (for > > CVE-2018-10844 and CVE-2018-10845) > > 4) A try to fix the problem (CVE-2018-10844 and potentially CVE-2018-10845) > > > > 1: I do not think we can do 1 such late in the release cycle. I mean > > new options now would be rather pointless. I will mark CVE-2018-10846 > > as ignored due to this. Or do you think new options is ok also in > > Jessie? > > I looked at the upstream patch (MR#657) for this and it doesn't look > that invasive. According to GitLab, it is "21 files with 738 additions > and 148 deletions", which seems fairly small considering the scope of > the change: > > https://gitlab.com/gnutls/gnutls/merge_requests/657.patch I agree on that. But introducing an option will not help in most cases that use gnutls. I mean gnutls is used in most cases as a library and unless the other software is changed then there is no use of introducing the option. 657 includes 1, 2, 3, and 4 described in this email and some other minor things too. > > 2: 2 is easy to do but as SHA384 is not part of the default ciphers I > > see limited value. I do not think it is worth it on its own. > > Upstream issue says this "should addressed in [...] 3.3" which means > they might have rolled out a patch for our precious jessie release on > this: > > https://gitlab.com/gnutls/gnutls/issues/455 > > So I think it would make sense do backport that work - according to the > security tracker, there's a minimal patch that might fix this in: > > https://gitlab.com/gnutls/gnutls/commit/cc14ec5ece856cb083d64e6a5a8657323da661cb Correct, I'm the one that added that entry to the security tracker. :-) I also agree that we should do this, but only if we change any of the other. I would not upload a new package with just this. But this is more of a copy paste error from the ELTS email. I should have removed that sentence about "not worth on its own". > But that is also part of the the larger fix in CVE-2018-10846 from what > I understand, that is MR#657. Correct. > > 3: Should we remove SHA256 and SHA384 from the default MAC ciphers? It > > add some extra protection against this but it is a backwards > > compatibility problem and therefore may not be good from an > > availability perspective. I'm not sure how good it is to remove > > ciphers such late in the release cycle either. SHA256 and SHA384 is > > mostly deprecated now
Re: twitter-bootstrap / CVE-2018-14040 / CVE-2018-14041 / CVE-2018-14042
On 2018-08-29 12:23:54, Brian May wrote:
> Antoine Beaupré writes:
>
>> On 2018-08-08 17:35:52, Brian May wrote:
>>> If I got this right, we cannot use $(xyz) unless the value of xyz is
>>> trusted. Otherwise executing $(xyz) can result in the execution of code
>>> if xyz is something like "". This
>>> happens immediately, and even if you don't use the return value.
>>
>> I am a bit puzzled as to how this attack works, but I'm ready to accept
>> that as yet another jQuery excentricity. :)
>
> So my understanding only, $(...) has been overloaded and has a number of
> distinct uses.
>
> You can use it to look up a value, e.g.:
>
> $("#myid")
>
> You can use it to create a DOM element:
>
> $("ABC")
>
> Or:
>
> $("")
>
> This will not only create the dom element, and try to preload the
> image. When this fails, the onerror hook is called.
>
> You could also use it to wrap a JS DOM element in a jquery selector, but
> this use isn't so relevant here.
Right, of course. That makes sense, somewhat.
> The problem occurs as this code does lookups on untrusted values like:
>
> $(untrusted_input)
>
> The problem being if untrusted_input can change the mode from "lookup"
> to "create" which in turn assumes that the data passed is trusted.
>
> I think the real problem here is poor jquery API, however I doubt this
> is going to change anytime soon as this would break everything that uses
> jquery.
Indeed. As far as Bootstrap is concerned, they are just going away from
that API at this point and use native lookups without side-effects:
https://github.com/twbs/bootstrap/issues/26643
But unfortunately, that work was done only in Bootstrap 4, which is not
even in Debian yet.
There are, unfortunately, a non-trivial number of packages depending on
bootstrap (even v2!) in the archive still, otherwise I would propose to
just remove the damn things and get it over with.
I guess the proper process here would be to actually test a few
instances to see if we are still vulnerable and open issues (CVE?
upstream?) to track those.
What do you think? Should we push this forward?
A.
--
Freedom of speech is a principal pillar of a free government; when
this support is taken away, the constitution of a free society is
dissolved, and tyranny is erected on its ruins.
- Benjamin Franklin, 1737
Accepted spice 0.12.5-1+deb8u6 (source amd64) into oldstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 31 Aug 2018 20:44:48 +0200 Source: spice Binary: spice-client libspice-server1 libspice-server1-dbg libspice-server-dev Architecture: source amd64 Version: 0.12.5-1+deb8u6 Distribution: jessie-security Urgency: medium Maintainer: Liang Guo Changed-By: Mike Gabriel Description: libspice-server-dev - Header files and development documentation for spice-server libspice-server1 - Implements the server side of the SPICE protocol libspice-server1-dbg - Debugging symbols for libspice-server1 spice-client - Implements the client side of the SPICE protocol Changes: spice (0.12.5-1+deb8u6) jessie-security; urgency=medium . * Non-maintainer upload by the LTS Team. * CVE-2018-10873: A vulnerability was discovered in SPICE before version 0.14.1 where the generated code used for demarshalling messages lacked sufficient bounds checks. A malicious client or server, after authentication, could send specially crafted messages to its peer which would result in a crash or, potentially, other impacts. . Fix: Bail out with an error if the pointer to the start of some message data is strictly greater than the pointer to the end of the message data. . See review comments in debian/patches/CVE-2018-10873.patch about potential weaknesses of this fix. Checksums-Sha1: 08ffd2a001aa30123c047dd3c7ad91688dc95179 2398 spice_0.12.5-1+deb8u6.dsc 2fabe47611cac6b43b3c2c61e400d7375f06e16a 1737169 spice_0.12.5.orig.tar.bz2 a0c57412a805615c21d05bbb88693422f5fba75b 32528 spice_0.12.5-1+deb8u6.debian.tar.xz 18b30b59aa86c94369e7c861dc3663f52f64cf5b 494628 spice-client_0.12.5-1+deb8u6_amd64.deb f9186feee231617f3f50e0fca64ca4b384ff8134 473024 libspice-server1_0.12.5-1+deb8u6_amd64.deb e1f73e015a8627438efbece0119688422870de6b 1213574 libspice-server1-dbg_0.12.5-1+deb8u6_amd64.deb 7ff3356af483af2fe36d350c447f49b13e2b501d 507340 libspice-server-dev_0.12.5-1+deb8u6_amd64.deb Checksums-Sha256: 759602fa0978bd77063ce72af9ea424919ff63bb954d602afd20d686cf84c12f 2398 spice_0.12.5-1+deb8u6.dsc 4209a20d8f67cb99a8a6ac499cfe79a18d4ca226360457954a223d6795c2f581 1737169 spice_0.12.5.orig.tar.bz2 028e5620545e5b447f565e6505b4643daa2467adc61aedb1177644e7c39bceb5 32528 spice_0.12.5-1+deb8u6.debian.tar.xz c4ce7952b70628856d1a66954849225b747e70d64bb1dbffb6050cef989a0238 494628 spice-client_0.12.5-1+deb8u6_amd64.deb 942d80ad05524066643f58075df470587968bde395c25e0a6e98f39e55aa9955 473024 libspice-server1_0.12.5-1+deb8u6_amd64.deb 31087232f91ed17caeb3dcf951f2e0097f1e1013fd3ae72592fc151bac433312 1213574 libspice-server1-dbg_0.12.5-1+deb8u6_amd64.deb c0da8de6583a2194fa0a8ecc954b597827d67623688ca8517ad2badc23e94243 507340 libspice-server-dev_0.12.5-1+deb8u6_amd64.deb Files: a9df62402ff8712d0dd68e8ac7ac19a3 2398 misc optional spice_0.12.5-1+deb8u6.dsc 1256286214fe402703c0a01bd3a85319 1737169 misc optional spice_0.12.5.orig.tar.bz2 70e542e318aa8abb8a0192dc33270180 32528 misc optional spice_0.12.5-1+deb8u6.debian.tar.xz 76dfeb14f31b43c60da300a13b317de4 494628 misc optional spice-client_0.12.5-1+deb8u6_amd64.deb 14125295758c019722375c7cbf7bbf7b 473024 libs optional libspice-server1_0.12.5-1+deb8u6_amd64.deb a53d9aeaf6a95cdc89ba8ce8ac2d0893 1213574 debug extra libspice-server1-dbg_0.12.5-1+deb8u6_amd64.deb 598643136be5cc00da0366353c789552 507340 libdevel optional libspice-server-dev_0.12.5-1+deb8u6_amd64.deb -BEGIN PGP SIGNATURE- iQJJBAEBCAAzFiEEm/uu6GwKpf+/IgeCmvRrMCV3GzEFAluJqBwVHHN1bndlYXZl ckBkZWJpYW4ub3JnAAoJEJr0azAldxsx9coP/24xh2nTKIvo0w1Fb4zDiEMFHBUA A2WcthvA6eoqcu0tf4WzzE42P28vgy3S26kYIIqRK1d+RNKjzHe3P0XJNw/95S2C vJ+T4qoJDmWhsDTh9fFLouvuCCEOXNYMFOgP7Ft1EMu49JdtjfMOPP5OcDLcw4xb jHPOVCe+jd4xRkIEoY9HgdxaF/VMx+uo3Goq6NQaILguMyVXcEQXxdFx3kMs5jH3 5blIWXGhI/41knKti5a8oppsuOSvgyE1tLid309i5Whkd8bliiah0SFOPN/1H4IS h3zt4quVK43n+HsX6LMvPufS1uJIvcYpPICNSgCJrpbGyYMsT/GLXK3zRdmMyMSI jeEZOizvvWbjtqujyWnse8apSqeT21glMgn9KrQiGU3HqZuONABiiuxQm+o/ZyzA O2Jnh2+MMSrQio9kEnWwbA08MFIUJUC4F53uDTWAda6UqsPwhsazopCGsGAbUJ5F 1Y0wJu06m6gqCqBqWnzKJs/++FVBMxsybtyEmQ33vG5IeLcoes/W61Mj3F4rBTg0 j8NVgw/1byG3euzIwCZjTwKw6LGVZLQFsXU5loBf+lPTzFv4CzEE4ftK+fWZilA3 sqXRcCs8g29VrI2bQAA6Cyj3FjlfbGswv6Z8am7vlM2DaEHyQ+L1AE6kYTBKlam/ CEzmSMB12JzMhFVR =7DLm -END PGP SIGNATURE-
Re: Gnutls investigation and request for advice for Jessie
On 2018-08-31 21:30:14, Ola Lundqvist wrote: > Hi Antoine > > Thank you for the input this is valuable. I have some comments below. > > On Fri, 31 Aug 2018 at 21:03, Antoine Beaupré wrote: >> >> On 2018-08-31 13:29:29, Ola Lundqvist wrote: >> > Hi all LTS contributors >> > >> > My question is whether removing default ciphers and introducing new >> > options is acceptable so late in the release cyckle. My assumption is >> > no, but let me know if you have another opinion. More details below. >> >> A priori, I think it is if it fixes serious security vulnerabilities and >> there is no easier way to do so. > > I'm not so sure this is a serious issue as it is only exploitable in a > rather uncommon case, that is when Encrypt-then-MAC (RFC7366) is > unsupported by the peer. > Most software do have that support as I understand it. That's the crucial part, I guess. :) I am not sure. [...] >> > Upstream do in fact not even plan to do this as the problem only occur >> > in the following cases: >> > - CBC cipher >> > - If Encrypt-then-MAC (RFC7366) is unsupported by the peer >> > >> > Instead upstream have done the following: >> > 1) Introduced a new option to enforce Encrypt-then-MAC (for CVE-2018-10846) >> > 2) Do a fix with SHA384 (for CVE-2018-10845) >> > 3) Remove SHA256 and SHA384 from the default MAC ciphers (for >> > CVE-2018-10844 and CVE-2018-10845) >> > 4) A try to fix the problem (CVE-2018-10844 and potentially CVE-2018-10845) >> > >> > 1: I do not think we can do 1 such late in the release cycle. I mean >> > new options now would be rather pointless. I will mark CVE-2018-10846 >> > as ignored due to this. Or do you think new options is ok also in >> > Jessie? >> >> I looked at the upstream patch (MR#657) for this and it doesn't look >> that invasive. According to GitLab, it is "21 files with 738 additions >> and 148 deletions", which seems fairly small considering the scope of >> the change: >> >> https://gitlab.com/gnutls/gnutls/merge_requests/657.patch > > I agree on that. But introducing an option will not help in most cases > that use gnutls. I mean gnutls is used in most cases as a library and > unless the other software is changed then there is no use of > introducing the option. That's true! I'm not sure how to deal with that... I guess it means library users need to do the right thing then? Unless they mess around with cipher lists the way charybdis does? [...] >> This, again, is also part of the larger fix in MR#657. >> >> Combined, those last two patches make about +- 50 lines of diff, >> compared to the 700+ lines of diff for the larger merge request. But do >> consider that a large part of MR#657 (+400 lines) is the introduction of >> tests/tls-force-etm.c, a standalone file which shouldn't cause conflicts >> at the very least. >> >> > I think I should do 2 and 4, but not 1 and 3. >> > >> > What do you think? If I do not hear any objections I'll do so. >> >> I would give it a shot and try to backport the whole thing. I would also >> carefully look at the 3.3.x series to see if there's an official commit >> shipping those. At first glance, it does look like a release was made on >> all branches, including a 3.3.30 release that bundles some of those >> patches. > > But not the default cipher removal, right? Actually, looking at the NEWS file, they *did* remove the ciphers from the defaults list as well. >> In fact, I'd be tempted to seriously consider upgrading to that upstream >> release after comparing our changelog with theirs to see if there's >> anything missing either side... > > That is another way. I'm not so comfortable with doing that > considering that I broke some software I did that with a library > package. I do not remember what library it was now but some browser > did not work after that. You mean the NSS library and #843624? :) That was a hairy issue and it affected an unsupported package (chromium). I don't think you should stop from working on difficult package because of one difficulty. If anything, that was a learning experience and you are now *more* qualified to deal with such packages now. ;) If you are unsure about updates, upload a test package somewhere and ask people for feedback. I do it all the time and it actually works, if you give people time (sometimes a week or more). For an update as critical, it would certainly be warranted. >> It seems that upstream did the right thing here and backported a bunch >> of stuff for us already - it'd be too bad to waste that effort and skip >> those CVEs. ;) > > :-D on the other hand maybe we break backwards compatibility. If it > wasn't for the backwards compatibility I would not have asked. :-) Yeah, I guess I don't know what's in those updates exactly, that's a good point. > Again thank you for the input. Glad to be of service! A.
Bug#907723: link package versions on security-tracker to source packages
Package: security-tracker Severity: wishlist X-Debbugs-Cc: debian-lts@lists.debian.org Hi, when working for the LTS team, I regularly need to download source packages from the LTS version of Debian. My development machine normally runs a newer Debian version, having deb-src URLs for Debian LTS in sources.list is possible but not a good option (for me) as it increases latency for apt update. So, I always go to [1] with my web browser, copy the URL of the .dsc file and then dget that .dsc file. However, for the actual CVE tracking work, I browse the security-tracker.debian.org platform. This could be my only web tool to use, if it allowed me to download source packages directly from there. Unfortunately, this is not (yet) possible. On a page like this [2] all package versions of the given package in Debian are listed, so it should be easy to make these version strings clickable hyperrefs that either link to the corresponding page on [1] or even directly to the .dsc file of that version in the package archive (the latter would be my preferred choice). Is that something that would be helpful to others using the security-tracker? What would be the preferred linking target, if so, then? Looking forward to some feedback from Security team members and LTS members. I'd be happy to put some work into this, if liked by others. Thanks+Greets, Mike [1] https://packages.debian.org/source// [1] https://security-tracker.debian.org/tracker/CVE-2018-10873 -- 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 pgpJ0yLem6HwV.pgp Description: Digitale PGP-Signatur
Re: [SECURITY] [DLA 1488-1 (invalid)] spice security update
Dear all, On Fr 31 Aug 2018 23:30:53 CEST, Mike Gabriel wrote: Package: spice Version: 0.12.5-1+deb8u6 CVE ID : CVE-2018-10873 Debian Bug : #906315 A vulnerability was discovered in SPICE before version 0.14.1 where the generated code used for demarshalling messages lacked sufficient bounds checks. A malicious client or server, after authentication, could send specially crafted messages to its peer which would result in a crash or, potentially, other impacts. The issue has been fixed by upstream by bailing out with an error if the pointer to the start of some message data is strictly greater than the pointer to the end of the message data. For Debian 8 "Jessie", this problem has been fixed in version 0.12.5-1+deb8u6. We recommend that you upgrade your spice packages. Further information about Debian LTS security advisories, how to apply these updates to your system and frequently asked questions can be found at: https://wiki.debian.org/LTS please note that this DLA email has been sent under the wrong DLA number (was: DLA-1488-1, should have been DLA-1486-1). A new email announcement for the recent upload of spice to Debian LTS has been sent as DLA-1486-1 to this mailing list, please reference that in case of occuring regressions or other issues you find in the uploaded package. Sorry for the inconvenience, Mike -- mike gabriel aka sunweaver (Debian Developer) mobile: +49 (1520) 1976 148 landline: +49 (4354) 8390 139 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: sunwea...@debian.org, http://sunweavers.net pgpgvNKhazWOo.pgp Description: Digitale PGP-Signatur
[SECURITY] [DLA 1486-1] spice security update
Package: spice Version: 0.12.5-1+deb8u6 CVE ID : CVE-2018-10873 Debian Bug : #906315 A vulnerability was discovered in SPICE before version 0.14.1 where the generated code used for demarshalling messages lacked sufficient bounds checks. A malicious client or server, after authentication, could send specially crafted messages to its peer which would result in a crash or, potentially, other impacts. The issue has been fixed by upstream by bailing out with an error if the pointer to the start of some message data is strictly greater than the pointer to the end of the message data. For Debian 8 "Jessie", this problem has been fixed in version 0.12.5-1+deb8u6. We recommend that you upgrade your spice packages. Further information about Debian LTS security advisories, how to apply these updates to your system and frequently asked questions can be found at: https://wiki.debian.org/LTS -- mike gabriel aka sunweaver (Debian Developer) fon: +49 (1520) 1976 148 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: sunwea...@debian.org, http://sunweavers.net signature.asc Description: PGP signature
[SECURITY] [DLA 1488-1] mariadb-10.0 security update
Package: mariadb-10.0 Version: 10.0.36-0+deb8u1 CVE ID : CVE-2018-3058 CVE-2018-3063 CVE-2018-3064 CVE-2018-3066 Debian Bug : 904121 Several issues have been discovered in the MariaDB database server. The vulnerabilities are addressed by upgrading MariaDB to the new upstream version 10.0.36. Please see the MariaDB 10.0 Release Notes for further details: https://mariadb.com/kb/en/mariadb/mariadb-10036-release-notes/ CVE-2018-3058 Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of MySQL Server accessible data. CVE-2018-3063 Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVE-2018-3064 Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as unauthorized update, insert or delete access to some of MySQL Server accessible data. CVE-2018-3066 Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of MySQL Server accessible data as well as unauthorized read access to a subset of MySQL Server accessible data. For Debian 8 "Jessie", these problems have been fixed in version 10.0.36-0+deb8u1. We recommend that you upgrade your mariadb-10.0 packages. Further information about Debian LTS security advisories, how to apply these updates to your system and frequently asked questions can be found at: https://wiki.debian.org/LTS signature.asc Description: PGP signature
[SECURITY] [DLA 1489-1] spice-gtk security update
Package: spice-gtk Version: 0.25-1+deb8u1 CVE ID : CVE-2018-10873 Debian Bug : 906316 A vulnerability was discovered in SPICE before version 0.14.1 where the generated code used for demarshalling messages lacked sufficient bounds checks. A malicious client or server, after authentication, could send specially crafted messages to its peer which would result in a crash or, potentially, other impacts. The issue has been fixed by upstream by bailing out with an error if the pointer to the start of some message data is strictly greater than the pointer to the end of the message data. The above issue and fix have already been announced for the "spice" Debian package (as DLA-1486-1 [1]). This announcement is about the "spice-gtk" Debian package (which ships some copies of code from the "spice" package, where the fix of this issue had to be applied). [1] https://lists.debian.org/debian-lts-announce/2018/08/msg00037.html For Debian 8 "Jessie", this problem has been fixed in version 0.25-1+deb8u1. We recommend that you upgrade your spice-gtk packages. Further information about Debian LTS security advisories, how to apply these updates to your system and frequently asked questions can be found at: https://wiki.debian.org/LTS -- mike gabriel aka sunweaver (Debian Developer) fon: +49 (1520) 1976 148 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: sunwea...@debian.org, http://sunweavers.net signature.asc Description: PGP signature
Accepted php5 5.6.37+dfsg-0+deb8u1 (source all amd64) into oldstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 31 Aug 2018 22:28:51 -0400 Source: php5 Binary: php5 php5-common libapache2-mod-php5 libapache2-mod-php5filter php5-cgi php5-cli php5-phpdbg php5-fpm libphp5-embed php5-dev php5-dbg php-pear php5-curl php5-enchant php5-gd php5-gmp php5-imap php5-interbase php5-intl php5-ldap php5-mcrypt php5-readline php5-mysql php5-mysqlnd php5-odbc php5-pgsql php5-pspell php5-recode php5-snmp php5-sqlite php5-sybase php5-tidy php5-xmlrpc php5-xsl Architecture: source all amd64 Version: 5.6.37+dfsg-0+deb8u1 Distribution: jessie-security Urgency: high Maintainer: Debian PHP Maintainers Changed-By: Roberto C. Sanchez Description: libapache2-mod-php5 - server-side, HTML-embedded scripting language (Apache 2 module) libapache2-mod-php5filter - server-side, HTML-embedded scripting language (apache 2 filter mo libphp5-embed - HTML-embedded scripting language (Embedded SAPI library) php-pear - PEAR - PHP Extension and Application Repository php5 - server-side, HTML-embedded scripting language (metapackage) php5-cgi - server-side, HTML-embedded scripting language (CGI binary) php5-cli - command-line interpreter for the php5 scripting language php5-common - Common files for packages built from the php5 source php5-curl - CURL module for php5 php5-dbg - Debug symbols for PHP5 php5-dev - Files for PHP5 module development php5-enchant - Enchant module for php5 php5-fpm - server-side, HTML-embedded scripting language (FPM-CGI binary) php5-gd- GD module for php5 php5-gmp - GMP module for php5 php5-imap - IMAP module for php5 php5-interbase - interbase/firebird module for php5 php5-intl - internationalisation module for php5 php5-ldap - LDAP module for php5 php5-mcrypt - MCrypt module for php5 php5-mysql - MySQL module for php5 php5-mysqlnd - MySQL module for php5 (Native Driver) php5-odbc - ODBC module for php5 php5-pgsql - PostgreSQL module for php5 php5-phpdbg - server-side, HTML-embedded scripting language (PHPDBG binary) php5-pspell - pspell module for php5 php5-readline - Readline module for php5 php5-recode - recode module for php5 php5-snmp - SNMP module for php5 php5-sqlite - SQLite module for php5 php5-sybase - Sybase / MS SQL Server module for php5 php5-tidy - tidy module for php5 php5-xmlrpc - XML-RPC module for php5 php5-xsl - XSL module for php5 Closes: 890266 Changes: php5 (5.6.37+dfsg-0+deb8u1) jessie-security; urgency=high . * Non-maintainer upload by the LTS Team. * New upstream version 5.6.37+dfsg - [CVE-2018-14883] An Integer Overflow leads to a heap-based buffer over-read in exif_thumbnail_extract of exif.c. - [CVE-2018-14851] exif_process_IFD_in_MAKERNOTE in ext/exif/exif.c allows remote attackers to cause a denial of service (out-of-bounds read and application crash) via a crafted JPEG file. * Drop patch for CVE-2017-7272. The patch breaks many applications that rely on undocumented behavior, was dropped by other distros, and the CVE was marked "ignore" by the security team. (Closes: #890266) Checksums-Sha1: 8bf1e30f50dc0b9a626554de9ad90bfde375499c 5096 php5_5.6.37+dfsg-0+deb8u1.dsc 00604a05f00fb65cdaa29a4ddf1690f7efc86d5d 19440222 php5_5.6.37+dfsg.orig.tar.gz a8ccbefd4687cf491a7dd12048b20c3ea3e1bb2f 132536 php5_5.6.37+dfsg-0+deb8u1.debian.tar.xz f8a20e6dd38d889057ca0e0e87efe8248f1c5ff3 1310 php5_5.6.37+dfsg-0+deb8u1_all.deb af90379dcafda635121d99c2faf3175e096589e1 265566 php-pear_5.6.37+dfsg-0+deb8u1_all.deb a4f894c22e90a34c3edd865f508eec6b6e039da7 743490 php5-common_5.6.37+dfsg-0+deb8u1_amd64.deb 8160e2bcf81ffc05c54df8672e0ada4e6225bbc8 2230058 libapache2-mod-php5_5.6.37+dfsg-0+deb8u1_amd64.deb dbbcb50841bd2ba39daf7e94a5ef4f9f9ee645af 2225522 libapache2-mod-php5filter_5.6.37+dfsg-0+deb8u1_amd64.deb 17460586d879bfbe409b94d87945008255fbe87c 4314742 php5-cgi_5.6.37+dfsg-0+deb8u1_amd64.deb 235d72678759ca995923e109290b22cf1f2e6fb3 2199246 php5-cli_5.6.37+dfsg-0+deb8u1_amd64.deb aea78adc88c9b13661cd5e54c013dd83bd17c009 2208424 php5-phpdbg_5.6.37+dfsg-0+deb8u1_amd64.deb da66cf940656ae4850f4baf9f4eeb8c4cdc584aa 2212452 php5-fpm_5.6.37+dfsg-0+deb8u1_amd64.deb e5587b8aef8ae00917a39f3929d5aab90f7bdf3f 2224324 libphp5-embed_5.6.37+dfsg-0+deb8u1_amd64.deb c1501f6704ce09ee20fa8829085acb3eab8656e1 357040 php5-dev_5.6.37+dfsg-0+deb8u1_amd64.deb 439b9ded4989a0bd10f6c1572728d010c1a610bf 51247992 php5-dbg_5.6.37+dfsg-0+deb8u1_amd64.deb e9eec664667d9d24213a2d9665c5a9b21f6b610b 27988 php5-curl_5.6.37+dfsg-0+deb8u1_amd64.deb f92c81e51ef59659ad20bf7bc4adc47f3f45adcd 9442 php5-enchant_5.6.37+dfsg-0+deb8u1_amd64.deb e31fe591470fd3c52ab287144e542251588b91fb 29236 php5-gd_5.6.37+dfsg-0+deb8u1_amd64.deb 64827f4e8cae46a76a0390219cd1e8ce375e693e 21700 php5-gmp_5.6.37+dfsg-0+deb8u1_amd64.deb d5eaf12de2e960cbb45dee7cb988754937c1f89a 31700 php5-imap_5.6.37+dfsg-0+deb8u1_amd64.deb
Accepted spice-gtk 0.25-1+deb8u1 (source amd64) into oldstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 31 Aug 2018 23:52:16 +0200 Source: spice-gtk Binary: spice-client-gtk spice-client-glib-usb-acl-helper libspice-client-glib-2.0-8 gir1.2-spice-client-glib-2.0 libspice-client-glib-2.0-dev libspice-client-gtk-2.0-4 gir1.2-spice-client-gtk-2.0 libspice-client-gtk-2.0-dev libspice-client-gtk-3.0-4 gir1.2-spice-client-gtk-3.0 libspice-client-gtk-3.0-dev python-spice-client-gtk Architecture: source amd64 Version: 0.25-1+deb8u1 Distribution: jessie-security Urgency: medium Maintainer: Liang Guo Changed-By: Mike Gabriel Description: gir1.2-spice-client-glib-2.0 - GObject for communicating with Spice servers (GObject-Introspecti gir1.2-spice-client-gtk-2.0 - GTK2 widget for SPICE clients (GObject-Introspection) gir1.2-spice-client-gtk-3.0 - GTK3 widget for SPICE clients (GObject-Introspection) libspice-client-glib-2.0-8 - GObject for communicating with Spice servers (runtime library) libspice-client-glib-2.0-dev - GObject for communicating with Spice servers (development files) libspice-client-gtk-2.0-4 - GTK2 widget for SPICE clients (runtime library) libspice-client-gtk-2.0-dev - GTK2 widget for SPICE clients (development files) libspice-client-gtk-3.0-4 - GTK3 widget for SPICE clients (runtime library) libspice-client-gtk-3.0-dev - GTK3 widget for SPICE clients (development files) python-spice-client-gtk - GTK2 widget for SPICE clients (Python binding) spice-client-glib-usb-acl-helper - Spice client glib usb acl helper spice-client-gtk - Simple clients for interacting with SPICE servers Changes: spice-gtk (0.25-1+deb8u1) jessie-security; urgency=medium . * Non-maintainer upload by the LTS Team. * CVE-2018-10873: A vulnerability was discovered in SPICE before version 0.14.1 where the generated code used for demarshalling messages lacked sufficient bounds checks. A malicious client or server, after authentication, could send specially crafted messages to its peer which would result in a crash or, potentially, other impacts. . Fix: Bail out with an error if the pointer to the start of some message data is strictly greater than the pointer to the end of the message data. . See review comments in debian/patches/CVE-2018-10873.patch about potential weaknesses of this fix. Checksums-Sha1: 9aab0ec657bc54dc5ccd166ce689e0b11d70e927 3501 spice-gtk_0.25-1+deb8u1.dsc dc4caf42d7497ba424efc22720946d116ead5dd2 1242457 spice-gtk_0.25.orig.tar.bz2 54c8eba041a4869e72c96bee0bbfcdfcb00dfd3c 13972 spice-gtk_0.25-1+deb8u1.debian.tar.xz 84ab52bc5daf372b39ef44f1cb58cfa3482d3c93 143616 spice-client-gtk_0.25-1+deb8u1_amd64.deb fa9d7025d2b91d2675a8909a4b511823ea5b3895 123280 spice-client-glib-usb-acl-helper_0.25-1+deb8u1_amd64.deb 8d542868ac90156114f25b0762f39850358f5d8c 412092 libspice-client-glib-2.0-8_0.25-1+deb8u1_amd64.deb 898d653b9242ab6017d8612b42d047fdbcb75bea 125106 gir1.2-spice-client-glib-2.0_0.25-1+deb8u1_amd64.deb 75322d47740ff7309dc1307c0e64283ce406608c 145686 libspice-client-glib-2.0-dev_0.25-1+deb8u1_amd64.deb 33aed38a899ccaa22513005a31bf267aff79ca81 151410 libspice-client-gtk-2.0-4_0.25-1+deb8u1_amd64.deb 21167358f47bc0979cf5c3cdee009663e4065662 119952 gir1.2-spice-client-gtk-2.0_0.25-1+deb8u1_amd64.deb dbc8bd3adc88e7eb4c8483a988ba222db6f7c70c 176978 libspice-client-gtk-2.0-dev_0.25-1+deb8u1_amd64.deb a3cc8d419902dc8efada7d0bd241347b9f205f3d 152324 libspice-client-gtk-3.0-4_0.25-1+deb8u1_amd64.deb 20b2ab3c988612608d8234c74d0b1cfed4171c1c 119950 gir1.2-spice-client-gtk-3.0_0.25-1+deb8u1_amd64.deb d041db3f114c2e7fd2f215890a0396cb8c4c9cff 125098 libspice-client-gtk-3.0-dev_0.25-1+deb8u1_amd64.deb 1ee5f41db8580f7b0044690f17e23d4f1878b436 129330 python-spice-client-gtk_0.25-1+deb8u1_amd64.deb Checksums-Sha256: d1cef3d9d26636900cb51e082eca45989806b6397649d50c11cf94ef91a7b17b 3501 spice-gtk_0.25-1+deb8u1.dsc 0730c6a80ad9f5012f65927d443377019f300573f7ccc93db84eadec462ad087 1242457 spice-gtk_0.25.orig.tar.bz2 d07351332754dbb78e3f707f6cfa7ab278bd2d46c60e5a77be46b4f33d2048d1 13972 spice-gtk_0.25-1+deb8u1.debian.tar.xz c209f961d0a5057e6a49ed81860ec9270a096a3296d494c9b35ee8dd5b120b45 143616 spice-client-gtk_0.25-1+deb8u1_amd64.deb 0486197f8560f1b2e499c5ad18a5477dedb1cb1bf773d763264eba607963b56a 123280 spice-client-glib-usb-acl-helper_0.25-1+deb8u1_amd64.deb 76da8267fd1a307f401a535d8e5df66d6ec7c110d6d5ead0d8fe4784d019e8f0 412092 libspice-client-glib-2.0-8_0.25-1+deb8u1_amd64.deb 6a861c0dca7d063bb1a2ce9395eafa67454321fa23f8bf874c063674a35a 125106 gir1.2-spice-client-glib-2.0_0.25-1+deb8u1_amd64.deb bed7c5cb8a6137c4e2f989f7f9017e74653456caea8d6941ed36a71e0ed08802 145686 libspice-client-glib-2.0-dev_0.25-1+deb8u1_amd64.deb f9aff8f0cc54e9102d2c303114861ecf041ed819142b9eab95904309662db2b4 151410 libspice-client-gtk-2.0-4_0.25-1+deb8u1_amd64.deb 3fe3f2bd3ce546599ffea728462b230321e5e1aefaceb84e56a052e3c8446ba4 119952
Re: fix squirrelmail bug 775720 in jessie
Hello Matus On Friday 31 August 2018 05:25 PM, Matus UHLAR - fantomas wrote: > Hello, > > the debian bug 775720 for squirrelmail was closed by debian maintainer > because squirrelmail was removed from archive. > > However, there were security 3 updates to squirrelmail since, and I've had > to fix the same bug (apply the same patch) 3 times after each update. > > Does it sound logical to apply the mentioned patch to squirrelmail, should > that happen again? > > Thank you I don't see any problem in merging that patch to the package. I will consider that on next security update of squirrelmail. But lets hear what other LTS members have to say :) --abhijith.
Gnutls investigation and request for advice for Jessie
Hi all LTS contributors My question is whether removing default ciphers and introducing new options is acceptable so late in the release cyckle. My assumption is no, but let me know if you have another opinion. More details below. If you have seen my email to ELTS then you may read faster. It is not identical as the Jessie version is significantly easier to port than the wheezy version. I think I need some advice. I have investigated the following issues for gnutls. CVE-2018-10844 CVE-2018-10845 CVE-2018-10846 I hope to spare you the time to read the full scientific paper on this matter. The overall problem is that by running some piece of software on the same CPU as the gnutls software is running it is possible to decrypt the plaintext by very smart techniques to deduce things from timing differences. OpenSSL has fully addressed this by always taking exactly the same time regardless of the input data but this was not properly done for gnutls. Upstream do in fact not even plan to do this as the problem only occur in the following cases: - CBC cipher - If Encrypt-then-MAC (RFC7366) is unsupported by the peer Instead upstream have done the following: 1) Introduced a new option to enforce Encrypt-then-MAC (for CVE-2018-10846) 2) Do a fix with SHA384 (for CVE-2018-10845) 3) Remove SHA256 and SHA384 from the default MAC ciphers (for CVE-2018-10844 and CVE-2018-10845) 4) A try to fix the problem (CVE-2018-10844 and potentially CVE-2018-10845) 1: I do not think we can do 1 such late in the release cycle. I mean new options now would be rather pointless. I will mark CVE-2018-10846 as ignored due to this. Or do you think new options is ok also in Jessie? 2: 2 is easy to do but as SHA384 is not part of the default ciphers I see limited value. I do not think it is worth it on its own. 3: Should we remove SHA256 and SHA384 from the default MAC ciphers? It add some extra protection against this but it is a backwards compatibility problem and therefore may not be good from an availability perspective. I'm not sure how good it is to remove ciphers such late in the release cycle either. SHA256 and SHA384 is mostly deprecated now when AEAD cipher is available but still the peer could be an old version (for example AEAD was not supported in wheezy). 4: Will do this and I do not think the backporting work is that complicated. I will investigate a little more. I think I should do 2 and 4, but not 1 and 3. What do you think? If I do not hear any objections I'll do so. Best regards // Ola -- --- Inguza Technology AB --- MSc in Information Technology / o...@inguza.comFolkebogatan 26\ | o...@debian.org 654 68 KARLSTAD| | http://inguza.com/Mobile: +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
fix squirrelmail bug 775720 in jessie
Hello, the debian bug 775720 for squirrelmail was closed by debian maintainer because squirrelmail was removed from archive. However, there were security 3 updates to squirrelmail since, and I've had to fix the same bug (apply the same patch) 3 times after each update. Does it sound logical to apply the mentioned patch to squirrelmail, should that happen again? Thank you -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. He who laughs last thinks slowest.
Re: fix squirrelmail bug 775720 in jessie
On 2018-08-31 19:42:15, Abhijith PA wrote: > Hello Matus > > On Friday 31 August 2018 05:25 PM, Matus UHLAR - fantomas wrote: >> Hello, >> >> the debian bug 775720 for squirrelmail was closed by debian maintainer >> because squirrelmail was removed from archive. >> >> However, there were security 3 updates to squirrelmail since, and I've had >> to fix the same bug (apply the same patch) 3 times after each update. >> >> Does it sound logical to apply the mentioned patch to squirrelmail, should >> that happen again? >> >> Thank you > > I don't see any problem in merging that patch to the package. I will > consider that on next security update of squirrelmail. > > But lets hear what other LTS members have to say :) We normally don't apply such patches to LTS unless they fix a release-critical bug. This bug is marked as "normal" so I am not sure it's worthy of such a change. But it might have been misfiled! It does seem like a major regression for non-ASCII languages, something I am obviously sensitive to. ;) That said, I would also be very careful about merging patches in LTS that have not been merged upstream. Considering upstream is dead, it might make that difficult, but extra careful consideration should then be applied if we merge at all. Cheers, A. -- The destiny of Earthseed is to take root among the stars. - Octavia Butler
Re: fix squirrelmail bug 775720 in jessie
( Sorry for the duplicate, forgot to add ) Hello Matus On Friday 31 August 2018 05:25 PM, Matus UHLAR - fantomas wrote: > Hello, > > the debian bug 775720 for squirrelmail was closed by debian maintainer > because squirrelmail was removed from archive. > > However, there were security 3 updates to squirrelmail since, and I've had > to fix the same bug (apply the same patch) 3 times after each update. > > Does it sound logical to apply the mentioned patch to squirrelmail, should > that happen again? > > Thank you I don't see any problem in merging that patch to the package. I will consider that on next security update of squirrelmail. But lets hear what other LTS members have to say :) --abhijith.
