Bug #7406
closedassertion error: Configuration::matchEntryPoint line 708
0%
Description
assertions in main code may not be a good thing? may need to come up with an appropriate decode recovery.
maybe an error '400 Bad Request' is appropriate?
Packet content:
09:47:02.969906 IP 45.143.220.157.64961 > 63.85.43.206.http: Flags [P.], seq 1:340, ack 1, win 513, length 339: HTTP: GET http://www.msftncsi.com/ncsi.txt HTTP/1.1
0x0000: 4500 017b 0db2 4000 7606 807b 2d8f dc9d E..{..@.v..{-...
0x0010: 3f55 2bce fdc1 0050 4fb0 1e2c 5c2a 8e43 ?U+....PO..,\*.C
0x0020: 5018 0201 9c71 0000 4745 5420 6874 7470 P....q..GET.http
0x0030: 3a2f 2f77 7777 2e6d 7366 746e 6373 692e ://www.msftncsi.
0x0040: 636f 6d2f 6e63 7369 2e74 7874 2048 5454 com/ncsi.txt.HTT
0x0050: 502f 312e 310d 0a48 6f73 743a 2077 7777 P/1.1..Host:.www
0x0060: 2e6d 7366 746e 6373 692e 636f 6d0d 0a41 .msftncsi.com..A
0x0070: 6363 6570 743a 2074 6578 742f 6874 6d6c ccept:.text/html
0x0080: 2c61 7070 6c69 6361 7469 6f6e 2f78 6874 ,application/xht
0x0090: 6d6c 2b78 6d6c 2c61 7070 6c69 6361 7469 ml+xml,applicati
0x00a0: 6f6e 2f78 6d6c 3b71 3d30 2e39 2c2a 2f2a on/xml;q=0.9,*/*
0x00b0: 3b71 3d30 2e38 0d0a 4163 6365 7074 2d45 ;q=0.8..Accept-E
0x00c0: 6e63 6f64 696e 673a 2064 6566 6c61 7465 ncoding:.deflate
0x00d0: 2c20 677a 6970 2c20 6964 656e 7469 7479 ,.gzip,.identity
0x00e0: 0d0a 4163 6365 7074 2d4c 616e 6775 6167 ..Accept-Languag
0x00f0: 653a 2065 6e2d 5553 3b71 3d30 2e36 2c65 e:.en-US;q=0.6,e
0x0100: 6e3b 713d 302e 340d 0a52 6566 6572 6572 n;q=0.4..Referer
0x0110: 3a20 6874 7470 3a2f 2f36 332e 3835 2e34 :.http://63.85.4
0x0120: 332e 3230 362f 0d0a 5573 6572 2d41 6765 3.206/..User-Age
0x0130: 6e74 3a20 4d6f 7a69 6c6c 612f 352e 3020 nt:.Mozilla/5.0.
0x0140: 2857 696e 646f 7773 204e 5420 352e 313b (Windows.NT.5.1;
0x0150: 2072 763a 392e 302e 3129 2047 6563 6b6f .rv:9.0.1).Gecko
0x0160: 2f32 3031 3030 3130 3120 4669 7265 666f /20100101.Firefo
0x0170: 782f 392e 302e 310d 0a0d 0a x/9.0.1....
debug inspection:
AppOneUnifiedNetLimited: /home/rpb/data/projects/libs-build/wt/src/web/Configuration.C:708: Wt::EntryPointMatch Wt::Configuration::matchEntryPoint(const string&, const string&, bool) const: Assertion `path.empty() || path[0] == '/'' failed.
Thread 10 "AppOneUnifiedNe" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffe9ffb700 (LWP 24888)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) info stack 10
#0 0x00007ffff62df081 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007ffff62ca535 in __GI_abort () at abort.c:79
#2 0x00007ffff62ca40f in __assert_fail_base
(fmt=0x7ffff642c710 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7ffff7c0f7f8 "path.empty() || path[0] == '/'", file=0x7ffff7c0f738 "/home/rpb/data/projects/libs-build/wt/src/web/Configuration.C", line=708, function=<optimized out>)
at assert.c:92
#3 0x00007ffff62d7b92 in __GI___assert_fail
(assertion=0x7ffff7c0f7f8 "path.empty() || path[0] == '/'", file=0x7ffff7c0f738 "/home/rpb/data/projects/libs-build/wt/src/web/Configuration.C", line=708, function=0x7ffff7c0f790 "Wt::EntryPointMatch Wt::Configuration::matchEntryPoint(const string&, const string&, bool) const") at assert.c:101
#4 0x00007ffff7a8ac1b in Wt::Configuration::matchEntryPoint(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool) const
(this=0x55555577b950, scriptName="", path="http://www.msftncsi.com/ncsi.txt", matchAfterSlash=true) at /home/rpb/data/projects/libs-build/wt/src/web/Configuration.C:708
#5 0x00007ffff6cde4e2 in http::server::RequestHandler::handleRequest(http::server::Request&, std::shared_ptr<http::server::Reply>&, std::shared_ptr<http::server::Reply>&, std::shared_ptr<http::server::Reply>&)
(this=0x5555557973c8, req=..., lastWtReply=std::shared_ptr<class http::server::Reply> (empty) = {...}, lastProxyReply=std::shared_ptr<class http::server::Reply> (empty) = {...}, lastStaticReply=std::shared_ptr<class http::server::Reply> (empty) = {...}) at /home/rpb/data/projects/libs-build/wt/src/http/RequestHandler.C:109
#6 0x00007ffff6c95408 in http::server::Connection::handleReadRequest0() (this=0x7fffc00248b0) at /home/rpb/data/projects/libs-build/wt/src/http/Connection.C:221
#7 0x00007ffff6c95ad7 in http::server::Connection::handleReadRequest(boost::system::error_code const&, unsigned long) (this=0x7fffc00248b0, e=..., bytes_transferred=339) at /home/rpb/data/projects/libs-build/wt/src/http/Connection.C:264
#8 0x00007ffff6d4ea87 in std::__invoke_impl<void, void (http::server::Connection::*&)(boost::system::error_code const&, unsigned long), std::shared_ptr<http::server::TcpConnection>&, boost::system::error_code const&, unsigned long const&>(std::__invoke_memfun_deref, void (http::server::Connection::*&)(boost::system::error_code const&, unsigned long), std::shared_ptr<http::server::TcpConnection>&, boost::system::error_code const&, unsigned long const&) (__f=
@0x7fffe9ff90c0: (void (http::server::Connection::*)(class http::server::Connection * const, const class boost::system::error_code &, unsigned long)) 0x7ffff6c95a64 <http::server::Connection::handleReadRequest(boost::system::error_code const&, unsigned long)>, __t=std::shared_ptr<class http::server::TcpConnection> (use count 4, weak count 1) = {...}) at /usr/include/c++/9/bits/invoke.h:73
#9 0x00007ffff6d4e9c1 in std::__invoke<void (http::server::Connection::*&)(boost::system::error_code const&, unsigned long), std::shared_ptr<http::server::TcpConnection>&, boost::system::error_code const&, unsigned long const&>(void (http::server::Connection::*&)(boost::system::error_code const&, unsigned long), std::shared_ptr<http::server::TcpConnection>&, boost::system::error_code const&, unsigned long const&) (__fn=
@0x7fffe9ff90c0: (void (http::server::Connection::*)(class http::server::Connection * const, const class boost::system::error_code &, unsigned long)) 0x7ffff6c95a64 <http::server::Connection::handleReadRequest(boost::system::error_code const&, unsigned long)>) at /usr/include/c++/9/bits/invoke.h:95
(More stack frames follow...)
(gdb) frame 4
#4 0x00007ffff7a8ac1b in Wt::Configuration::matchEntryPoint (this=0x55555577b950, scriptName="", path="http://www.msftncsi.com/ncsi.txt", matchAfterSlash=true) at /home/rpb/data/projects/libs-build/wt/src/web/Configuration.C:708
Updated by Ray . over 4 years ago
Another flavour of the same thing:
22:48:21.827240 IP 194.180.224.249.42562 > 63.85.43.206.http: Flags [P.], seq 1:134, ack 1, win 502, options [nop,nop,TS val 2169255265 ecr 2166905358], length 133: HTTP: GET http://194.180.224.249 HTTP/1.1
0x0000: 4500 00b9 d8ad 4000 3406 5ec0 c2b4 e0f9 E.....@.4.^.....
0x0010: 3f55 2bce a642 0050 e7fc 5e69 a9ce cdcf ?U+..B.P..^i....
0x0020: 8018 01f6 7c3a 0000 0101 080a 814c 3561 ....|:.......L5a
0x0030: 8128 5a0e 4745 5420 6874 7470 3a2f 2f31 .(Z.GET.http://1
0x0040: 3934 2e31 3830 2e32 3234 2e32 3439 2048 94.180.224.249.H
0x0050: 5454 502f 312e 310d 0a41 6363 6570 742d TTP/1.1..Accept-
0x0060: 456e 636f 6469 6e67 3a20 6964 656e 7469 Encoding:.identi
0x0070: 7479 0d0a 486f 7374 3a20 3139 342e 3138 ty..Host:.194.18
0x0080: 302e 3232 342e 3234 390d 0a43 6f6e 6e65 0.224.249..Conne
0x0090: 6374 696f 6e3a 2063 6c6f 7365 0d0a 5573 ction:.close..Us
0x00a0: 6572 2d41 6765 6e74 3a20 4d6f 7a69 6c6c er-Agent:.Mozill
0x00b0: 612f 352e 300d 0a0d 0a a/5.0....
Yeah, my site seems to be a magnet for ne'er-do-wells. But it does give your code some exercise!
Updated by Roel Standaert over 4 years ago
I put that assertion there because our code should've made sure that doesn't happen.
I think the strange thing here is this: path="http://www.msftncsi.com/ncsi.txt"
. It's including the scheme and hostname.
Updated by Ray . over 4 years ago
I don't know what the intent here was by the sender. And the Get with a non-leading / is non-typical, and not expected by my particular web site, but we have to be ready to process what ever arrives.
Do you have a way of turning this into a 400 return?
Updated by Roel Standaert over 4 years ago
Yeah, I think it should return a 400 response, but I'll have to make sure it does that somewhere else. That's not matchEntryPoint
's responsibility.
Updated by Ray . over 4 years ago
Roel: do you have some sort of fix for this? or workaround I can insert for the time being? I get regular breakage on this.
Updated by Roel Standaert over 4 years ago
I was inclined to reject requests that were not in origin form (RFC 7230 5.3.1), were it not that it says this under 5.3.2. absolute form:
To allow for transition to the absolute-form for all requests in some future version of HTTP, a server MUST accept the absolute-form in requests, even though HTTP/1.1 clients will only send them in requests to proxies.
If you want to patch it quickly, it's just a matter of returning bad_request
in RequestHandler::handleRequest
after url_decode
if req.request_path
doesn't start with /
.
Updated by Roel Standaert over 4 years ago
I pushed a commit rejecting the absolute form for now.
Updated by Ray . over 4 years ago
Thank you. I am running the new code. It make take several days for the code to trigger.