Opened 8 years ago

Closed 8 years ago

Last modified 3 years ago

#296 closed defect (invalid)

HttpUseridModule lacks uniqueness in uid generation

Reported by: Patrick Ellul Owned by:
Priority: minor Milestone:
Component: nginx-module Version: 1.3.x
Keywords: userid, security Cc:
uname -a: Linux XXXXXX 3.2.34-55.46.amzn1.x86_64 #1 SMP Tue Nov 20 10:06:15 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
nginx -V: nginx_1.2.5

Description

Looking at the C code of this module, it seems that the UID generation is based on 4 things in order:

1) local_sockaddr
2) ngx_time
3) start time of nginx
4) sequence

However, these values are converted to uint32 before being htonl'ed.

Then they are sprintf'ed using %08XD

Also the resultant cookie is trimmed to 22 characters.

This means that the assigned uid is not very unique, not to mention quite predictable.

When using this uid for session management, it makes it possible for users to intrude on other users sessions, perhaps even steal another user's session on purpose.

We discovered this from our production systems, when we noticed that the same uid was being given to hundreds of different clients.

The nature of our system is such that we receive massive bursts of requests in a small amount of time and hence the chance of this happening increases quite a lot.

A simple fix could be to use a long random string instead, possibly of configurable length.

Change History (4)

comment:1 by Maxim Dounin, 8 years ago

Resolution: invalid
Status: newclosed

UID generated is 128 bit number, and it is generated in a way which provides uniqueness for up to 2128 cookies for a single domain as long as properly configured (note that you are responsible for proper userid_service assignment if multiple servers with the same ip address are used, see docs and original mod_uid apache module documentation for details).

The module was never meant to provide unpredictable values, it's design goal is different. See original mod_uid apache module documentation, it has many details explaining why it works this way and how it's expected to be used.

in reply to:  1 ; comment:2 by Patrick Ellul, 8 years ago

Thank you for your prompt reply.

I looked at the references but I could not find an explanation why the length is trimmed to 22 characters. Since the sequencer is the final 32 bits, potentially it might be trimming the most significant bits.

Replying to Maxim Dounin:

UID generated is 128 bit number, and it is generated in a way which provides uniqueness for up to 2128 cookies for a single domain as long as properly configured (note that you are responsible for proper userid_service assignment if multiple servers with the same ip address are used, see docs and original mod_uid apache module documentation for details).

The module was never meant to provide unpredictable values, it's design goal is different. See original mod_uid apache module documentation, it has many details explaining why it works this way and how it's expected to be used.

in reply to:  2 comment:3 by Ruslan Ermilov, 8 years ago

Replying to Patrick Ellul <pellul@ipowow.com>:

Thank you for your prompt reply.

I looked at the references but I could not find an explanation why the length is trimmed to 22 characters. Since the sequencer is the final 32 bits, potentially it might be trimming the most significant bits.

UID is 128 bit entity.
128 bits == 16 bytes
16 bytes encoded in Base64 gives you 22 characters.

comment:4 by Maxim Dounin, 3 years ago

sensitive: 10
Note: See TracTickets for help on using tickets.