Wheezy update of libsys-syslog-perl?

2016-08-02 Thread Jonas Meurer 
Hello dear maintainer(s),

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

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.

Thank you very much.

Jonas Meurer,
  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

PPS: Dominic Hargreaves of the pkg-perl team already uploaded a fixed
libsys-syslog-perl 0.33 to jessie-security. The fix is simple and can be
overtaken for 0.29 in wheezy. I have already prepared packages. So if
you don't object, I could do the upload.




signature.asc
Description: OpenPGP digital signature

Re: Bug#832908: mongodb: CVE-2016-6494: world-readable .dbshell history file: LTS update and upgrade handling

2016-08-02 Thread Roberto C . Sánchez 
On Wed, Aug 03, 2016 at 12:25:32AM +0200, Ola Lundqvist wrote:
>Hi
>Maybe. However if someone is added to a users group that should really
>mean that they should at least be able to read things, even though they
>may not be able to write to stuff. So I actually think bash and others do
>the wrong thing here.
>The way I have done it is also more in line with upstream opinion, even
>though upstream think it is ok for even anyone to read this file.
>New simplified and with better comments attached to this mail.
>Best regards

There is likely a reasonable difference between files like .bash_history
(which are meant to be used/accessed only by the creating user) and
files which are possibly or likely to be shared amongst a group of
users.  This case seems to be of the latter form.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: Bug#832908: mongodb: CVE-2016-6494: world-readable .dbshell history file: LTS update and upgrade handling

2016-08-02 Thread Ola Lundqvist 
Hi

Maybe. However if someone is added to a users group that should really mean
that they should at least be able to read things, even though they may not
be able to write to stuff. So I actually think bash and others do the wrong
thing here.

The way I have done it is also more in line with upstream opinion, even
though upstream think it is ok for even anyone to read this file.

New simplified and with better comments attached to this mail.

Best regards

// Ola

On Wed, Aug 3, 2016 at 12:16 AM, Emilio Pozuelo Monfort 
wrote:

> 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
>
>


-- 
 --- 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  /
 ---
Description: World readable dbshell log file
 This correction make sure the ~/.dbshell log file is not world readable.
 .
 mongodb (1:2.0.6-1+deb7u1) wheezy-security; urgency=high
 .
   * Non-maintainer upload by the Long Term Security Team.
   * Make sure dbshell log file is not readable by others
 CVE-2016-6494 (Closes: #832908).
Author: Ola Lundqvist 
Origin: other
Bug: https://jira.mongodb.org/browse/SERVER-25335
Bug-Debian: https://bugs.debian.org/832908
Forwarded: no
Reviewed-By: Ola Lundqvist 
Last-Update: 2016-08-01

Index: mongodb-2.0.6/third_party/linenoise/linenoise.cpp
===
--- mongodb-2.0.6.orig/third_party/linenoise/linenoise.cpp	2012-06-04 13:42:54.0 +
+++ mongodb-2.0.6/third_party/linenoise/linenoise.cpp	2016-08-02 22:28:13.094657162 +
@@ -104,11 +104,13 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -799,6 +801,11 @@
 /* Save the history in the specified file. On success 0 is returned
  * otherwise -1 is returned. */
 int linenoiseHistorySave(const char *filename) {
+mode_t prev_mask = umask(0022);
+// Make sure this file is not readable by others, but honor
+// the umask for user and group permissions.
+// CVE-2016-6494
+umask(prev_mask | S_IRWXO);
 FILE *fp = fopen(filename,"w");
 int j;
 
@@ -808,6 +815,8 @@
 fprintf(fp,"%s\n",history[j]);
 }
 fclose(fp);
+// return umask as it was before
+umask(prev_mask);
 return 0;
 }
 
@@ -817,6 +826,15 @@
  * If the file exists and the operation succeeded 0 is returned, otherwise
  * on error -1 is returned. */
 int linenoiseHistoryLoad(const char *filename) {
+struct stat fileStat;
+if (stat(filename,&fileStat) < 0) return -1;
+if (fileStat.st_mode & S_IRWXO) {
+  // If the file is world readable, writeable or executable
+  // make sure it is not but keep all other permissions.
+  // CVE-2016-6494
+  chmod(filename, fileStat.st_mode & 070);
+}
+
 FILE *fp = fopen(filename,"r");
 char buf[LINENOISE_MAX_LINE];

Re: Bug#832908: mongodb: CVE-2016-6494: world-readable .dbshell history file: LTS update and upgrade handling

2016-08-02 Thread Emilio Pozuelo Monfort 
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

Re: Bug#832908: mongodb: CVE-2016-6494: world-readable .dbshell history file: LTS update and upgrade handling

2016-08-02 Thread Ola Lundqvist 
Hi Chris

I had this
// Make sure this file is not readable by others

But maybe it was not clear enough. :-)

