Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
operating system:Mac Sierra 10.12.6
when i change nmap version to 7.4, We can obtain normal result。
Thanks for the bug report! It would be helpful to have the core dump file from the crash. Also, can you try using the
Apart from this, the output from this command with
(EDITED to fix link to stackoverflow question regarding OS X core dumps)
Ok, I've successfully reproduced this bug. Whatever the service is, it responds to some probes (
Specifically, we're getting into a really deep recursion in trying to match that "any number of single characters not followed by '\r\n\r\n'" group. I don't quite understand why it's recursing; we used this pattern in a lot of places to match "some number of HTTP headers, but not the message body." And it's only affecting some versions of libpcre, including the one Nmap includes in its source tree. Apparently #1108 shows the same crash affecting CentOS.
I'm going to try some things to improve the performance of these match lines, but the better solution might be to upgrade libpcre. Here are some workarounds for now:
Thanks for reporting!
Ok, I figured out a good solution for now: we need to make these groups non-greedy.
Our intent was to allow the patterns to match within the headers only, and stop when they get to the end of the headers. This is because the body of a HTTP response could be quite large, and we'd like to fail quickly. But what was actually happening is that the regex engine was seeing the greedy
To take the example from before, this is the new match line:
Note the addition of the