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
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.
Thanks all. I meant if I want to secure nginx without apt update/upgrade. They say to change some access rights - would be nice to have commands to copy/paste.
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
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.
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.
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.
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:
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?
33 comments
[ 3.8 ms ] story [ 84.1 ms ] threadhttps://launchpad.net/ubuntu/+source/nginx/1.10.0-0ubuntu0.1...
https://wiki.debian.org/UnattendedUpgrades
sudo apt-get install --only-upgrade <package_name>
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...
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.
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.
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.
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.
That is an issue some distributions introduced and they have to deal with it or you should choose one that does a rolling release.
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.
https://www.debian.org/security/
Others were never affected.
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...
Note: cvedetails explicitly says it does not show "Rejected or reserved CVE entries", and so shouldn't yet be showing this CVE.