// Ola

On Wed, Aug 3, 2016 at 12:00 AM, Chris Lamb  wrote:

> > This is why I just override the "world readable" part and
> > let the rest be controlled by the user.
>
> Ah, didn't quite spot you are overriding just this bit. Worth a comment
> I think.
>
> > 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.
>
> Well, sure, of course. :)
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>



-- 
 --- 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  /
 ---

Re: Bug#832908: mongodb: CVE-2016-6494: world-readable .dbshell history file: LTS update and upgrade handling

2016-08-02 Thread Chris Lamb 
> This is why I just override the "world readable" part and
> let the rest be controlled by the user.

Ah, didn't quite spot you are overriding just this bit. Worth a comment
I think.

> 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.

Well, sure, of course. :)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Re: Bug#832908: mongodb: CVE-2016-6494: world-readable .dbshell history file: LTS update and upgrade handling

2016-08-02 Thread Ola Lundqvist 
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?

Best regards

// Ola

On Tue, Aug 2, 2016 at 7:14 PM, Chris Lamb  wrote:

> > Here is the working patch (attached).
>
> Out of interest, why:
>
> +mode_t prev_mask = umask(0022);
> +// Make sure this file is not readable by others
> +umask(prev_mask | S_IROTH | S_IWOTH | S_IXOTH);
>  FILE *fp = fopen(filename,"w");
>
> .. over, say:
>
> +// Make sure this file is not readable by others
> +mode_t prev_mask = umask(S_IXUSR|S_IRWXG|S_IRWXO);
>  FILE *fp = fopen(filename,"w");
> +umask(prev_mask);
>
> We don't really want to change the umask for the entire process.
> Or at least, we don't know the ramifications of that so better to
> keep it isolated to just this bit?
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>



-- 
 --- 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  /
 ---

Re: Wheezy update of libupnp?

2016-08-02 Thread Balint Reczey 
On 07/26/2016 10:51 PM, Bálint Réczey wrote:
> Hi Nick,
> 
> 2016-07-19 15:35 GMT+02:00 Nick Leverton :
>> On Tue, Jul 19, 2016 at 08:54:18AM +0200, Chris Lamb 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 libupnp:
>>> https://security-tracker.debian.org/tracker/TEMP-000-867096
>>>
>>> Would you like to take care of this yourself?
>>
>> Hi,
>>
>> Thanks very much for the headsup on this.  I've a bit to do for Squeeze
>> at the moment and would really appreciate any help your team can provide
>> on LTS.  If I do get enough time though I'll check in on your task
>> tracker as suggested.
> 
> I will prepare a fix for Wheezy tomorrow.

It took some more time but I also reported the problem upstream in their
public bug tracker:
https://sourceforge.net/p/pupnp/bugs/132/

Please see the attached patch which I will upload in a few days if
upstream does not react.

The binary packages for amd64 are also available for testing here:
https://people.debian.org/~rbalint/ppa/wheezy-lts/wheezy-security/

Cheers,
Balint

