1. 13 Oct, 2016 2 commits
  2. 07 Oct, 2016 7 commits
  3. 06 Oct, 2016 4 commits
    • antirez's avatar
      Fix typos in GetContextFromIO API declaration. · a5998d1f
      antirez authored
      a5998d1f
    • antirez's avatar
      Fix name of mispelled function. · 799208de
      antirez authored
      799208de
    • antirez's avatar
      Module: Ability to get context from IO context. · 152c1b68
      antirez authored
      It was noted by @dvirsky that it is not possible to use string functions
      when writing the AOF file. This sometimes is critical since the command
      rewriting may need to be built in the context of the AOF callback, and
      without access to the context, and the limited types that the AOF
      production functions will accept, this can be an issue.
      
      Moreover there are other needs that we can't anticipate regarding the
      ability to use Redis Modules APIs using the context in order to build
      representations to emit AOF / RDB.
      
      Because of this a new API was added that allows the user to get a
      temporary context from the IO context. The context is auto released
      if obtained when the RDB / AOF callback returns.
      
      Calling multiple time the function to get the context, always returns
      the same one, since it is invalid to have more than a single context.
      152c1b68
    • antirez's avatar
      Copyright notice added to module.c. · 72279e3e
      antirez authored
      72279e3e
  4. 02 Oct, 2016 4 commits
  5. 26 Sep, 2016 3 commits
    • antirez's avatar
      6782e774
    • antirez's avatar
    • antirez's avatar
      Security: CONFIG SET client-output-buffer-limit overflow fixed. · 6d9f8e24
      antirez authored
      This commit fixes a vunlerability reported by Cory Duplantis
      of Cisco Talos, see TALOS-2016-0206 for reference.
      
      CONFIG SET client-output-buffer-limit accepts as client class "master"
      which is actually only used to implement CLIENT KILL. The "master" class
      has ID 3. What happens is that the global structure:
      
          server.client_obuf_limits[class]
      
      Is accessed with class = 3. However it is a 3 elements array, so writing
      the 4th element means to write up to 24 bytes of memory *after* the end
      of the array, since the structure is defined as:
      
          typedef struct clientBufferLimitsConfig {
              unsigned long long hard_limit_bytes;
              unsigned long long soft_limit_bytes;
              time_t soft_limit_seconds;
          } clientBufferLimitsConfig;
      
      EVALUATION OF IMPACT:
      
      Checking what's past the boundaries of the array in the global
      'server' structure, we find AOF state fields:
      
          clientBufferLimitsConfig client_obuf_limits[CLIENT_TYPE_OBUF_COUNT];
          /* AOF persistence */
          int aof_state;                  /* AOF_(ON|OFF|WAIT_REWRITE) */
          int aof_fsync;                  /* Kind of fsync() policy */
          char *aof_filename;             /* Name of the AOF file */
          int aof_no_fsync_on_rewrite;    /* Don't fsync if a rewrite is in prog. */
          int aof_rewrite_perc;           /* Rewrite AOF if % growth is > M and... */
          off_t aof_rewrite_min_size;     /* the AOF file is at least N bytes. */
          off_t aof_rewrite_base_size;    /* AOF size on latest startup or rewrite. */
          off_t aof_current_size;         /* AOF current size. */
      
      Writing to most of these fields should be harmless and only cause problems in
      Redis persistence that should not escalate to security problems.
      However unfortunately writing to "aof_filename" could be potentially a
      security issue depending on the access pattern.
      
      Searching for "aof.filename" accesses in the source code returns many different
      usages of the field, including using it as input for open(), logging to the
      Redis log file or syslog, and calling the rename() syscall.
      
      It looks possible that attacks could lead at least to informations
      disclosure of the state and data inside Redis. However note that the
      attacker must already have access to the server. But, worse than that,
      it looks possible that being able to change the AOF filename can be used
      to mount more powerful attacks: like overwriting random files with AOF
      data (easily a potential security issue as demostrated here:
      http://antirez.com/news/96), or even more subtle attacks where the
      AOF filename is changed to a path were a malicious AOF file is loaded
      in order to exploit other potential issues when the AOF parser is fed
      with untrusted input (no known issue known currently).
      
      The fix checks the places where the 'master' class is specifiedf in
      order to access configuration data structures, and return an error in
      this cases.
      
      WHO IS AT RISK?
      
      The "master" client class was introduced in Redis in Jul 28 2015.
      Every Redis instance released past this date is not vulnerable
      while all the releases after this date are. Notably:
      
          Redis 3.0.x is NOT vunlerable.
          Redis 3.2.x IS vulnerable.
          Redis unstable is vulnerable.
      
      In order for the instance to be at risk, at least one of the following
      conditions must be true:
      
          1. The attacker can access Redis remotely and is able to send
             the CONFIG SET command (often banned in managed Redis instances).
      
          2. The attacker is able to control the "redis.conf" file and
             can wait or trigger a server restart.
      
      The problem was fixed 26th September 2016 in all the releases affected.
      6d9f8e24
  6. 21 Sep, 2016 2 commits
  7. 20 Sep, 2016 1 commit
    • antirez's avatar
      dict.c: fix dictGenericDelete() return ASAP condition. · 67058671
      antirez authored
      Recently we moved the "return ASAP" condition for the Delete() function
      from checking .size to checking .used, which is smarter, however while
      testing the first table alone always works to ensure the dict is totally
      emtpy, when we test the .size field, testing .used requires testing both
      T0 and T1, since a rehashing could be in progress.
      67058671
  8. 19 Sep, 2016 5 commits
  9. 16 Sep, 2016 7 commits
  10. 15 Sep, 2016 5 commits