Accepted tomcat6 6.0.45+dfsg-1~deb7u5 (source all) into oldstable

[Markus Koschany]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 17 Dec 2016 17:28:37 +0100
Source: tomcat6
Binary: tomcat6-common tomcat6 tomcat6-user libtomcat6-java libservlet2.4-java 
libservlet2.5-java libservlet2.5-java-doc tomcat6-admin tomcat6-examples 
tomcat6-docs tomcat6-extras
Architecture: source all
Version: 6.0.45+dfsg-1~deb7u5
Distribution: wheezy-security
Urgency: high
Maintainer: Debian Java Maintainers 

Changed-By: Markus Koschany 
Description: 
 libservlet2.4-java - Transitional package for libservlet2.5-java
 libservlet2.5-java - Servlet 2.5 and JSP 2.1 Java API classes
 libservlet2.5-java-doc - Servlet 2.5 and JSP 2.1 Java API documentation
 libtomcat6-java - Servlet and JSP engine -- core libraries
 tomcat6- Servlet and JSP engine
 tomcat6-admin - Servlet and JSP engine -- admin web applications
 tomcat6-common - Servlet and JSP engine -- common files
 tomcat6-docs - Servlet and JSP engine -- documentation
 tomcat6-examples - Servlet and JSP engine -- example web applications
 tomcat6-extras - Servlet and JSP engine -- additional components
 tomcat6-user - Servlet and JSP engine -- tools to create user instances
Closes: 848492
Changes: 
 tomcat6 (6.0.45+dfsg-1~deb7u5) wheezy-security; urgency=high
 .
   * Backport only the minimal changes to fix #845425. (Closes: #848492)
Checksums-Sha1: 
 e84827f6d5b469c53295142746d3c4270899edd9 2905 tomcat6_6.0.45+dfsg-1~deb7u5.dsc
 ac345574ee12b3b18729f217295a99ab39e174ec 60525 
tomcat6_6.0.45+dfsg-1~deb7u5.debian.tar.gz
 6169df3d19febdee57eb9579c620e76deb2811a3 58646 
tomcat6-common_6.0.45+dfsg-1~deb7u5_all.deb
 3f09d1ae746086141c97e516dd64d8bb79c37ffa 52280 
tomcat6_6.0.45+dfsg-1~deb7u5_all.deb
 ab08dc251017dab93f6399b92fda735dc946ca92 41936 
tomcat6-user_6.0.45+dfsg-1~deb7u5_all.deb
 7c8d5037a55da4d76d4554ab219d546ef5eb6eed 3167156 
libtomcat6-java_6.0.45+dfsg-1~deb7u5_all.deb
 98d942982604bfcfa62e4ba31efdb5ad09c3c556 15844 
libservlet2.4-java_6.0.45+dfsg-1~deb7u5_all.deb
 99e97308395aebaa880342a8536332e3fa110ffe 242240 
libservlet2.5-java_6.0.45+dfsg-1~deb7u5_all.deb
 7d0293b673db2b4421d4223c5faa309600205043 274070 
libservlet2.5-java-doc_6.0.45+dfsg-1~deb7u5_all.deb
 b52432450374f6080cd4ec7c4539056e5a47cd0e 51418 
tomcat6-admin_6.0.45+dfsg-1~deb7u5_all.deb
 2fcfd1bc0cc58c844e65e2494cc7aca792cc41a1 166398 
tomcat6-examples_6.0.45+dfsg-1~deb7u5_all.deb
 dbd3559a3c13515fec8c37504da0a0e50585c78d 605218 
tomcat6-docs_6.0.45+dfsg-1~deb7u5_all.deb
 1d469f13d55f5f8cbefabc3e38c25234191c3cc0 16066 
tomcat6-extras_6.0.45+dfsg-1~deb7u5_all.deb
Checksums-Sha256: 
 78fe4ee55dc103baff014276987cdd4ca3933cb30f94154fe7d5ffbf3ff0b34d 2905 
tomcat6_6.0.45+dfsg-1~deb7u5.dsc
 b6b70131919bdb0870d0b97aef11b3567ef3fe8cd63ba76ab7c643e5214122f2 60525 
tomcat6_6.0.45+dfsg-1~deb7u5.debian.tar.gz
 052eff666a75ca1ec597f80529dc9b0178b9dee7ba5d1f081cbdb802688c2deb 58646 
