Nginx version and vulnerability

Support
1

I am setting up a new ubuntu 18.04 server with ODK Sync Endpoint (on a VM). The server isn’t completely set up yet, but already our organization (Penn State University) during a security scan flagged a vulnerability in nginx. It looks like the version I just installed is 1.13.12 – but the current version is 1.17, and 1.16 fixed a number of vulnerabilities.

My questions are: will I encounter any problems if I upgrade nginx? And if not, would you please consider upgrading it in the git repository so that other people don’t encounter this same issue?

Thanks.

2

Thanks for pointing this security problem out.

We are currently working through making security updates in ODK-X. Give the update a try and let us know. If it works fine then we will be happy to upgrade it. I am not sure if other people have tried it.

Perhaps @linl33, @clarice_larson or @Emil have tried it?

3

Thanks very much. I:

  1. stopped the Endpoint (docker stack rm syncldap),
  2. edited docker-compose.yml
    (changed image: nginx:1.3 to image: nginx:latest)
  3. restarted the endpoint (docker stack deploy -c docker-compose.yml syncldap)
  4. verified that I was on v 1.17.3
    Everything seems to work fine.

EDIT: Now I’m not sure. We also added a cert yesterday. The site seems to work in that it automatically switches over to https, and presents us with a login prompt. Up to yesterday I was also having an issue with it refusing to accept the username I created in LDAP – today it seems to accept that password but then I get this:
August 29, 2019 12:41:49 PM UTC
There was an unexpected error (type=Internal Server Error, status=500).
500
Please contact the operator with the above information.
I don’t seem to be able to revert to nginx image 1.3 either, since the result of that is that the site doesn’t respond at all, almost as if the cert is bad.
So I’m not sure if this is due to the nginx upgrade or not. Any debugging suggestions are welcome.

4

I have tried NGINX 1.17 and it should work just as well as version 1.13.

The HTTP 500 is likely caused by misconfiguration of either the LDAP server or the Sync Endpoint container. It would help if you can post the logs of the Sync Endpoint container.

See docker logs documentation for steps to obtain container logs.

5

Thanks very much – logs attached.
docker_syncendpointcontainer_log_20190830.txt (63.0 KB)

6

I see there is an exception being thrown that implies that we may have installed the cert wrong. I’m also attaching our docker-compose.yml and a text document with some notes about how we went about installing the cert. Note: we requested an nginx cert, not a tomcat one.
Thanks again for any advice you can give us.

docker-compose.yml.txt (3.5 KB) cert_notes.txt (3.5 KB)

7

The server couldn’t read the default group attribute for your user. Make sure all users have the default group attribute gidNumber set. gidNumber is also known as the primary group attribute.

8

Thanks, but since I’m still using command line ldap tools and there wasn’t a template to choose from when creating the user, I put the odk2_admin user entry into the people ou. But apparently the people ObjectClass does not allow gidNumber.
So that’s maybe the problem. Should I remove this ldap user and recreate it as a PosixAccount?

To be clear, here is the ldif file I just created and attempted to execute:

#SET DEFAULT GROUP ID
dn: uid=odk2_admin,ou=people,dc=example,dc=org
changetype: modify
add: gidNumber
gidNumber: 500

and here is the error message:
ldap_modify: Object class violation (65)
additional info: attribute ‘gidNumber’ not allowed

Thanks so much for all your help, and sorry to be a pain but much of this is new to me.

– Ned (emb23@psu.edu)

9

As long as the gidNumber attribute is set it should be alright.

For reference, this is what the phpLDAPAdmin template creates:

dn: uid=myuser,ou=people,dc=example,dc=org
cn: myuser
gidnumber: 501
homedirectory: /home/users/myuser
objectclass: inetOrgPerson
objectclass: posixAccount
objectclass: top
sn: myuser
uid: myuser
uidnumber: 1000
userpassword: *****************************
10

Awesome, thank you – that did the trick. Had to delete the previous entry from ldap and then re-added it according to your spec, and now I can log in as that user

My suggestion or request if this is possible is to post a couple of example ldif files to the documentation at ODK-X Sync Endpoint — ODK-X Docs – it would perhaps save some people like me from a lot of trial and error.

But thanks so much.