test/fuzz: frame replay style testing and fuzzing for HTTP/2 headers.#6491
test/fuzz: frame replay style testing and fuzzing for HTTP/2 headers.#6491htuch merged 5 commits intoenvoyproxy:masterfrom
Conversation
In the fix patch for CVE-2019-9900, we introduced some basic HTTP/2 manual fuzzing, where single bytes were corrupted in a HEADERS frame, to attempt to show that NUL/CR/LF were handled. However, testing that relies on codec_impl_test has nghttp2 as both client and server. This implies that Huffman coding may be present, and single byte corruptions of 0x00 don't imply a NUL for example. In this patch, we take a more principled approach and use artisinal HEADERS frames that have no Huffman or dynamic table compression to validate the above single byte corruption property. A nice side effect of this is that we can derived from this infrastructure stateless request/response HEADERS fuzzers that can cover uncompressed (specifically no Huffman) paths, which is more likely to provide a direct access to nghttp2 codec header sanitization logic. Risk level: Low Testing: Unit tests and ran both fuzzers under oss-fuzz Docker image. Seems reasonably fast and no crashes locally. Signed-off-by: Harvey Tuch <htuch@google.com>
|
Friendly ping. |
| TEST_F(RequestFrameCommentTest, SingleByteNulCrLfInHeaderField) { | ||
| FileFrame header{"request_header_corpus/simple_example_plain"}; | ||
|
|
||
| for (size_t offset = header.frame().size() - 11 /* foo: offset */; offset < header.frame().size(); |
There was a problem hiding this comment.
Why not try to corrupt the whole frame?
There was a problem hiding this comment.
The above test SingleByteNulCrLfInHeaderFrame does this. The idea in this test is that we explicitly expect an exception. If you corrupt some bytes in a frame with NUL, it will have no effect and more or less parse correctly, e.g. those bytes that are already NUL :)
mattklein123
left a comment
There was a problem hiding this comment.
LGTM from a skim and very neat. Can you add some comments somewhere on how you generated all the magic byte strings that are in this PR? Did you use tcpdump or some other mechanism? Thank you.
/wait
|
@mattklein123 I basically added hexdump to |
Probably not, but I think a comment would be very helpful. |
Signed-off-by: Harvey Tuch <htuch@google.com>
In the fix patch for CVE-2019-9900, we introduced some basic HTTP/2
manual fuzzing, where single bytes were corrupted in a HEADERS frame, to
attempt to show that NUL/CR/LF were handled. However, testing that
relies on codec_impl_test, which has nghttp2 as both client and server. This
implies that Huffman coding may be present, and single byte corruptions
of 0x00 don't imply a NUL for example.
In this patch, we take a more principled approach and use artisinal
HEADERS frames that have no Huffman or dynamic table compression to
validate the above single byte corruption property.
A nice side effect of this is that we can derived from this
infrastructure stateless request/response HEADERS fuzzers that can cover
uncompressed (specifically no Huffman) paths, which is more likely to
provide a direct access to nghttp2 codec header sanitization logic.
Risk level: Low
Testing: Unit tests and ran both fuzzers under oss-fuzz Docker image.
Seems reasonably fast and no crashes locally.
Signed-off-by: Harvey Tuch htuch@google.com