Running restore command with a malformed serialized value (but valid checksum and rdb version) crashes the redis process.

In general, serialized-value for restore command is obtained by calling the dump command. In my case, I am generating the serialized value directly as part of a tool I am building. Due to a bug in my code, I was generating an incorrect payload. The checksum and rdb version are correct, so redis server doesn't immediately return an error. But when it tries to load the object, it crashes.

Looking at the source code, it seems there are a variety of code paths that can cause server to crash if the payload is malformed.

I am not sure if this should be considered a bug, because normal users are unlikely to face this. My expectation was the restore command would return an error indicating malformed payload or something like that.

To reproduce:

cat hash_as_ziplist.bin | redis-cli --pipe

will crash redis-server with the message ziplist with dup elements dump (hexdump of 3343411 bytes):

hash_as_ziplist.bin.zip

Comment From: 0xtonyxia

We have encountered a similar problem in our production environment when using redis-port to migrate data. I think for a command which can be issued by a normal user, having the power to crash the server by just using an invalid argument is too dangerous.

Comment From: itamarhaber

Personal confession: this "exploit" has been my favorite tool for testing black-box hosted services failover times :)

If I remember correctly we discussed this in the past and decided that it is "good enough" in the sense that: 1. Misuse can't be entirely prevented (only, perhaps, be made harder) 2. CRC is cheap 3. Anything else would slow deserialization and, hence, effect load times

On Thu, Aug 16, 2018 at 6:22 PM, TonyXia notifications@github.com wrote:

We have encountered a similar problem in our production environment when using redis-port to migrate data. I think for a command which can be issued by a normal user, having the power to crash the server by just using an invalid argument is too dangerous.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/antirez/redis/issues/5255#issuecomment-413583206, or mute the thread https://github.com/notifications/unsubscribe-auth/AFx1_O33-Oit_4nHoGK98nEFgFOA0eNPks5uRY4lgaJpZM4V_bxx .

--

Itamar Haber Technicalist Evangenly

Phone: +972.54.567.9692 [image: Redis Labs] https://redislabs.com/

Comment From: shenlongxing

We met some similar problems. A serialized-value without a real value may restore successfully. I think it is unreasonable. Reproduce like this:

127.0.0.1:6379> restore string 0 "\x00\x00\x07\x00\xa2\xa9\x89\xb3\x07\xb5w\xc0"
OK
127.0.0.1:6379> restore list 0 "\x01\x00\x07\x00\xa4\xca\xf0?d\xdd\x96L"
OK
127.0.0.1:6379> type string
string
127.0.0.1:6379> get string
""
127.0.0.1:6379> strlen string
(integer) 0
127.0.0.1:6379> type list
list
127.0.0.1:6379> llen list
(integer) 0

Comment From: lcmkevin

Is this problem solved yet?

Comment From: oranagra

not yet, but it is currently being worked on in #7807