DoS/Segfault when request path contains more than 387 characters

[Bendr0id]

Due to that someone reported a crash on my app when passing very long parameters to the server i did some deeper investigation.

It turns out that this is happening in httplib.

So i tried a bit and was able to verify my finding even with your example server.cc code.

This is the env im using:

alpine64:~# g++ --version
g++ (Alpine 10.2.1_pre1) 10.2.1 20201203

With a not to long path everyting works as expected.

alpine64:~# g++ server.cc -I. -g -o server
alpine64:~# ./server
================================
GET HTTP/1.1 /tinypath
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: de,en-US;q=0.9,en;q=0.8,es;q=0.7
Connection: keep-alive
DNT: 1
Host: 192.168.0.36:8080
REMOTE_ADDR: 192.168.0.55
REMOTE_PORT: 49466
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36
--------------------------------
404 HTTP/1.1
Content-Length: 56
Content-Type: text/html
Keep-Alive: timeout=5, max=5

<p>Error Status: <span style='color:red;'>404</span></p>

But using this request it segfaults.

http://192.168.0.36:8080/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbccccccccccccccddddddddddddddddddddddeeeeeeeeeeeeeeeeeeefffffffffffffffffffffffffffffffffffggggggggggggggggggggggggggggg

alpine64:~# ./server
Segmentation fault (core dumped)

Even without printing the headers.

The segfault is happening somewhere here:

#2023 0x00005610ffe76a3c in std::regex_match<char, std::allocator<std::__cxx11::sub_match<char const*> >, std::__cxx11::regex_traits<char> > (__s=0x7f98b1e29e70 "GET /", 'a' <repeats 195 times>..., __m=..., __re=..., __f=0) at /usr/include/c++/10.2.1/bits/regex.h:2229
#2024 0x00005610ffe6d552 in httplib::Server::parse_request_line (this=0x7fff357a30e0, s=0x7f98b1e29e70 "GET /", 'a' <repeats 195 times>..., req=...) at ./httplib.h:4528

CoreDump is attached.

core.log

I'm somehow not able to reproduce this on my Arch, Debian and Ubuntu machine. It might be GCC version related or that alpine is using musl instead of libc. But the binary produced on alpine executed on Debian/Ubuntu/Arch crashs there too with the large request.

Thanks in advance

[Bendr0id]

Additional note: it seems to be g++ unrelated. Same happens using clang-10.

[Bendr0id]

The RFC7230 doesn't define limit size of the Target. It only claims this:

HTTP does not place a predefined limit on the length of a
   request-line, as described in Section 2.5.  A server that receives a
   method longer than any that it implements SHOULD respond with a 501
   (Not Implemented) status code.  A server that receives a





Fielding & Reschke           Standards Track                   [Page 21]

RFC 7230           HTTP/1.1 Message Syntax and Routing         June 2014


   request-target longer than any URI it wishes to parse MUST respond
   with a 414 (URI Too Long) status code (see Section 6.5.12 of
   [RFC7231]).

   Various ad hoc limitations on request-line length are found in
   practice.  It is RECOMMENDED that all HTTP senders and recipients
   support, at a minimum, request-line lengths of 8000 octets.

But we are far away from that 1k characters.

[yhirose]

@Bendr0id, thank you for the fine report! I would like to clarify the condition. So does only binary produced on alpine OS cause the problem, right? Also do you think if #832 relates to this issue?

Here is the code where the crash is happening. Line number is 4528.

cpp-httplib/httplib.h

