Hi,
Thanks to Anca Vamanu < anca at voice-system dot ro> , the auth module
has a new mechanism for protecting the nonce against third party attacks.
So far, the auth module provided only nonce lifetime limitation to
prevent re-usage of the nonce. The new mechanism offers protection
against sniffing intrusion. The module generates and verifies the nonces
so that they can be used only once (in an auth response). This is done
by having a lifetime value and an index associated with every nonce.
Using only an expiration value is not good enough because,as this value
has to be of few tens of seconds, it is possible for someone to sniff on
the network, get the credentials and then reuse them in another packet
with which to register a different contact or make calls using the
other's account. The index ensures that this will never be possible
since it is generated as unique through the lifetime of the nonce.
What problem is solved:
========================
Typical intrusion scenario is:
1) UAC sends INVITE with no credentials
2) openser sends challenge to UAC
3) UAC sends INVITE with credentials (lifetime 1 minute)
4) the credentials (auth response) are exposed on the net, so anybody
can grab them (lets assume by person X)
5) openser accepts the credentials and call is establish
6) person X injects (by sending to openser) an re-INVITE (to change the
media destination, for example) by re-using the credentials that he
grabbed from the net.
7) credentials are accepted by openser if the lifetime is not expired.
So, third parties can modify (or even initiate) dialogs by re-using the
credentials they captures from a previous authentication. The only
limitation is the nonce lifetime which is about 30 - 60 seconds, long
enough for allowing such an atack.
The new mechanism, by blocking the re-usage of the same nonce (even if
the lifetime is still valid), will block step 7) as the same nonce was
used in step 5) (by UAC).
Technical details:
==================
The auth module keeps state for each nonce - to validate it only on the
first usage. A binary array (which can by default accomodate 100K
nonces) is used to keep the state. An index in this array is allocated
when the challenge is generated; this index in kept for the whole life
duration of the nonce. After the first auth result (for the nonce), the
following auth results for that nonce are discarded and re-challenged.
As nonce can be generated and later checked from different processes,
the nonce state (binary array) is kept in shm memory and the access to
it is synchronized via locking.
The see what is the overhead added by the computation time (keeping the
nonce state) and locking (sharing between processes), Anca run several
of tests :
- openser single process
- openser multiple processes, single processor machine
- openser multiple processes, multi processor machine
For tests we were using authentication via PV (for password and
username) to avoid using any slow data backend (radius or DB) that might
eclipse the overhead.
The measured overhead is 4% - 7% (from the original version).
Regards,
Bogdan
Show replies by date