1. 31 Jan, 2017 1 commit
  2. 30 Jan, 2017 7 commits
    • antirez's avatar
      Ziplist: insertion bug under particular conditions fixed. · 3876d985
      antirez authored
      Ziplists had a bug that was discovered while investigating a different
      issue, resulting in a corrupted ziplist representation, and a likely
      segmentation foult and/or data corruption of the last element of the
      ziplist, once the ziplist is accessed again.
      
      The bug happens when a specific set of insertions / deletions is
      performed so that an entry is encoded to have a "prevlen" field (the
      length of the previous entry) of 5 bytes but with a count that could be
      encoded in a "prevlen" field of a since byte. This could happen when the
      "cascading update" process called by ziplistInsert()/ziplistDelete() in
      certain contitious forces the prevlen to be bigger than necessary in
      order to avoid too much data moving around.
      
      Once such an entry is generated, inserting a very small entry
      immediately before it will result in a resizing of the ziplist for a
      count smaller than the current ziplist length (which is a violation,
      inserting code expects the ziplist to get bigger actually). So an FF
      byte is inserted in a misplaced position. Moreover a realloc() is
      performed with a count smaller than the ziplist current length so the
      final bytes could be trashed as well.
      
      SECURITY IMPLICATIONS:
      
      Currently it looks like an attacker can only crash a Redis server by
      providing specifically choosen commands. However a FF byte is written
      and there are other memory operations that depend on a wrong count, so
      even if it is not immediately apparent how to mount an attack in order
      to execute code remotely, it is not impossible at all that this could be
      done. Attacks always get better... and we did not spent enough time in
      order to think how to exploit this issue, but security researchers
      or malicious attackers could.
      
      REPRODUCING:
      
      The bug can be reproduced with the following commands.
      
          redis-cli del list
          redis-cli rpush list one
          redis-cli rpush list two
          redis-cli rpush list
          AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
          redis-cli rpush list
          AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
          redis-cli rpush list three
          redis-cli rpush list a
          redis-cli lrem list 1
          AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
          redis-cli linsert list after
          AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
          10
          redis-cli lrange list 0 -1
      
      Instead of "rpush list a", use "rpush list 10" in order to trigger a
      data corruption instead of a crash.
      3876d985
    • antirez's avatar
      Jemalloc updated to 4.4.0. · 153f2f00
      antirez authored
      The original jemalloc source tree was modified to:
      
      1. Remove the configure error that prevents nested builds.
      2. Insert the Redis private Jemalloc API in order to allow the
      Redis fragmentation function to work.
      153f2f00
    • miter's avatar
      Change switch statment to if statment · ca532c94
      miter authored
      ca532c94
    • oranagra's avatar
      fix rare assertion in DEBUG DIGEST · a7350353
      oranagra authored
      getExpire calls dictFind which can do rehashing.
      found by calling computeDatasetDigest from serverCron and running the test suite.
      a7350353
    • Itamar Haber's avatar
    • antirez's avatar
      Avoid geo.c warning in initialization. · 1177cf63
      antirez authored
      This problem was properly solved in 4.0 / unstable. Here is just a quick
      fix for the warning.
      1177cf63
    • antirez's avatar
      Security: Cross Protocol Scripting protection. · 874804da
      antirez authored
      This is an attempt at mitigating problems due to cross protocol
      scripting, an attack targeting services using line oriented protocols
      like Redis that can accept HTTP requests as valid protocol, by
      discarding the invalid parts and accepting the payloads sent, for
      example, via a POST request.
      
      For this to be effective, when we detect POST and Host: and terminate
      the connection asynchronously, the networking code was modified in order
      to never process further input. It was later verified that in a
      pipelined request containing a POST command, the successive commands are
      not executed.
      874804da
  3. 27 Jan, 2017 2 commits
  4. 21 Dec, 2016 1 commit
  5. 14 Dec, 2016 2 commits
    • antirez's avatar
      MIGRATE: Remove upfront ttl initialization. · 68aab8e8
      antirez authored
      After the fix for #3673 the ttl var is always initialized inside the
      loop itself, so the early initialization is not needed.
      
      Variables declaration also moved to a more local scope.
      68aab8e8
    • Jan-Erik Rediger's avatar
      Reset the ttl for additional keys · 788e8925
      Jan-Erik Rediger authored
      Before, if a previous key had a TTL set but the current one didn't, the
      TTL was reused and thus resulted in wrong expirations set.
      
      This behaviour was experienced, when `MigrateDefaultPipeline` in
      redis-trib was set to >1
      
      Fixes #3655
      788e8925
  6. 06 Dec, 2016 1 commit
  7. 05 Dec, 2016 2 commits
    • antirez's avatar
      Geo: improve fuzz test. · f20f3ead
      antirez authored
      The test now uses more diverse radius sizes, especially sizes near or
      greater the whole earth surface are used, that are known to trigger edge
      cases. Moreover the PRNG seeding was probably resulting into the same
      sequence tested over and over again, now seeding unsing the current unix
      time in milliseconds.
      
      Related to #3631.
      f20f3ead
    • antirez's avatar
      Geo: fix computation of bounding box. · 8c22086c
      antirez authored
      A bug was reported in the context in issue #3631. The root cause of the
      bug was that certain neighbor boxes were zeroed after the "inside the
      bounding box or not" check, simply because the bounding box computation
      function was wrong.
      
      A few debugging infos where enhanced and moved in other parts of the
      code. A check to avoid steps=0 was added, but is unrelated to this
      issue and I did not verified it was an actual bug in practice.
      8c22086c
  8. 16 Nov, 2016 1 commit
  9. 31 Oct, 2016 3 commits
  10. 26 Oct, 2016 3 commits
  11. 26 Sep, 2016 3 commits
    • antirez's avatar
      3.2.4 release notes clarifications. · 381651fa
      antirez authored
      381651fa
    • antirez's avatar
      Redis 3.2.4. · 070d0471
      antirez authored
      070d0471
    • antirez's avatar
      Security: CONFIG SET client-output-buffer-limit overflow fixed. · 05396347
      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.
      05396347
  12. 12 Sep, 2016 2 commits
  13. 09 Sep, 2016 3 commits
  14. 11 Aug, 2016 1 commit
  15. 05 Aug, 2016 1 commit
    • rojingeorge's avatar
      Display the nodes summary once the cluster is established using redis-trib.rb · 011dc9f9
      rojingeorge authored
      Display the nodes summary once the cluster is established using
      redis-trib.rb
      After the cluster meet and join was done, when the summary was shown, it
      was giving info regarding the nodes. This fix ensures that confusion
      where the slaves were shown as masters.
      Fix would be to reset the nodes and reload the cluster information
      before checking the cluster status after creating it.
      011dc9f9
  16. 04 Aug, 2016 1 commit
  17. 02 Aug, 2016 2 commits
  18. 01 Aug, 2016 1 commit
  19. 29 Jul, 2016 1 commit
  20. 28 Jul, 2016 2 commits
    • antirez's avatar
      Redis 3.2.2. · 7c6e288d
      antirez authored
      7c6e288d
    • antirez's avatar
      Ability of slave to announce arbitrary ip/port to master. · 0a45fbc3
      antirez authored
      This feature is useful, especially in deployments using Sentinel in
      order to setup Redis HA, where the slave is executed with NAT or port
      forwarding, so that the auto-detected port/ip addresses, as listed in
      the "INFO replication" output of the master, or as provided by the
      "ROLE" command, don't match the real addresses at which the slave is
      reachable for connections.
      0a45fbc3