
Debian Security Advisory: nginx security update - marksamman
https://www.debian.org/security/2016/dsa-3701
======
LukeShu
From the linked CVE page:

    
    
        Notes:
    
          Issue introduced with the Debian specific fix for CVE-2013-0337 / #701112
    

So Nginx users on non-Debian-based systems don't need to worry.

~~~
vog
It's not the first time that Debian-specific patches introduce large issues.
The most prominent failure was the deeply flawed SSH key generation of the
Debian-modified OpenSSH.

This is a general problem, that almost inevitably happens if patches are
developed by (non-upstream) people who do not have an intimate knowledge of
the code.

What's worse in the case of Debian and other distros is that they have no
incentive to coordinate their patches with upstream. In particular, they do
not need to convince upstream for inclusion. This is quite risky from a Q/A
point of view.

I wonder when this issue will appear in enterprise distros (RHEL, SLES, etc.)
as well, where the situation is even worse. These distros try to support
package versions which are way older than Debian/Stable ever got, backporting
patches to versions which aren't even interesting to upstream anymore, so they
couldn't receive good feedback from upstream even if they suddenly decided to
care about upstream's opinion.

~~~
avian
> What's worse in the case of Debian and other distros is that they have no
> incentive to coordinate their patches with upstream.

They do have an incentive: patches against upstream need to be maintained.
Maintainer has much less work if any patches are included upstream.

I can't speak for other distros, but in my experience many Debian maintainers
will strongly oppose including distro-specific patches in their packages
without a very good reason.

~~~
vog
_> They do have an incentive: patches against upstream need to be maintained_

You are right. However, this only means they have an incentive to push patches
to upstream _in hindsight_. That's is better than nothing, but still happens
after the fact, when the damage is done and the defect distributed to the
users.

As far as I know, they have no incentive to _wait_ for their patches to be
included in upstream.

 _> many [...] maintainers will strongly oppose including distro-specific
patches in their packages without a very good reason._

Well, fixing security issues is often seen as a "very good reason", completely
ignoring that an incomplete and/or errorneous security fix may do more harm
than good, and meanwhile provides the users with a false sense of security.

~~~
feld
This is precisely why I'm against the Linux style "freeze software at version
X" methodology.

~~~
chme
What does the kernel has to do with this?

That is an issue some distributions introduced and they have to deal with it
or you should choose one that does a rolling release.

------
marksamman
nginx-common (1.6.2-5+deb8u3) jessie-security; urgency=high

    
    
      In order to secure nginx against privilege escalation attacks, we are
      changing the way log file owners & permissions are handled so that www-data
      is not allowed to symlink a logfile. /var/log/nginx is now owned by root:adm
      and its permissions are changed to 0755. The package checks for such symlinks
      on existing installations and informs the admin using debconf.
    
      That unfortunately may come at a cost in terms of privacy. /var/log/nginx is
      now world-readable, and nginx hardcodes permissions of non-existing logs to
      0644. On systems running logrotate log files are private after the first
      logrotate run, since the new log files are created with 0640 permissions.
    
     -- Christos Trochalakis <yatiohi@ideopolis.gr>  Tue, 04 Oct 2016 15:20:33 +0300

~~~
3pt14159
Yikes this is pretty bad. Many log files (wrongly) include things like form
fields including passwords and auth tokens.

~~~
0x0
If you have www-data access you can probably grab those from memory. This
vulnerability is about escalating to root. But if all your juicy data is
already available to / passing through your nginx, then this patch isn't doing
much to improve your situation.

~~~
therein
Except one requires the attacker to read from the processes memory in an
organized way for an extended amount of time to snoop data while the other
just puts its conveniently onto your disk.

------
0x0
Why is this suddenly an issue compared to how apache logs? (Why does the
directory need to be world readable?)

------
antocv
So this seems to be the old "local user www-data makes a symlink in
/var/log/nginx/access.log pointing to /sbin/give_me_root_on_open_by_root.sh"
and nginx when it starts up is running as root and opens that file, and then
root?

------
avodonosov
What command should I run manually?

~~~
akerro
Just setup daily unattended security updates.

~~~
kiallmacinnes
For 99% of fixes, though I'm unsure about the specifics of this one, just
having unattended upgrades enabled will do little/nothing to protect you.

Installing the upgraded package often won't restart the service, meaning
you're still running old code, and in the case of libraries, won't restart
every process on the system that has loaded the library, meaning you're still
running old code...

~~~
kikoreis
Hey, Ubuntu/Debian contributor here. Actually, 99% is misrepresenting it. Any
[well-packaged] service upgraded through unattended-upgrades (nginx included)
gets restarted through package hooks. What unattended-upgrades won't help with
are:

    
    
      1. Updates to the kernel
      2. Updates to system libraries which services depend on
    

For 1, if you run Ubuntu you now have canonical-livepatch:
[http://blog.dustinkirkland.com/2016/10/canonical-
livepatch.h...](http://blog.dustinkirkland.com/2016/10/canonical-
livepatch.html)

2 remains a problem, and yes, if you're thinking openssl, that's a problem.
But you can track what goes into /var/run/reboot-required.pkgs to see it's
really not 99% of fixes we're streaming to you.

See [http://askubuntu.com/questions/775504/does-unattended-
upgrad...](http://askubuntu.com/questions/775504/does-unattended-upgrades-
restart-services-automatically/) for a more complete discussion.

------
danielvf
Is Ubuntu affected?

~~~
masterleep
yes:

[https://launchpad.net/ubuntu/+source/nginx/1.10.0-0ubuntu0.1...](https://launchpad.net/ubuntu/+source/nginx/1.10.0-0ubuntu0.16.04.3)

------
benevol
Does anybody have a better source than CVEdetails.com?

They still don't have that vulnerability listed [0], which means their RSS
feeds are of limited value.

[0] [http://www.cvedetails.com/vulnerability-
list/vendor_id-10048...](http://www.cvedetails.com/vulnerability-
list/vendor_id-10048/product_id-17956/Nginx-Nginx.html)

~~~
kiallmacinnes
[http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2016-1247](http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2016-1247)

Note: cvedetails explicitly says it does not show "Rejected or reserved CVE
entries", and so shouldn't yet be showing this CVE.

------
hsivonen
What are the benefits of using Debian's package for nginx instead of using one
from nginx.org's apt repo?

------
torbjorn
So if you have nginx 1.7 or higher you're ok?

~~~
antod
Not if you're on Debian or Ubuntu.

Others were never affected.

------
qwertyuiop924
Sheesh. First OSSL and now this. What is with this week?

~~~
duskwuff
Nothing. You're finding patterns where they don't exist.

Both of those vulnerabilities are trivial. The OpenSSL vulnerability is a very
weak, non-persistent denial of service, and this nginx vulnerability requires
an attacker to already have code execution on the machine.

~~~
qwertyuiop924
Yeah, I guess, I just rarely see this many privescs. Am I not looking in the
right places?

~~~
wildparrot
You can subscribe to your favorite distro's security announce mailing list. In
the case of Debian, you can reference their latest security announcements
here:

[https://www.debian.org/security/](https://www.debian.org/security/)

