• United States



by Staff Writer

Nginx sets world-readable logs by default

Nov 07, 20134 mins
Data and Information SecurityNetwork SecurityPrivacy

Webserver's issue found to be much larger-scale than initially thought

Nginx (pronounced engine-x), a lightweight alternative to Apache when it comes to webservers, installs access and error logs that are world-readable by default. Intitially, the security advisory related to the issue noted that the impact was low, but researchers at CloudPassage and Redspin have discovered that the issue has a much wider reach, including current source-based installations.

An easily deployed, lighweight alternative to Apache when it comes to webservers, Nginx doesn’t tax resources and is able to handle high-traffic domains with ease. The virsitility makes it a favorite for developers the world over, as well as a favorite with investors — who dropped $10 million in funding on the company last month. Many of the Web’s most popular websites run Nginx, including Facebook, Hulu, Dropbox, CloudFlare, GitHub, and more. According to Netcraft, 15 percent of the top million busiest websites run the platform.

However, Nginx comes with a rather unique and unexpected risk that needs to be considered before it’s deployed into production. Last week, US-CERT released CVE-2013-0337 that highlights an issue with how Nginx creates access.log and error.log — noting that they are installed with world-readable permissions.

[Log management basics]

US-CERT, running with the Gentoo Linux advisory, noted that Nginx versions 1.3.13 and earlier were vulnerable, but David Shaw, CTO at Redspin, and Andrew Hay, Director of Applied Security Research at CloudPassage Inc., have discovered a larger affected version count than disclosed in the CVE.

According to their tests, Nginx 1.5.6, 1.4.3, and 1.2.9 when installed from source also set world-readable permissions by default. Moreover, the Amazon Linux implementation of Nginx and the version on Ubuntu do it too, and it is likely that other “combinations of operating system specific packages are suceptible to the issues in the CVE,” Hay noted in a report on the issue.

When asked about the issue, Nginx’s Maxim Dounin told one researcher that his company was fine with how the default permissions on the logs were set.

“If in a particular configuration stricter permissions are required, this may be done either by creating appropriate log files with needed permissions, or by restricting access to a directory with log files,” Dounin said.

But how serious is the issue? First, it’s a violation of responsible security practices for information access, but at the same time, it isn’t the Holy Grail of vulnerabilities, Hay told CSO. But in his opinion “the default configuration does give too much access for a production environment.”

Nginx is popular, and that popularity is only growing month over month. So what does this issue mean for an organization risk wise, and how can it impact their security posture?

“I think it depends entirely on how your web applications are configured to write to the nginx logs. The last thing you want is for your application to log sensitive PII or other regulated data into a log file that is publically accessible by anyone on the system,” Hay explained.

“The likelihood of a security risk is low but the potential for privacy related risk is much higher. I can’t help but think an organization would not be too pleased to discover this particular finding during the course of an audit.”

With that said, we asked Hay his thoughts on what needs to be done to correct this issue, especially since the fix has been placed on the user’s shoulders by Nginx. What about using logroatate to manage the files?

“If you use logrotate you can rotate the existing log file and create a new log file with the specified permissions, owner, and group. The default, however, is to use the same mode, owner, and group as the original file. The odds that a user will apply security scrutiny to the logrotate configuration when they’re already ignoring the native log file permissions, however, is unlikely,” he said.

“The quickest way to correct the issue is to use the chmod utility to either reduce existing, or overlay new, permissions. Users should also ensure that these permissions remain intact by employing continuous monitoring methodologies and tools.”