Lines 4522 to 4532 in 80be649

	inline bool Server::parse_request_line(const char *s, Request &req) {
	const static std::regex re(
	"(GET|HEAD|POST|PUT|DELETE|CONNECT|OPTIONS|TRACE|PATCH|PRI) "
	"(([^? ]+)(?:\\?([^ ]*?))?) (HTTP/1\\.[01])\r\n");
	std::cmatch m;
	if (std::regex_match(s, m, re)) {
	req.version = std::string(m[5]);
	req.method = std::string(m[1]);
	req.target = std::string(m[2]);
	req.path = detail::decode_url(m[3], false);

It seems like the std::regex implementation in toolchain on alpine OS has a serious problem.
I have only Mac and Windows machines, and wonder how I can reproduce this problem on my machine...
Anyway, I appreciate any further information regarding this. Thanks!

[Bendr0id]

I added some logging for debugging and the crash is happening in the regex_match.
Its not entering the if statement.

[Bendr0id]

This somehow just works flawlessly:

#include <iostream>
#include <string>
#include <regex>

int main()
{
  std::string s = "GET /aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaannnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnasssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss

  std::regex re(
      "(GET|HEAD|POST|PUT|DELETE|CONNECT|OPTIONS|TRACE|PATCH|PRI) "
      "(([^? ]+)(?:\\?([^ ]*?))?) (HTTP/1\\.[01])\r\n");

  std::cmatch m;
  if (std::regex_match(s.c_str(), m, re)) {
    auto version = std::string(m[5]);
    auto method = std::string(m[1]);
    auto target = std::string(m[2]);

    std::cout << "\n version: " << version << "\n method: " << method << "\n target: " << target << "\n";
  }
  else {
    std::cout << "match failed!\n";
  }

  return 0;
}

alpine64:~# g++ test.cpp -o test && ./test

version: HTTP/1.1
method: GET
target: /aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaannnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnassssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaar

[Bendr0id]

So i'm wondering if that it might be due to the buf beeing used for linereader?

[Bendr0id]

The code mentioned in #832 works fine too.

alpine64:~# g++ test2.cpp -o test2 && ./test2
HTTP/1.1:200:OK

[yhirose]

Thanks for the further investigation. Could you add the following debug lines to right before line 4528 in httplib.h on your alpine OS machine and see what values you will get?

   std::cmatch m; 
   std::cout << "len: " << s.length() << std::endl; // Add
   std::cout << ">>>" << s << "<<<" << std::endl; // Add
   if (std::regex_match(s, m, re)) { 

[Bendr0id]

Here is a docker container for you to test:

FROM alpine:3.13

RUN apk add --no-cache git make cmake libstdc++ gcc g++ automake libtool autoconf linux-headers && \
    rm -rf /var/lib/apt/lists/*

RUN wget https://raw.githubusercontent.com/yhirose/cpp-httplib/master/httplib.h && \
    wget https://raw.githubusercontent.com/yhirose/cpp-httplib/master/example/server.cc && \
    sed -i 's/localhost/0.0.0.0/g' server.cc && \
    cat server.cc && \
    g++ server.cc -I. -g -o server

ENTRYPOINT  ["/server"]

Put that into a file called Dockerfile

Then Build the image (whenever you change something to the docker file):
docker build -t httplib-test:latest .

Once this is done you can always start the container with:
docker run -d --rm -p 8080:8080 --rm httplib-test:latest

When the server crashs, it will remove the docker container. And you can rerun it.

It will start your test server.cc on 0.0.0.0:8080

[yhirose]

I'll try to reproduce the problem accordingly this weekend. Thanks!

[Bendr0id]

If you want to modify something on httplib.h just get an interactive docker shell by using this:

docker run -it --entrypoint /bin/bash --rm -p 8080:8080 --rm httplib-test:latest

Vim is available in the env.

[Bendr0id]

Workaround is to limit the max uri length:

#define CPPHTTPLIB_REQUEST_URI_MAX_LENGTH 300

[yhirose]

@Bendr0id, I did some research, and it turns out that the server accepts up to 396 characters on my machine. But if I compile with -O3, it now accepts up to 436 characters. It seem like it's a stack overflow problem. It might be related to this stackoverflow post.

Anyway, operating systems with small stack size have the problem. Could you for now take the workaround that you suggests with CPPHTTPLIB_REQUEST_URI_MAX_LENGTH ?

In order to fix this problem completely, I guess I need to give up using std::regex, and come up with a better way to parse the request line. I'll get back to you when I find a good solution. Thanks for your help.

[PixlRainbow]

this bug is being fixed in GCC with a full re-implementation of std::regex based on a different algorithm, but it is not complete yet. It is uncertain how long it will take, but it has already been 2-3 years