[security advisory] http://wiki.nginx.org/Redmine

[Francis Daly]

On Mon, Mar 09, 2015 at 04:44:05PM +0200, Gena Makhomed wrote:
> On 08.03.2015 22:50, Francis Daly wrote:

Hi there,

> >>webpage http://wiki.nginx.org/Redmine has some security problems:
> >>
> >>1. All redmine config files are available for anybody in internet,
> >>for example: https://redmine.example.com/config/database.yml
> >>contains in plain text login and password for database connection.
> >
> >I don't think that one is an nginx problem.

> Yes, this is not nginx problem. This is nginx configuration problem,
> which provided at wiki.nginx.org as "drop in configuration" for redmine.

I think that you are incorrect in your understanding of it as an nginx
configuration problem, and as a drop-in configuration.

> >From reading the redmine docs, it looks like the contents of the "root"
> >directive directory should be whatever is in the distributed redmine
> >public/ directory; not the entire installation including configuration.
> 
> I am talk about configuration recommended
> at webpage http://wiki.nginx.org/Redmine
> not about "reading the redmine docs".

But the user must have followed some documentation to install redmine in
the first place; and if they unthinkingly install it into /var/www/redmine
they are probably doing something wrong before nginx gets involved.

I see instructions to install to /opt/redmine, and to /var/lib/redmine,
and to /usr/share/redmine, and in each case they say to do something like

  ln -s /usr/share/redmine/public /var/www/redmine

to have only the web-accessible content below /var/www/redmine.

If the user really wants to install to /var/www/redmine, then they must
modify the "root" directive (to be /var/www/redmine/public), as the
words on the wiki page already say.

I do not see this as an nginx-related security problem.

> >And if /var/www/redmine does just have the public/ contents and the
> >upstream servers reveal secret information, that would be their problem
> >and not nginx's, I think.
> 
>    root /var/www/redmine;
>    try_files $uri @ruby;
> 
> Request https://redmine.example.com/config/database.yml will be
> processed by nginx, because file /var/www/redmine/config/database.yml
> exists. For details - see manual about try_files directive in nginx.

The file /var/www/redmine/config/database.yml should not exist.

If the file /var/www/redmine/config/database.yml does exist and the
above nginx configuration is used, then the user will find that no part
of their redmine web-related installation will work, because all of the
images and stylesheets and javascripts are inaccessible.

Correspondingly, if the user has installed only web content below
/var/www, then using a different "root" directive will cause that
installation not to work.

> >>3. Unsafe variable $http_host was used instead of safe one $host
> >
> >I'm not sure how $http_host is less safe than $host. It is proxy_pass'ed
> >to the "real" redmine server as the Host header. That server must be
> >able to handle it safely anyway, no?
> 
> Such configuration allow to spoof nginx built-in server selection rules.
> because nginx will use server name from request line, but will provide
> to upstream completely different server name, from Host request header.

It is true that $http_host is completely controlled by the client, and
$host is mostly controlled by the client. It is true that they can have
different values. I do not see that the difference is a security issue
in this case.

> So, $host must be used always with proxy_pass instead of $http_host.

If the upstream server would do anything security-relevant with the Host:
header that it gets from nginx, it would do exactly the same with the
Host: header that it would get from the client directly, no?

Also: I suspect that $http_host was there because if you run nginx
on not-port-80, using $host will probably lose that information. The
server{} has no "listen", so it will use port 80 or 8080 depending on
the invoking user.

The config that was there (probably) works under some circumstances, and
fails under some others. It's fine to change it to another configuration
which works under some different circumstances, but you should probably
be aware that you are failing under different circumstances too.

As as "example" config, it should be understood that it does not cover
all circumstances. And the newer example config may be more suitable
for more installations -- I'll let someone else count them, if they
care. But I don't see how security is involved in the change.

Cheers,

	f
-- 
Francis Daly        francis at daoine.org