diff -Nru libupnp-1.6.17/debian/changelog libupnp-1.6.17/debian/changelog
--- libupnp-1.6.17/debian/changelog	2013-02-01 21:56:14.0 +0100
+++ libupnp-1.6.17/debian/changelog	2016-07-27 19:05:24.0 +0200
@@ -1,3 +1,12 @@
+libupnp (1:1.6.17-1.2+deb7u1) wheezy-security; urgency=medium
+
+  * Non-maintainer upload by the LTS Team
+  * Don't allow unhandled POSTs to write to the filesystem by
+default (Closes: #831857) (CVE-2016-6255)
+Thanks to Matthew Garrett for the patch.
+
+ -- Balint Reczey   Wed, 27 Jul 2016 19:01:31 +0200
+
 libupnp (1:1.6.17-1.2) unstable; urgency=high
 
   * Non-maintainer upload by the Security Team.
diff -Nru libupnp-1.6.17/debian/patches/0002-Don-t-allow-unhandled-POSTs-to-write-to-the-filesyst.patch libupnp-1.6.17/debian/patches/0002-Don-t-allow-unhandled-POSTs-to-write-to-the-filesyst.patch
--- libupnp-1.6.17/debian/patches/0002-Don-t-allow-unhandled-POSTs-to-write-to-the-filesyst.patch	1970-01-01 01:00:00.0 +0100
+++ libupnp-1.6.17/debian/patches/0002-Don-t-allow-unhandled-POSTs-to-write-to-the-filesyst.patch	2016-07-27 19:01:19.0 +0200
@@ -0,0 +1,59 @@
+From be0a01bdb83395d9f3a5ea09c1308a4f1a972cbd Mon Sep 17 00:00:00 2001
+From: Matthew Garrett 
+Date: Tue, 23 Feb 2016 13:53:20 -0800
+Subject: [PATCH] Don't allow unhandled POSTs to write to the filesystem by
+ default
+
+If there's no registered handler for a POST request, the default behaviour
+is to write it to the filesystem. Several million deployed devices appear
+to have this behaviour, making it possible to (at least) store arbitrary
+data on them. Add a configure option that enables this behaviour, and change
+the default to just drop POSTs that aren't directly handled.
+---
+ configure.ac | 4 
+ upnp/inc/upnpconfig.h.in | 5 +
+ upnp/src/genlib/net/http/webserver.c | 4 
+ 3 files changed, 13 insertions(+)
+
+--- a/configure.ac
 b/configure.ac
+@@ -452,6 +452,10 @@
+ AC_DEFINE(UPNP_ENABLE_BLOCKING_TCP_CONNECTIONS, 1, [see upnpconfig.h])
+ fi
+ 
++RT_BOOL_ARG_ENABLE([postwrite], [no], [write to the filesystem on otherwise unhandled POST requests])
++if test "x$enable_postwrite" = xyes ; then
++AC_DEFINE(UPNP_ENABLE_POST_WRITE, 1, [see upnpconfig.h])
++fi
+ 
+ RT_BOOL_ARG_ENABLE([samples], [yes], [compilation of upnp/sample/ code])
+ 
+--- a/upnp/inc/upnpconfig.h.in
 b/upnp/inc/upnpconfig.h.in
+@@ -131,5 +131,10 @@
+  * header (i.e. configure --enable-unspecified_server) */
+ #undef UPNP_ENABLE_UNSPECIFIED_SERVER
+ 
++/** Defined to 1 if the library has been compiled to support filesystem writes on POST
++ *  (i.e. configure --enable-postwrite) */
++#undef UPNP_ENABLE_POST_WRITE
++
++
+ #endif /* UPNP_CONFIG_H */
+ 
+--- a/upnp/src/genlib/net/http/webserver.c
 b/upnp/src/genlib/net/http/webserver.c
+@@ -1354,9 +1354,13 @@
+ 		if (Fp == NULL)
+ 			return HTTP_INTERNAL_SERVER_ERROR;
+ 	} else {
++#ifdef UPNP_ENABLE_POST_WRITE
+ 		Fp = fopen(filename, "wb");
+ 		if (Fp == NULL)
+ 			return HTTP_UNAUTHORIZED;
++#else
++		return HTTP_NOT_FOUND;
++#endif
+ 	}
+ 	parser->position = POS_ENTITY;
+ 	do {
diff -Nru libupnp-1.6.17/debian/patches/series libupnp-1.6.17/debian/patches/series
--- libupnp-1.6.17/debian/patches/series	2013-02-01 18:36:23.0 +0100
+++ libupnp-1.6.17/debian/patches/series	2016-07-27 19:00:56.0 +0200
@@ -4,3 +4,4 @@
 12-debian-always-debug.patch
 18-url-upnpstrings.patch
 0001-Security-fix-for-CERT-issue-VU-922681.branch-1.6.patch
+0002-Don-t-allow-unhandled-POSTs-to-write-to-the-filesyst.patch

Re: Redis not uploaded and timely security announcements

2016-08-02 Thread Emilio Pozuelo Monfort 
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: Icedtea plugin

2016-08-02 Thread Emilio Pozuelo Monfort 
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

2016-08-02 Thread Chris Lamb 
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.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Re: Bug#832908: mongodb: CVE-2016-6494: world-readable .dbshell history file: LTS update and upgrade handling

2016-08-02 Thread Chris Lamb 
> Here is the working patch (attached).

Out of interest, why:

+mode_t prev_mask = umask(0022);
+// Make sure this file is not readable by others
+umask(prev_mask | S_IROTH | S_IWOTH | S_IXOTH);
 FILE *fp = fopen(filename,"w");

.. over, say:

+// Make sure this file is not readable by others
+mode_t prev_mask = umask(S_IXUSR|S_IRWXG|S_IRWXO);
 FILE *fp = fopen(filename,"w");
+umask(prev_mask);

We don't really want to change the umask for the entire process.
Or at least, we don't know the ramifications of that so better to
keep it isolated to just this bit?


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Re: Bug#832908: mongodb: CVE-2016-6494: world-readable .dbshell history file: LTS update and upgrade handling

2016-08-02 Thread Ola Lundqvist 
Hi again

Here is the working patch (attached).

Hope it helps for later versions too.

// Ola

On Tue, Aug 2, 2016 at 12:15 AM, Ola Lundqvist  wrote:

> Hi again
>
> I just realize that we need to change back the umask after the file is
> created. I'll update the patch tomorrow and send one that I know works.
>
> // Ola
>
> On Tue, Aug 2, 2016 at 12:13 AM, Ola Lundqvist  wrote:
>
>> Hi all
>>
>> I have prepared a preliminary patch for wheezy. I have not yet been able
>> to test it fully (it is building right now). It looks like attached. You
>> may need to modify it for later versions.
>>
>> Please comment. The principles should be ok even if I may have made some
>> stupid copy+paste mistake. It worked fine in a little test program I made.
>>
>> Hope this helps
>>
>> // Ola
>>
>> On Mon, Aug 1, 2016 at 5:53 AM, Chris Lamb  wrote:
>>
>>> > 2) How do you plan to handle the "upgrade case" that is will you try to
>>> > change the permission on already created history file or will you just
>>> > handle the creation case?
>>>
>>> For redis, what I did was set and then unset the umask (for creation) and
>>> chmod(2) the file afterwards to "upgrade" existing ones.
>>>
>>> I don't recommend a postinst approach (ie. chmod 0600 /home/*/.filename)
>>> for
>>> various reasons.
>>>
>>>
>>> Regards,
>>>
>>> --
>>>   ,''`.
>>>  : :'  : Chris Lamb
>>>  `. `'`  la...@debian.org / chris-lamb.co.uk
>>>`-
>>>
>>
>>
>>
>> --
>>  --- 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  /
>>  ---
>>
>>
>
>
> --
>  --- 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  /
>  ---
>
>


-- 
 --- 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  /
 ---
Description: World readable dbshell log file
 This correction make sure the ~/.dbshell log file is not world readable.
 .
 mongodb (1:2.0.6-1+deb7u1) wheezy-security; urgency=high
 .
   * Non-maintainer upload by the Long Term Security Team.
   * Make sure dbshell log file is not readable by others
 CVE-2016-6494 (Closes: #832908).
Author: Ola Lundqvist 
Origin: other
Bug: https://jira.mongodb.org/browse/SERVER-25335
Bug-Debian: https://bugs.debian.org/832908
Forwarded: no
Reviewed-By: Ola Lundqvist 
Last-Update: 2016-08-01

Index: mongodb-2.0.6/third_party/linenoise/linenoise.cpp
===
--- mongodb-2.0.6.orig/third_party/linenoise/linenoise.cpp	2016-08-01 22:10:07.318825853 +
+++ mongodb-2.0.6/third_party/linenoise/linenoise.cpp	2016-08-01 22:19:52.706824724 +
@@ -104,11 +104,13 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -799,6 +801,9 @@
 /* Save the history in the specified file. On success 0 is returned
  * otherwise -1 is returned. */
 int linenoiseHistorySave(const char *filename) {
+mode_t prev_mask = umask(0022);
+// Make sure this file is not readable by others
+umask(prev_mask | S_IROTH | S_IWOTH | S_IXOTH);
 FILE *fp = fopen(filename,"w");
 int j;
 
@@ -808,6 +813,7 @@
 fprintf(fp,"%s\n",history[j]);
 }
 fclose(fp);
+umask(prev_mask);
 return 0;
 }
 
@@ -817,6 +823,16 @@
  * If the file exists and the operation succeeded 0 is returned, otherwise
  * on error -1 is returned. */
 int linenoiseHistoryLoad(const char *filename) {
+struct stat fileStat;
+if (stat(filename,&fileStat) < 0) return -1;
+if (fileStat.st_mode & S_IROTH ||
+	fileStat.st_mode & S_IWOTH ||
+	fileStat.st_mode & S_IXOTH) {
+  // If the file is world readable, writeable or executable
+  // make sure it is not but keep all other permissions.
+  chmod(filename, fileStat.st_mode & 070);
+}
+
 FILE *fp = fopen(filename,"r");
 char buf[LINENOISE_MAX_LINE];

Re: Wheezy and jessie updates of lighttpd

2016-08-02 Thread Sébastien Delafond 
On Aug/02, Santiago R.R. wrote:
> .changes attached. security-master doesn't handle source-only uploads,
> isn't it?

No, in most cases it does not, so it's always better not to try it. Feel
free to upload to security-master, and I'll probably have time to
release the DSA tomorrow.

Cheers,

--Seb

Re: Wheezy and jessie updates of lighttpd

2016-08-02 Thread Santiago R.R. 
El 02/08/16 a las 10:11, Sébastien Delafond escribió:
> On Aug/01, Santiago R.R. wrote:
> > Please, find attached debdiffs to mitigate this in wheezy (that I plan
> > to upload) and jessie. I have tested it with a python cgi taken from
> > httpoxy's PoCs, and it seems to work well. However, I am not familiar
> > with lighttpd, so any review is welcome.
> 
> Hi Santiago,
> 
> thanks for working on this. Could you please change your jessie debdiff
> so it uses version 1.4.35-4+deb8u1 instead of 1.4.35-5 ? The rest looks
> OK.
> 

Oups! Fixed.

> You'll also need to make sure you build with -sa, as lighttpd will be
> new on security-master.

.changes attached. security-master doesn't handle source-only uploads,
isn't it?

For wheezy user, lighttpd test packages are available at:

  deb https://people.debian.org/~santiago/debian santiago-wheezy/
  deb-src https://people.debian.org/~santiago/debian santiago-wheezy/

Thanks,

Santiago
Format: 1.8
Date: Sun, 31 Jul 2016 20:57:24 +0200
Source: lighttpd
Binary: lighttpd lighttpd-doc lighttpd-mod-mysql-vhost 
lighttpd-mod-trigger-b4-dl lighttpd-mod-cml lighttpd-mod-magnet 
lighttpd-mod-webdav
Architecture: source amd64 all
Version: 1.4.35-4+deb8u1
Distribution: jessie-security
Urgency: medium
Maintainer: Debian lighttpd maintainers 

Changed-By: Santiago R.R. 
Description:
 lighttpd   - fast webserver with minimal memory footprint
 lighttpd-doc - documentation for lighttpd
 lighttpd-mod-cml - cache meta language module for lighttpd
 lighttpd-mod-magnet - control the request handling module for lighttpd
 lighttpd-mod-mysql-vhost - MySQL-based virtual host configuration for lighttpd
 lighttpd-mod-trigger-b4-dl - anti-deep-linking module for lighttpd
 lighttpd-mod-webdav - WebDAV module for lighttpd
Changes:
 lighttpd (1.4.35-4+deb8u1) jessie-security; urgency=medium
 .
   * Non-maintainer upload.
   * Fix CVE-2016-1000212: Mitigate HTTPoxy vulnerability.
   * Add mitigate-httpoxy-779c133c16f9af168b004dce7a2a64f16c1cb3a4.patch
Checksums-Sha1:
 71b880ac6738f55e6a0685f00244939ce857de28 1929 lighttpd_1.4.35-4+deb8u1.dsc
 90c22d55c9656494d772deb62e253aa35bb5221d 847321 lighttpd_1.4.35.orig.tar.gz
 bca8d5ff2a27d99624fc5ebe0237d08eba31238b 27380 
lighttpd_1.4.35-4+deb8u1.debian.tar.xz
 ea3a16570c70702f13e6139b8ced1ad7e304e139 245054 
lighttpd_1.4.35-4+deb8u1_amd64.deb
 3ab0e23dc3bb4443369ca244ea82a509df2b23f8 61394 
lighttpd-doc_1.4.35-4+deb8u1_all.deb
 eecace5ee43943e2f036dab62a4e01a5807898b5 19958 
lighttpd-mod-mysql-vhost_1.4.35-4+deb8u1_amd64.deb
 e90cfd2cd0465315f75f3f2809f7c819a43ba19d 20776 
lighttpd-mod-trigger-b4-dl_1.4.35-4+deb8u1_amd64.deb
 5b456baf03fcb151e4bfc9647ea041ee527802c0 23088 
lighttpd-mod-cml_1.4.35-4+deb8u1_amd64.deb
 1d106305a394d9324c74ea454e2a1dcc08bf3e85 24646 
lighttpd-mod-magnet_1.4.35-4+deb8u1_amd64.deb
 be572db784ec222fe1c33da9775e3bdf2fc002c4 30102 
lighttpd-mod-webdav_1.4.35-4+deb8u1_amd64.deb
Checksums-Sha256:
 ed42927602f5e59e976f96df34b4375b5d9d05d00551ff5350c06ea7dee53990 1929 
lighttpd_1.4.35-4+deb8u1.dsc
 62c23de053fd82e1bf64f204cb6c6e44ba3c16c01ff1e09da680d982802ef1cc 847321 
lighttpd_1.4.35.orig.tar.gz
 809f136773a28f3d3aad000b9bb74d2cb53e92da0d09e4bb246d755451d14db9 27380 
lighttpd_1.4.35-4+deb8u1.debian.tar.xz
 6f19013234e34977cb05f857421e8e1bc66a17b272eca71c582c0440172f6baf 245054 
lighttpd_1.4.35-4+deb8u1_amd64.deb
 29fbbf46264be0bb0c5cf32fa1e9d55bf614272fb1de521407be6f06cbe4e059 61394 
lighttpd-doc_1.4.35-4+deb8u1_all.deb
 1ce44aa301e1974eb0c4b50d409c63106ba8baccfd2b36fda91602ad295b3960 19958 
lighttpd-mod-mysql-vhost_1.4.35-4+deb8u1_amd64.deb
 45a05c88e23b3a8556068b4c60f0726e9afebecd935639907df542b3856a025a 20776 
lighttpd-mod-trigger-b4-dl_1.4.35-4+deb8u1_amd64.deb
 1d6541fa3af0ec414939b91827a65dd71f87896caf5d8f52194aac14e6183f0f 23088 
lighttpd-mod-cml_1.4.35-4+deb8u1_amd64.deb
 b739d657c7c997b1203a5b13eddaed34fa2af24fbb27980be372b29ce79c2017 24646 
lighttpd-mod-magnet_1.4.35-4+deb8u1_amd64.deb
 a1b734ccc4098d8062c65aeb03cf57da3f23f1ebc89914ec47173f80c0d42ddd 30102 
lighttpd-mod-webdav_1.4.35-4+deb8u1_amd64.deb
Files:
 733c5fd6fe344a29d06cc48bce7fead0 1929 httpd optional 
lighttpd_1.4.35-4+deb8u1.dsc
 69057685df672218d45809539b874917 847321 httpd optional 
lighttpd_1.4.35.orig.tar.gz
 d3e2a03dd80db575902ee96722b11598 27380 httpd optional 
lighttpd_1.4.35-4+deb8u1.debian.tar.xz
 ce497ebd3a8f1baa6aa119b36af3d4ea 245054 httpd optional 
lighttpd_1.4.35-4+deb8u1_amd64.deb
 46be0ace9166e17375c15b9860a0964b 61394 doc optional 
lighttpd-doc_1.4.35-4+deb8u1_all.deb
 6044e7f4079507ca13deb3091cf4b61b 19958 httpd optional 
lighttpd-mod-mysql-vhost_1.4.35-4+deb8u1_amd64.deb
 ccf6d8a31d235239ad0e8440e46d996a 20776 httpd optional 
lighttpd-mod-trigger-b4-dl_1.4.35-4+deb8u1_amd64.deb
 aaa81298e8f9c929ddd470c067bbb81f 23088 httpd optional 
lighttpd-mod-cml_1.4.35-4+deb8u1_amd64.deb
 385be1550836e0157ba40ef82c94927d 24646 httpd optional 
lighttpd-mod-magnet_1.4.35-4+deb8u1_amd64.deb
 8346d52de822696d20506619b577c1ca 30102 httpd optional 
light

Re: Wheezy and jessie updates of lighttpd

2016-08-02 Thread Sébastien Delafond 
On Aug/01, Santiago R.R. wrote:
> Please, find attached debdiffs to mitigate this in wheezy (that I plan
> to upload) and jessie. I have tested it with a python cgi taken from
> httpoxy's PoCs, and it seems to work well. However, I am not familiar
> with lighttpd, so any review is welcome.

Hi Santiago,

thanks for working on this. Could you please change your jessie debdiff
so it uses version 1.4.35-4+deb8u1 instead of 1.4.35-5 ? The rest looks
OK.

You'll also need to make sure you build with -sa, as lighttpd will be
new on security-master.

Cheers,

--Seb