mirrors/tcpdump
0
0
Fork 0
mirror of https://github.com/the-tcpdump-group/tcpdump.git synced 2024-11-24 02:23:27 +08:00
Code Issues Packages Projects Releases Wiki Activity
6f53130273
tcpdump/print-resp.c

543 lines
16 KiB
C
Raw Normal View History

Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
/*
* Copyright (c) 2015 The TCPDUMP project
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
* FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
* COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
* BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
* LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
* CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
* ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*
* Initial contribution by Andrew Darqui (andrew.darqui@gmail.com).
*/
Add a summary comment in all other printers Moreover: Remove some redundant comments Update some summary comments Update the specification URL for ATA over Ethernet (AoE) protocol
2016-08-15 21:27:28 +08:00
/* \summary: REdis Serialization Protocol (RESP) printer */
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
#ifdef HAVE_CONFIG_H
Always include <config.h> rather than "config.h". This can prevent bizarre failures if, for example, you've done a configuration in the top-level source directory, leaving behind one config.h file, and then do an out-of-tree build in another directory, with different configuration options. This way, we always pick up the same config.h, in the build directory.
2018-01-22 04:27:08 +08:00
#include <config.h>
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
#endif
Use quoted include netdissect-stdinc.h instead of angle-bracketed one
2018-01-20 22:59:49 +08:00
#include "netdissect-stdinc.h"
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
#include "netdissect.h"
Use strtol(), not atoi(), to parse integral values. strtol()'s error behavior is standardized; atoi()'s isn't.
2016-04-26 18:04:21 +08:00
#include <limits.h>
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
#include <string.h>
#include <stdlib.h>
Use strtol(), not atoi(), to parse integral values. strtol()'s error behavior is standardized; atoi()'s isn't.
2016-04-26 18:04:21 +08:00
#include <errno.h>
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
#include "extract.h"
/*
Use more HTTPS in URLs [skip ci]
2019-08-05 21:11:50 +08:00
* For information regarding RESP, see: https://redis.io/topics/protocol
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
*/
#define RESP_SIMPLE_STRING '+'
#define RESP_ERROR '-'
#define RESP_INTEGER ':'
#define RESP_BULK_STRING '$'
#define RESP_ARRAY '*'
Update ND_PRINT() as a variadic macro
2018-01-07 18:47:30 +08:00
#define resp_print_empty(ndo) ND_PRINT(" empty")
#define resp_print_null(ndo) ND_PRINT(" null")
#define resp_print_length_too_large(ndo) ND_PRINT(" length too large")
#define resp_print_length_negative(ndo) ND_PRINT(" length negative and not -1")
#define resp_print_invalid(ndo) ND_PRINT(" invalid")
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
void resp_print(netdissect_options *, const u_char *, u_int);
Remove all storage class specifier 'register' Let the compiler do the optimizations (or not) based on build options. Avoid 'value has been optimized out' messages in gdb using '-O0'.
2017-12-14 02:17:47 +08:00
static int resp_parse(netdissect_options *, const u_char *, int);
static int resp_print_string_error_integer(netdissect_options *, const u_char *, int);
static int resp_print_simple_string(netdissect_options *, const u_char *, int);
static int resp_print_integer(netdissect_options *, const u_char *, int);
static int resp_print_error(netdissect_options *, const u_char *, int);
static int resp_print_bulk_string(netdissect_options *, const u_char *, int);
static int resp_print_bulk_array(netdissect_options *, const u_char *, int);
static int resp_print_inline(netdissect_options *, const u_char *, int);
static int resp_get_length(netdissect_options *, const u_char *, int, const u_char **);
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
#define LCHECK2(_tot_len, _len) \
{ \
if (_tot_len < _len) \
goto trunc; \
}
#define LCHECK(_tot_len) LCHECK2(_tot_len, 1)
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
/*
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
* FIND_CRLF:
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
* Attempts to move our 'ptr' forward until a \r\n is found,
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
* while also making sure we don't exceed the buffer '_len'
* or go past the end of the captured data.
* If we exceed or go past the end of the captured data,
* jump to trunc.
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
*/
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
#define FIND_CRLF(_ptr, _len) \
for (;;) { \
LCHECK2(_len, 2); \
Use more ND_TCHECK_n() macros
2017-11-30 04:06:51 +08:00
ND_TCHECK_2(_ptr); \
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
if (*_ptr == '\r' && *(_ptr+1) == '\n') \
break; \
_ptr++; \
_len--; \
}
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
/*
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
* CONSUME_CRLF
* Consume a CRLF that we've just found.
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
*/
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
#define CONSUME_CRLF(_ptr, _len) \
_ptr += 2; \
_len -= 2;
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
/*
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
* FIND_CR_OR_LF
* Attempts to move our '_ptr' forward until a \r or \n is found,
* while also making sure we don't exceed the buffer '_len'
* or go past the end of the captured data.
* If we exceed or go past the end of the captured data,
* jump to trunc.
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
*/
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
#define FIND_CR_OR_LF(_ptr, _len) \
for (;;) { \
LCHECK(_len); \
Use more the ND_TCHECK_1() macro
2018-01-02 23:16:02 +08:00
ND_TCHECK_1(_ptr); \
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
if (*_ptr == '\r' || *_ptr == '\n') \
break; \
_ptr++; \
_len--; \
}
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
/*
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
* CONSUME_CR_OR_LF
* Consume all consecutive \r and \n bytes.
* If we exceed '_len' or go past the end of the captured data,
* jump to trunc.
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
*/
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
#define CONSUME_CR_OR_LF(_ptr, _len) \
{ \
int _found_cr_or_lf = 0; \
for (;;) { \
/* \
* Have we hit the end of data? \
*/ \
RESP: Use more the ND_TCHECK_1() macro
2018-01-13 04:27:07 +08:00
if (_len == 0 || !ND_TTEST_1(_ptr)) {\
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
/* \
* Yes. Have we seen a \r \
* or \n? \
*/ \
if (_found_cr_or_lf) { \
/* \
* Yes. Just stop. \
*/ \
break; \
} \
/* \
* No. We ran out of packet. \
*/ \
goto trunc; \
} \
if (*_ptr != '\r' && *_ptr != '\n') \
break; \
_found_cr_or_lf = 1; \
_ptr++; \
_len--; \
} \
}
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
/*
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
* SKIP_OPCODE
* Skip over the opcode character.
* The opcode has already been fetched, so we know it's there, and don't
* need to do any checks.
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
*/
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
#define SKIP_OPCODE(_ptr, _tot_len) \
_ptr++; \
_tot_len--;
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
/*
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
* GET_LENGTH
* Get a bulk string or array length.
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
*/
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
#define GET_LENGTH(_ndo, _tot_len, _ptr, _len) \
{ \
const u_char *_endp; \
_len = resp_get_length(_ndo, _ptr, _tot_len, &_endp); \
_tot_len -= (_endp - _ptr); \
_ptr = _endp; \
}
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
/*
* TEST_RET_LEN
* If ret_len is < 0, jump to the trunc tag which returns (-1)
* and 'bubbles up' to printing tstr. Otherwise, return ret_len.
*/
#define TEST_RET_LEN(rl) \
if (rl < 0) { goto trunc; } else { return rl; }
/*
* TEST_RET_LEN_NORETURN
* If ret_len is < 0, jump to the trunc tag which returns (-1)
* and 'bubbles up' to printing tstr. Otherwise, continue onward.
*/
#define TEST_RET_LEN_NORETURN(rl) \
if (rl < 0) { goto trunc; }
/*
* RESP_PRINT_SEGMENT
* Prints a segment in the form of: ' "<stuff>"\n"
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
* Assumes the data has already been verified as present.
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
*/
#define RESP_PRINT_SEGMENT(_ndo, _bp, _len) \
Update ND_PRINT() as a variadic macro
2018-01-07 18:47:30 +08:00
ND_PRINT(" \""); \
Rename the fn_printX() functions to nd_printX() The functions are: nd_print, nd_printztn, nd_printn and nd_printzp. Trying to make it clearer that they currently have to be used only on part of the packet buffer. Update some comments.
2018-04-30 18:52:10 +08:00
if (nd_printn(_ndo, _bp, _len, _ndo->ndo_snapend)) \
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
goto trunc; \
fn_print_char(_ndo, '"');
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
void
resp_print(netdissect_options *ndo, const u_char *bp, u_int length)
{
int ret_len = 0, length_cur = length;
Add the ndo_protocol field in the netdissect_options structure Update this field in printer entry functions. It will be used for some printings.
2018-03-14 23:54:17 +08:00
ndo->ndo_protocol = "resp";
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
if(!bp || length <= 0)
return;
Update ND_PRINT() as a variadic macro
2018-01-07 18:47:30 +08:00
ND_PRINT(": RESP");
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
while (length_cur > 0) {
/*
* This block supports redis pipelining.
* For example, multiple operations can be pipelined within the same string:
* "*2\r\n\$4\r\nINCR\r\n\$1\r\nz\r\n*2\r\n\$4\r\nINCR\r\n\$1\r\nz\r\n*2\r\n\$4\r\nINCR\r\n\$1\r\nz\r\n"
* or
* "PING\r\nPING\r\nPING\r\n"
* In order to handle this case, we must try and parse 'bp' until
* 'length' bytes have been processed or we reach a trunc condition.
*/
ret_len = resp_parse(ndo, bp, length_cur);
TEST_RET_LEN_NORETURN(ret_len);
bp += ret_len;
length_cur -= ret_len;
}
return;
trunc:
Print truncations with nd_print_trunc() instead of tstr[] strings Remove the tstr[] strings. Update the output of some tests accordingly. Moreover: Add or update some ndo_protocol fields.
2018-05-02 23:15:04 +08:00
nd_print_trunc(ndo);
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
}
static int
Remove all storage class specifier 'register' Let the compiler do the optimizations (or not) based on build options. Avoid 'value has been optimized out' messages in gdb using '-O0'.
2017-12-14 02:17:47 +08:00
resp_parse(netdissect_options *ndo, const u_char *bp, int length)
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
{
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
u_char op;
int ret_len;
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
LCHECK2(length, 1);
Use more the ND_TCHECK_1() macro
2017-12-05 03:21:48 +08:00
ND_TCHECK_1(bp);
Use the new GET_ macros instead of the EXTRACT_ ones The exceptions are currently: Some EXTRACT_ in print-juniper.c, not used on packet buffer pointer. An EXTRACT_BE_U_3 in addrtoname.c, not always used on packet buffer pointer.
2018-06-16 23:23:21 +08:00
op = GET_U_1(bp);
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
/* bp now points to the op, so these routines must skip it */
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
switch(op) {
case RESP_SIMPLE_STRING: ret_len = resp_print_simple_string(ndo, bp, length); break;
case RESP_INTEGER: ret_len = resp_print_integer(ndo, bp, length); break;
case RESP_ERROR: ret_len = resp_print_error(ndo, bp, length); break;
case RESP_BULK_STRING: ret_len = resp_print_bulk_string(ndo, bp, length); break;
case RESP_ARRAY: ret_len = resp_print_bulk_array(ndo, bp, length); break;
default: ret_len = resp_print_inline(ndo, bp, length); break;
}
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
/*
* This gives up with a "truncated" indicator for all errors,
* including invalid packet errors; that's what we want, as
* we have to give up on further parsing in that case.
*/
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
TEST_RET_LEN(ret_len);
trunc:
return (-1);
}
static int
Remove all storage class specifier 'register' Let the compiler do the optimizations (or not) based on build options. Avoid 'value has been optimized out' messages in gdb using '-O0'.
2017-12-14 02:17:47 +08:00
resp_print_simple_string(netdissect_options *ndo, const u_char *bp, int length) {
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
return resp_print_string_error_integer(ndo, bp, length);
}
static int
Remove all storage class specifier 'register' Let the compiler do the optimizations (or not) based on build options. Avoid 'value has been optimized out' messages in gdb using '-O0'.
2017-12-14 02:17:47 +08:00
resp_print_integer(netdissect_options *ndo, const u_char *bp, int length) {
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
return resp_print_string_error_integer(ndo, bp, length);
}
static int
Remove all storage class specifier 'register' Let the compiler do the optimizations (or not) based on build options. Avoid 'value has been optimized out' messages in gdb using '-O0'.
2017-12-14 02:17:47 +08:00
resp_print_error(netdissect_options *ndo, const u_char *bp, int length) {
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
return resp_print_string_error_integer(ndo, bp, length);
}
static int
Remove all storage class specifier 'register' Let the compiler do the optimizations (or not) based on build options. Avoid 'value has been optimized out' messages in gdb using '-O0'.
2017-12-14 02:17:47 +08:00
resp_print_string_error_integer(netdissect_options *ndo, const u_char *bp, int length) {
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
int length_cur = length, len, ret_len;
const u_char *bp_ptr;
/* bp points to the op; skip it */
SKIP_OPCODE(bp, length_cur);
bp_ptr = bp;
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
/*
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
* bp now prints past the (+-;) opcode, so it's pointing to the first
* character of the string (which could be numeric).
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
* +OK\r\n
* -ERR ...\r\n
* :02912309\r\n
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
*
* Find the \r\n with FIND_CRLF().
*/
FIND_CRLF(bp_ptr, length_cur);
/*
* bp_ptr points to the \r\n, so bp_ptr - bp is the length of text
* preceding the \r\n. That includes the opcode, so don't print
* that.
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
*/
Squelch more narrowing warnings. Add an ND_BYTES_BETWEEN() macro that computes how many bytes are present, starting at the second argument and running up to (but not including) the first argument, and returns that as a u_int (cutting it to 32 bits on LP64 and LLP64 platforms). Use that, including using it as a replacement for SMB's PTR_DIFF().
2019-04-19 02:01:55 +08:00
len = ND_BYTES_BETWEEN(bp_ptr, bp);
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
RESP_PRINT_SEGMENT(ndo, bp, len);
ret_len = 1 /*<opcode>*/ + len /*<string>*/ + 2 /*<CRLF>*/;
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
TEST_RET_LEN(ret_len);
trunc:
return (-1);
}
static int
Remove all storage class specifier 'register' Let the compiler do the optimizations (or not) based on build options. Avoid 'value has been optimized out' messages in gdb using '-O0'.
2017-12-14 02:17:47 +08:00
resp_print_bulk_string(netdissect_options *ndo, const u_char *bp, int length) {
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
int length_cur = length, string_len;
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
/* bp points to the op; skip it */
SKIP_OPCODE(bp, length_cur);
/* <length>\r\n */
GET_LENGTH(ndo, length_cur, bp, string_len);
if (string_len >= 0) {
/* Byte string of length string_len, starting at bp */
if (string_len == 0)
resp_print_empty(ndo);
else {
LCHECK2(length_cur, string_len);
Replace ND_TTEST2()/ND_TCHECK2() macros by macros using pointers (1/n) ND_TTEST2(var, l) -> ND_TTEST_LEN(p, l) ND_TCHECK2(var, l) -> ND_TCHECK_LEN(p, l)
2017-12-11 19:46:51 +08:00
ND_TCHECK_LEN(bp, string_len);
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
RESP_PRINT_SEGMENT(ndo, bp, string_len);
bp += string_len;
length_cur -= string_len;
}
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
/*
* Find the \r\n at the end of the string and skip past it.
* XXX - report an error if the \r\n isn't immediately after
* the item?
*/
FIND_CRLF(bp, length_cur);
CONSUME_CRLF(bp, length_cur);
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
} else {
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
/* null, truncated, or invalid for some reason */
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
switch(string_len) {
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
case (-1): resp_print_null(ndo); break;
case (-2): goto trunc;
case (-3): resp_print_length_too_large(ndo); break;
case (-4): resp_print_length_negative(ndo); break;
default: resp_print_invalid(ndo); break;
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
}
}
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
return (length - length_cur);
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
trunc:
return (-1);
}
static int
Remove all storage class specifier 'register' Let the compiler do the optimizations (or not) based on build options. Avoid 'value has been optimized out' messages in gdb using '-O0'.
2017-12-14 02:17:47 +08:00
resp_print_bulk_array(netdissect_options *ndo, const u_char *bp, int length) {
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
u_int length_cur = length;
int array_len, i, ret_len;
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
/* bp points to the op; skip it */
SKIP_OPCODE(bp, length_cur);
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
/* <array_length>\r\n */
GET_LENGTH(ndo, length_cur, bp, array_len);
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
if (array_len > 0) {
/* non empty array */
for (i = 0; i < array_len; i++) {
ret_len = resp_parse(ndo, bp, length_cur);
TEST_RET_LEN_NORETURN(ret_len);
bp += ret_len;
length_cur -= ret_len;
}
} else {
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
/* empty, null, truncated, or invalid */
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
switch(array_len) {
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
case 0: resp_print_empty(ndo); break;
case (-1): resp_print_null(ndo); break;
case (-2): goto trunc;
case (-3): resp_print_length_too_large(ndo); break;
case (-4): resp_print_length_negative(ndo); break;
default: resp_print_invalid(ndo); break;
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
}
}
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
return (length - length_cur);
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
trunc:
return (-1);
}
static int
Remove all storage class specifier 'register' Let the compiler do the optimizations (or not) based on build options. Avoid 'value has been optimized out' messages in gdb using '-O0'.
2017-12-14 02:17:47 +08:00
resp_print_inline(netdissect_options *ndo, const u_char *bp, int length) {
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
int length_cur = length;
int len;
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
const u_char *bp_ptr;
/*
* Inline commands are simply 'strings' followed by \r or \n or both.
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
* Redis will do its best to split/parse these strings.
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
* This feature of redis is implemented to support the ability of
* command parsing from telnet/nc sessions etc.
*
* <string><\r||\n||\r\n...>
*/
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
/*
* Skip forward past any leading \r, \n, or \r\n.
*/
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
CONSUME_CR_OR_LF(bp, length_cur);
bp_ptr = bp;
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
/*
* Scan forward looking for \r or \n.
*/
FIND_CR_OR_LF(bp_ptr, length_cur);
/*
* Found it; bp_ptr points to the \r or \n, so bp_ptr - bp is the
Fix small misspellings
2019-01-24 00:28:14 +08:00
* Length of the line text that precedes it. Print it.
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
*/
Squelch more narrowing warnings. Add an ND_BYTES_BETWEEN() macro that computes how many bytes are present, starting at the second argument and running up to (but not including) the first argument, and returns that as a u_int (cutting it to 32 bits on LP64 and LLP64 platforms). Use that, including using it as a replacement for SMB's PTR_DIFF().
2019-04-19 02:01:55 +08:00
len = ND_BYTES_BETWEEN(bp_ptr, bp);
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
RESP_PRINT_SEGMENT(ndo, bp, len);
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
/*
* Skip forward past the \r, \n, or \r\n.
*/
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
CONSUME_CR_OR_LF(bp_ptr, length_cur);
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
/*
* Return the number of bytes we processed.
*/
return (length - length_cur);
Initial support for the REdis Serialization Protocol known as RESP. This commit adds support for RESP as defined in: http://redis.io/topics/protocol. It also supports inline commands and pipelining. Due to the popularity of RESP, numerous services are emerging that use this protocol. You may decode RESP packets on arbitrary ports using the "-T resp" option. Example captures can be found in tests/resp_*. A simple way to test this parser is to start redis-server and then run redis-cli commands such as "redis-cli set key value". Traditionally, redis-cli monitor is used to debug redis. Unfortunately, the "monitor" command can cause significant load on a redis-server in production. This parser may be used as a non-invasive alternative to redis-cli monitor.
2016-01-13 01:32:55 +08:00
trunc:
return (-1);
}
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
static int
Remove all storage class specifier 'register' Let the compiler do the optimizations (or not) based on build options. Avoid 'value has been optimized out' messages in gdb using '-O0'.
2017-12-14 02:17:47 +08:00
resp_get_length(netdissect_options *ndo, const u_char *bp, int len, const u_char **endp)
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
{
int result;
u_char c;
int saw_digit;
int neg;
int too_large;
if (len == 0)
goto trunc;
Use more the ND_TCHECK_1() macro
2017-12-05 03:21:48 +08:00
ND_TCHECK_1(bp);
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
too_large = 0;
neg = 0;
Use the new GET_ macros instead of the EXTRACT_ ones The exceptions are currently: Some EXTRACT_ in print-juniper.c, not used on packet buffer pointer. An EXTRACT_BE_U_3 in addrtoname.c, not always used on packet buffer pointer.
2018-06-16 23:23:21 +08:00
if (GET_U_1(bp) == '-') {
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
neg = 1;
bp++;
len--;
}
result = 0;
saw_digit = 0;
for (;;) {
if (len == 0)
goto trunc;
Use more the ND_TCHECK_1() macro
2017-12-05 03:21:48 +08:00
ND_TCHECK_1(bp);
Use the new GET_ macros instead of the EXTRACT_ ones The exceptions are currently: Some EXTRACT_ in print-juniper.c, not used on packet buffer pointer. An EXTRACT_BE_U_3 in addrtoname.c, not always used on packet buffer pointer.
2018-06-16 23:23:21 +08:00
c = GET_U_1(bp);
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
if (!(c >= '0' && c <= '9')) {
CVE-2017-12989/RESP: Make sure resp_get_length() advances the pointer for invalid lengths. Make sure that it always sends *endp before returning and that, for invalid lengths where we don't like a character in the length string, what it sets *endp to is past the character in question, so we don't run the risk of infinitely looping (or doing something else random) if a character in the length is invalid. This fixes an infinite loop discovered by Forcepoint's security researchers Otto Airamo & Antti Levomäki. Add a test using the capture file supplied by the reporter(s).
2017-02-07 16:13:33 +08:00
if (!saw_digit) {
bp++;
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
goto invalid;
CVE-2017-12989/RESP: Make sure resp_get_length() advances the pointer for invalid lengths. Make sure that it always sends *endp before returning and that, for invalid lengths where we don't like a character in the length string, what it sets *endp to is past the character in question, so we don't run the risk of infinitely looping (or doing something else random) if a character in the length is invalid. This fixes an infinite loop discovered by Forcepoint's security researchers Otto Airamo & Antti Levomäki. Add a test using the capture file supplied by the reporter(s).
2017-02-07 16:13:33 +08:00
}
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
break;
}
c -= '0';
if (result > (INT_MAX / 10)) {
/* This will overflow an int when we multiply it by 10. */
too_large = 1;
} else {
result *= 10;
RESP: Fix overflow check. At that point, result is a multiple of 10, so it can at most be 2147483640, i.e. (INT_MAX / 10)*10. If it's less than that, you can add any value between 0 and 9 to it and it won't overflow. If it's *equal* to that, you can only add a value between 0 and 7 without overflowing, i.e. the maximum is INT_MAX % 10. Addresses Coverity CID 1400557.
2017-02-16 07:43:46 +08:00
if (result == ((INT_MAX / 10) * 10) && c > (INT_MAX % 10)) {
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
/* This will overflow an int when we add c */
too_large = 1;
} else
result += c;
}
bp++;
len--;
saw_digit = 1;
}
/*
RESP: Remove some redundant checks. Before we break out of the loop, we've already checked for those conditions. No need to check for them again. This fixes Coverity CIDs 1400553 and 1400554.
2017-02-16 05:22:41 +08:00
* OK, we found a non-digit character. It should be a \r, followed
* by a \n.
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
*/
Use the new GET_ macros instead of the EXTRACT_ ones The exceptions are currently: Some EXTRACT_ in print-juniper.c, not used on packet buffer pointer. An EXTRACT_BE_U_3 in addrtoname.c, not always used on packet buffer pointer.
2018-06-16 23:23:21 +08:00
if (GET_U_1(bp) != '\r') {
CVE-2017-12989/RESP: Make sure resp_get_length() advances the pointer for invalid lengths. Make sure that it always sends *endp before returning and that, for invalid lengths where we don't like a character in the length string, what it sets *endp to is past the character in question, so we don't run the risk of infinitely looping (or doing something else random) if a character in the length is invalid. This fixes an infinite loop discovered by Forcepoint's security researchers Otto Airamo & Antti Levomäki. Add a test using the capture file supplied by the reporter(s).
2017-02-07 16:13:33 +08:00
bp++;
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
goto invalid;
CVE-2017-12989/RESP: Make sure resp_get_length() advances the pointer for invalid lengths. Make sure that it always sends *endp before returning and that, for invalid lengths where we don't like a character in the length string, what it sets *endp to is past the character in question, so we don't run the risk of infinitely looping (or doing something else random) if a character in the length is invalid. This fixes an infinite loop discovered by Forcepoint's security researchers Otto Airamo & Antti Levomäki. Add a test using the capture file supplied by the reporter(s).
2017-02-07 16:13:33 +08:00
}
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
bp++;
len--;
if (len == 0)
goto trunc;
Use more the ND_TCHECK_1() macro
2017-12-05 03:21:48 +08:00
ND_TCHECK_1(bp);
Use the new GET_ macros instead of the EXTRACT_ ones The exceptions are currently: Some EXTRACT_ in print-juniper.c, not used on packet buffer pointer. An EXTRACT_BE_U_3 in addrtoname.c, not always used on packet buffer pointer.
2018-06-16 23:23:21 +08:00
if (GET_U_1(bp) != '\n') {
CVE-2017-12989/RESP: Make sure resp_get_length() advances the pointer for invalid lengths. Make sure that it always sends *endp before returning and that, for invalid lengths where we don't like a character in the length string, what it sets *endp to is past the character in question, so we don't run the risk of infinitely looping (or doing something else random) if a character in the length is invalid. This fixes an infinite loop discovered by Forcepoint's security researchers Otto Airamo & Antti Levomäki. Add a test using the capture file supplied by the reporter(s).
2017-02-07 16:13:33 +08:00
bp++;
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
goto invalid;
CVE-2017-12989/RESP: Make sure resp_get_length() advances the pointer for invalid lengths. Make sure that it always sends *endp before returning and that, for invalid lengths where we don't like a character in the length string, what it sets *endp to is past the character in question, so we don't run the risk of infinitely looping (or doing something else random) if a character in the length is invalid. This fixes an infinite loop discovered by Forcepoint's security researchers Otto Airamo & Antti Levomäki. Add a test using the capture file supplied by the reporter(s).
2017-02-07 16:13:33 +08:00
}
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
bp++;
len--;
*endp = bp;
if (neg) {
/* -1 means "null", anything else is invalid */
if (too_large || result != 1)
return (-4);
result = -1;
}
return (too_large ? -3 : result);
trunc:
CVE-2017-12989/RESP: Make sure resp_get_length() advances the pointer for invalid lengths. Make sure that it always sends *endp before returning and that, for invalid lengths where we don't like a character in the length string, what it sets *endp to is past the character in question, so we don't run the risk of infinitely looping (or doing something else random) if a character in the length is invalid. This fixes an infinite loop discovered by Forcepoint's security researchers Otto Airamo & Antti Levomäki. Add a test using the capture file supplied by the reporter(s).
2017-02-07 16:13:33 +08:00
*endp = bp;
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
return (-2);
invalid:
CVE-2017-12989/RESP: Make sure resp_get_length() advances the pointer for invalid lengths. Make sure that it always sends *endp before returning and that, for invalid lengths where we don't like a character in the length string, what it sets *endp to is past the character in question, so we don't run the risk of infinitely looping (or doing something else random) if a character in the length is invalid. This fixes an infinite loop discovered by Forcepoint's security researchers Otto Airamo & Antti Levomäki. Add a test using the capture file supplied by the reporter(s).
2017-02-07 16:13:33 +08:00
*endp = bp;
Do better checking of RESP packets. Don't call strtol() on the contents of a packet; there is *no* guarantee that it won't run past the end of the buffer, as the buffer isn't a null-terminated string. Instead, have our own routine to parse ASCII numbers (based on the FreeBSD strtol()), which uses ND_TCHECK() and checks against the on-the-wire length to ensure it doesn't go past the end of the packet or the end of the captured data. Have it check for other errors as well, such as checking for negative lengths that aren't -1. Clean up other aspects of the packet parsing. Have them check the on-the-wire length as well as the captured length. Update the results of the resp_3 test.
2016-10-28 03:22:54 +08:00
return (-5);
}
Reference in New Issue Copy Permalink