Debian Security Advisory: nginx security update | Hacker News Reader

Debian Security Advisory: nginx security update

debian.org

84 pointsmarksamman32 comments

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.

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.

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

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

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

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.

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

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

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.

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.

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

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?

What command should I run manually?

Just setup daily unattended security updates.

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

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

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... for a more complete discussion.

sudo apt upgrade

You forgot to update first

Indeed (s)he did:

  sudo apt update
  sudo apt upgrade