Commit cd0269505872933a9a8567ca5bcc402a7f17d344

Authored by Georg Hopp
1 parent 1dfefcbf

add todo for session memory overflow

... ... @@ -32,6 +32,43 @@
32 32 // livetime of a session in seconds
33 33 #define SESSION_LIVETIME 300 // 5 minutes
34 34
  35 +/**
  36 + * Having only a session livetime is not enough.
  37 + * An attacker might create a client that never sends a session id
  38 + * back and continuously sends requests. This will then result
  39 + * in newly created sessions.
  40 + * The session class uses 57 bytes
  41 + * But there is also a user object created all the time.
  42 + * This uses 80 bytes.
  43 + * Each user in turn contains a uuid which is 37 bytes.
  44 + * Each of these are a class which adds another 221 bytes to each.
  45 + * So the following is allocated for these three objects:
  46 + * Session: 57 + 221 = 278
  47 + * User: 80 + 221 = 301
  48 + * Uuid: 37 + 221 = 258
  49 + * My allocater only allocates power of 2 sizes to optimize
  50 + * memory management so we end up with 512 bytes per object which is
  51 + * 1536 bytes per created session.
  52 + * The current code is able to handle more than 25000 request per
  53 + * second if there is no session id provided on my hardware.
  54 + * This sums up to 10GB of used memory within the 5 minutes
  55 + * session livetime.
  56 + *
  57 + * @TODO
  58 + * One possible solution is to prevent the creation of sessions
  59 + * for subsequent requests from the same connection or ip within
  60 + * a given time range. This time range should be the session
  61 + * livetime. This would effectively prevent such malicious requests
  62 + * from doing harm but also prevents non attackers that did a
  63 + * first request from another client (lets say telnet) from getting
  64 + * a session in their browser. This might be accaptable if the user
  65 + * gets a fitting error message.
  66 + * To prevent this we could associate the session with the ip it was
  67 + * created on. If there then is a subsequent request from the same ip
  68 + * without a sessionid, the old session can be removed and a new one
  69 + * can be created. This might give a small but acceptable performance
  70 + * hit.
  71 + */
35 72
36 73 TR_CLASS(Session) {
37 74 char id[37];
... ...
... ... @@ -42,6 +42,7 @@ routerCtor(void * _this, va_list * params)
42 42 this->application = va_arg(*params, Application);
43 43 this->functions = TR_new(TR_Hash);
44 44 this->handle = dlopen(NULL, RTLD_LAZY);
  45 + dlerror();
45 46 this->prefix = PREFIX;
46 47 this->nprefix = sizeof(PREFIX) - 1;
47 48
... ... @@ -58,6 +59,7 @@ routerDtor(void * _this) {
58 59 Router this = _this;
59 60
60 61 TR_delete(this->functions);
  62 + dlerror();
61 63 dlclose(this->handle);
62 64 }
63 65
... ...
... ... @@ -43,3 +43,10 @@
43 43 fun:ldap_open_defconn
44 44 }
45 45
  46 +{
  47 + Ignore dlopen bug.
  48 + Memcheck:Leak
  49 + ...
  50 + fun:_dl_open
  51 + ...
  52 +}
... ...
Please register or login to post a comment