tomcat6-common_6.0.45+dfsg-1~deb7u5_all.deb
 63d1e796868318832b6529c2bc650c7a17d789c106a5ad10ec0125d3dea6fd64 52280 
tomcat6_6.0.45+dfsg-1~deb7u5_all.deb
 57d609f497883645bae86771432640a2de09fecf4b67dc27aef8134640085585 41936 
tomcat6-user_6.0.45+dfsg-1~deb7u5_all.deb
 9caa3b4473b3212a8e761a8892622165031703006a73537104eb407193bb9c23 3167156 
libtomcat6-java_6.0.45+dfsg-1~deb7u5_all.deb
 0f68d603b18db5f86f969fe3bd7461ffa331303532d0825077d739e0965a5204 15844 
libservlet2.4-java_6.0.45+dfsg-1~deb7u5_all.deb
 2f103c79444df05710bf9ef1726389cbe47a6032acb5c2e9a23a0746eee5af04 242240 
libservlet2.5-java_6.0.45+dfsg-1~deb7u5_all.deb
 0e2331ecff6ed1e5f36dbff55f261133dbfd68fa3ef0ac28f48199dd97248f6d 274070 
libservlet2.5-java-doc_6.0.45+dfsg-1~deb7u5_all.deb
 372080b74692f6edaa72d05faa749ffeffba143952aad785e39541cae6dec5fc 51418 
tomcat6-admin_6.0.45+dfsg-1~deb7u5_all.deb
 e19d801c883159e243c6c22e17f2451c9a10a254cb6988688d910c5e9d10c14e 166398 
tomcat6-examples_6.0.45+dfsg-1~deb7u5_all.deb
 66320ca413df67f96fe38bd313e394dabc76279b309d45ebbf9d95521bbae8b6 605218 
tomcat6-docs_6.0.45+dfsg-1~deb7u5_all.deb
 3a88e9b912559436b7732aac5d113b5caa9031390e567698eac14c88365b4532 16066 
tomcat6-extras_6.0.45+dfsg-1~deb7u5_all.deb
Files: 
 5b30653753f3a528a044c479138e593b 2905 java optional 
tomcat6_6.0.45+dfsg-1~deb7u5.dsc
 8b726b85f09e040d69040d54f2c7e4a3 60525 java optional 
tomcat6_6.0.45+dfsg-1~deb7u5.debian.tar.gz
 5bf8271b2e13f3b10e02c4fe594ecc11 58646 java optional 
tomcat6-common_6.0.45+dfsg-1~deb7u5_all.deb
 f1ddbb4b57711b4e22ca49d82137d436 52280 java optional 
tomcat6_6.0.45+dfsg-1~deb7u5_all.deb
 83ad6f9f361cdd273ae43c4784a11f64 41936 java optional 
tomcat6-user_6.0.45+dfsg-1~deb7u5_all.deb
 7a5514b36f237a680ad3de00094bb4a2 3167156 java optional 
libtomcat6-java_6.0.45+dfsg-1~deb7u5_all.deb
 6ad8bf2a6a44b22c89fa488ef8bf7186 15844 oldlibs extra 
libservlet2.4-java_6.0.45+dfsg-1~deb7u5_all.deb
 4392e2b6783ef8612c7cf0c73b4f2ba4 242240 java optional 
libservlet2.5-java_6.0.45+dfsg-1~deb7u5_all.deb
 473c83f65ad0a2c420e362b366cc6619 274070 doc 

[SECURITY] [DLA 752-1] icedove security update

[Guido Günther]

Package: icedove
Version: 45.5.1-1~deb7u1
CVE ID : CVE-2016-5290 CVE-2016-5291 CVE-2016-5296 CVE-2016-5297 
 CVE-2016-9066 CVE-2016-9074 CVE-2016-9079

Multiple security issues have been found in Icedove, Debian's version of
the Mozilla Thunderbird mail client: Multiple memory safety errors,
same-origin policy bypass issues, integer overflows, buffer overflows
and use-after-frees may lead to the execution of arbitrary code or
denial of service.

For Debian 7 "Wheezy", these problems have been fixed in version
45.5.1-1~deb7u1.

We recommend that you upgrade your icedove 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

Wheezy update of python-bottle?

[Markus Koschany]

Hello dear maintainer(s),

the Debian LTS team would like to fix the security issues which are
currently open in the Wheezy version of python-bottle:
https://security-tracker.debian.org/tracker/CVE-2016-9964

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.

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 python-bottle updates
for the LTS releases.

