8 ms·

Debian Security Advisory: nginx security update

84 points by marksamman 10y ago

marksamman 10y ago
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 10y ago
  Yikes this is pretty bad. Many log files (wrongly) include things like form fields including passwords and auth tokens.
  - 0x0 10y ago
    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 10y ago
      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.
danielvf 10y ago
Is Ubuntu affected?
- masterleep 10y ago
  yes: https://launchpad.net/ubuntu/+source/nginx/1.10.0-0ubuntu0.16.04.3 https://launchpad.net/ubuntu/+source/nginx/1.10.0-0ubuntu0.1...
avodonosov 10y ago
What command should I run manually?
- torbjorn 10y ago
  sudo apt upgrade
  - brianwawok 10y ago
    You forgot to update first
    - e12e 10y ago
      Indeed (s)he did: sudo apt update sudo apt upgrade See also: https://wiki.debian.org/UnattendedUpgrades https://wiki.debian.org/UnattendedUpgrades
      - avodonosov 10y ago
        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.
      - deleted 10y ago
        [deleted]
    - benevol 10y ago
      If you want to update a specific package only: sudo apt-get install --only-upgrade <package_name>
- akerro 10y ago
  Just setup daily unattended security updates.
  - kiallmacinnes 10y ago
    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...
0x0 10y ago
Why is this suddenly an issue compared to how apache logs? (Why does the directory need to be world readable?)
LukeShu 10y ago
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 10y ago
  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 10y ago
    > 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 10y ago
      > 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.
qwertyuiop924 10y ago
Sheesh. First OSSL and now this. What is with this week?
- duskwuff 10y ago
  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 10y ago
    Yeah, I guess, I just rarely see this many privescs. Am I not looking in the right places?
    - wildparrot 10y ago
      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/
torbjorn 10y ago
So if you have nginx 1.7 or higher you're ok?
- antod 10y ago
  Not if you're on Debian or Ubuntu. Others were never affected.
benevol 10y ago
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/product_id-17956/Nginx-Nginx.html http://www.cvedetails.com/vulnerability-list/vendor_id-10048...
- kiallmacinnes 10y ago
  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 10y ago
What are the benefits of using Debian's package for nginx instead of using one from nginx.org's apt repo?
antocv 10y ago
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?

84 points by marksamman 10y ago

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 10y ago
Yikes this is pretty bad. Many log files (wrongly) include things like form fields including passwords and auth tokens.
- 0x0 10y ago
  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 10y ago
    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.

danielvf 10y ago

Is Ubuntu affected?

masterleep 10y ago
yes: https://launchpad.net/ubuntu/+source/nginx/1.10.0-0ubuntu0.16.04.3 https://launchpad.net/ubuntu/+source/nginx/1.10.0-0ubuntu0.1...

avodonosov 10y ago

What command should I run manually?

torbjorn 10y ago
sudo apt upgrade
- brianwawok 10y ago
  You forgot to update first
  - e12e 10y ago
    Indeed (s)he did: sudo apt update sudo apt upgrade See also: https://wiki.debian.org/UnattendedUpgrades https://wiki.debian.org/UnattendedUpgrades
    - avodonosov 10y ago
      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.
    - deleted 10y ago
      [deleted]
  - benevol 10y ago
    If you want to update a specific package only: sudo apt-get install --only-upgrade <package_name>
akerro 10y ago
Just setup daily unattended security updates.
- kiallmacinnes 10y ago
  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...

0x0 10y ago

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

LukeShu 10y ago

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 10y ago
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 10y ago
  > 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 10y ago
    > 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.

qwertyuiop924 10y ago

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

duskwuff 10y ago
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 10y ago
  Yeah, I guess, I just rarely see this many privescs. Am I not looking in the right places?
  - wildparrot 10y ago
    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/

torbjorn 10y ago

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

antod 10y ago
Not if you're on Debian or Ubuntu. Others were never affected.

benevol 10y ago

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/product_id-17956/Nginx-Nginx.html http://www.cvedetails.com/vulnerability-list/vendor_id-10048...

kiallmacinnes 10y ago
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 10y ago

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

antocv 10y ago

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?