1. 26 Sep, 2016 1 commit
    • 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
  2. 12 Sep, 2016 2 commits
  3. 09 Sep, 2016 3 commits
  4. 11 Aug, 2016 1 commit
  5. 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
  6. 04 Aug, 2016 1 commit
  7. 02 Aug, 2016 2 commits
  8. 01 Aug, 2016 1 commit
  9. 29 Jul, 2016 1 commit
  10. 28 Jul, 2016 3 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
    • antirez's avatar
      redis-benchmark: new option to show server errors on stdout. · c3982c09
      antirez authored
      Disabled by default, can be activated with -e. Maybe the reverse was
      more safe but departs from the past behavior.
      c3982c09
  11. 27 Jul, 2016 6 commits
    • antirez's avatar
      Multiple GEORADIUS bugs fixed. · fdafe233
      antirez authored
      By grepping the continuous integration errors log a number of GEORADIUS
      tests failures were detected.
      
      Fortunately when a GEORADIUS failure happens, the test suite logs enough
      information in order to reproduce the problem: the PRNG seed,
      coordinates and radius of the query.
      
      By reproducing the issues, three different bugs were discovered and
      fixed in this commit. This commit also improves the already good
      reporting of the fuzzer and adds the failure vectors as regression
      tests.
      
      The issues found:
      
      1. We need larger squares around the poles in order to cover the area
      requested by the user. There were already checks in order to use a
      smaller step (larger squares) but the limit set (+/- 67 degrees) is not
      enough in certain edge cases, so 66 is used now.
      
      2. Even near the equator, when the search area center is very near the
      edge of the square, the north, south, west or ovest square may not be
      able to fully cover the specified radius. Now a test is performed at the
      edge of the initial guessed search area, and larger squares are used in
      case the test fails.
      
      3. Because of rounding errors between Redis and Tcl, sometimes the test
      signaled false positives. This is now addressed.
      
      Whenever possible the original code was improved a bit in other ways. A
      debugging example stanza was added in order to make the next debugging
      session simpler when the next bug is found.
      fdafe233
    • antirez's avatar
      Replication: when possible start RDB saving ASAP. · a1bfe22a
      antirez authored
      In a previous commit the replication code was changed in order to
      centralize the BGSAVE for replication trigger in replicationCron(),
      however after further testings, the 1 second delay imposed by this
      change is not acceptable.
      
      So now the BGSAVE is only delayed if the AOF rewriting process is
      active. However past comments made sure that replicationCron() is always
      able to trigger the BGSAVE when needed, making the code generally more
      robust.
      
      The new code is more similar to the initial @oranagra patch where the
      BGSAVE was delayed only if an AOF rewrite was in progress.
      
      Trivia: delaying the BGSAVE uncovered a minor Sentinel issue that is now
      fixed.
      a1bfe22a
    • antirez's avatar
      7ca69aff
    • antirez's avatar
      Sentinel: check Slave INFO state more often when disconnected. · 5b5e6520
      antirez authored
      During the initial handshake with the master a slave will report to have
      a very high disconnection time from its master (since technically it was
      disconnected since forever, so the current UNIX time in seconds is
      reported).
      
      However when the slave is connected again the Sentinel may re-scan the
      INFO output again only after 10 seconds, which is a long time. During
      this time Sentinels will consider this instance unable to failover, so
      a useless delay is introduced.
      
      Actaully this hardly happened in the practice because when a slave's
      master is down, the INFO period for slaves changes to 1 second. However
      when a manual failover is attempted immediately after adding slaves
      (like in the case of the Sentinel unit test), this problem may happen.
      
      This commit changes the INFO period to 1 second even in the case the
      slave's master is not down, but the slave reported to be disconnected
      from the master (by publishing, last time we checked, a master
      disconnection time field in INFO).
      
      This change is required as a result of an unrelated change in the
      replication code that adds a small delay in the master-slave first
      synchronization.
      5b5e6520
    • antirez's avatar
      Avoid simultaneous RDB and AOF child process. · 21cffc26
      antirez authored
      This patch, written in collaboration with Oran Agra (@oranagra) is a companion
      to 780a8b1d. Together the two patches should avoid that the AOF and RDB saving
      processes can be spawned at the same time. Previously conditions that
      could lead to two saving processes at the same time were:
      
      1. When AOF is enabled via CONFIG SET and an RDB saving process is
         already active.
      
      2. When the SYNC command decides to start an RDB saving process ASAP in
         order to serve a new slave that cannot partially resynchronize (but
         only if we have a disk target for replication, for diskless
         replication there is not such a problem).
      
      Condition "1" is not very severe but "2" can happen often and is
      definitely good at degrading Redis performances in an unexpected way.
      
      The two commits have the effect of always spawning RDB savings for
      replication in replicationCron() instead of attempting to start an RDB
      save synchronously. Moreover when a BGSAVE or AOF rewrite must be
      performed, they are instead just postponed using flags that will try to
      perform such operations ASAP.
      
      Finally the BGSAVE command was modified in order to accept a SCHEDULE
      option so that if an AOF rewrite is in progress, when this option is
      given, the command no longer returns an error, but instead schedules an
      RDB rewrite operation for when it will be possible to start it.
      21cffc26
    • antirez's avatar
      Replication: start BGSAVE for replication always in replicationCron(). · 017378ec
      antirez authored
      This makes the replication code conceptually simpler by removing the
      synchronous BGSAVE trigger in syncCommand(). This also means that
      socket and disk BGSAVE targets are handled by the same code.
      017378ec
  12. 06 Jul, 2016 2 commits
  13. 05 Jul, 2016 2 commits
  14. 04 Jul, 2016 12 commits
  15. 30 Jun, 2016 2 commits