Thank you very much.

Markus Koschany,
  on behalf of the Debian LTS team.

PS: A member of the LTS team might start working on this update at
any point in time. You can verify whether someone is registered
on this update in this file:
https://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?view=markup

Re: unrealize mechanism in 9pfs

[Guido Günther]

On Sat, Dec 17, 2016 at 10:29:57AM +0100, Hugo Lefeuvre wrote:
> Hi,
> 
> I'm currently finishing my upload for qemu, and a question is
> remaining concerning the fix of CVE-2016-99{14,15,16}[0,1,2].
> 
> It is clear to me that the 9pfs proxy/handle backend drivers may
> issue a memory leakage when unrealized (ctx->private not deallocated

We don't have virtfs-proxy-helper in wheezy so I think we don't need
support the "proxy" case.

As for "handle" did you check that it works in Wheezy including unplug?
If so please let me know and we can have a closer look.

I've only used "local" so far which does not seem to be affected by the
CVEs.
Cheers,
 -- Gudio

> for example). Thus, if they can be unrealized, we will need to
> implement a cleanup mechanism, as proposed in the upstream patch[3,4].
> 
> In recent versions following the QOM model, the unrealize operation
> is implemented in 9p.c. It is not the case in the wheezy version,
> for which I can't find any function performing unrealize operations[5]
> (the current unrealize function got implemented in this commit[6]).
> 
> So, I am having trouble defining whether it is possible to unrealize the
> 9pfs device in the wheezy version, and if yes, which method (if there's
> one) is handling it.
> 
> Does anybody have an idea ?
> 
> Cheers,
>  Hugo
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2016-9914
> [1] https://security-tracker.debian.org/tracker/CVE-2016-9915
> [2] https://security-tracker.debian.org/tracker/CVE-2016-9916
> [3] 
> http://git.qemu.org/?p=qemu.git;a=commit;h=971f406b77a6eb84e0ad27dcc416b663765aee30
> [4] 
> http://git.qemu.org/?p=qemu.git;a=commit;h=898ae90a44551d25b8e956fd87372d303c82fe68
> [5] For the record, the equivalent in wheezy of the modern realize function is
> virtio_9p_init in virtio-9p-device.c.
> [6] 
> http://git.qemu.org/?p=qemu.git;a=commit;h=6cecf093735f2e5af7d0e29d957350320044e354
> 
> -- 
>  Hugo Lefeuvre (hle)|www.owl.eu.com
> 4096/ ACB7 B67F 197F 9B32 1533 431C AC90 AC3E C524 065E

unrealize mechanism in 9pfs

[Hugo Lefeuvre]

Hi,

I'm currently finishing my upload for qemu, and a question is
remaining concerning the fix of CVE-2016-99{14,15,16}[0,1,2].

It is clear to me that the 9pfs proxy/handle backend drivers may
issue a memory leakage when unrealized (ctx->private not deallocated
for example). Thus, if they can be unrealized, we will need to
implement a cleanup mechanism, as proposed in the upstream patch[3,4].

In recent versions following the QOM model, the unrealize operation
is implemented in 9p.c. It is not the case in the wheezy version,
for which I can't find any function performing unrealize operations[5]
(the current unrealize function got implemented in this commit[6]).

So, I am having trouble defining whether it is possible to unrealize the
9pfs device in the wheezy version, and if yes, which method (if there's
one) is handling it.

Does anybody have an idea ?

Cheers,
 Hugo

[0] https://security-tracker.debian.org/tracker/CVE-2016-9914
[1] https://security-tracker.debian.org/tracker/CVE-2016-9915
[2] https://security-tracker.debian.org/tracker/CVE-2016-9916
[3] 
http://git.qemu.org/?p=qemu.git;a=commit;h=971f406b77a6eb84e0ad27dcc416b663765aee30
[4] 
http://git.qemu.org/?p=qemu.git;a=commit;h=898ae90a44551d25b8e956fd87372d303c82fe68
[5] For the record, the equivalent in wheezy of the modern realize function is
virtio_9p_init in virtio-9p-device.c.
[6] 
http://git.qemu.org/?p=qemu.git;a=commit;h=6cecf093735f2e5af7d0e29d957350320044e354

-- 
 Hugo Lefeuvre (hle)|www.owl.eu.com
4096/ ACB7 B67F 197F 9B32 1533 431C AC90 AC3E C524 065E


signature.asc
Description: PGP signature