New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nmap7.60 crash in libpcre.so when scan service #1108

Closed
liteway opened this Issue Jan 17, 2018 · 4 comments

Comments

Projects
None yet
2 participants
@liteway

liteway commented Jan 17, 2018

In centos7, use nmap 7.60(x64) scan os fingerprint may be lead to crash for some specific ip ports.
repreduction step:
execute following cmd, if has no crash, please try more times.
./nmap 112.17.252.38 -sT -sV -Pn -n -p82 -O

the crash backtrace is as follows:
0 0x00007ffff7b8d7ca in match () from /lib64/libpcre.so.1
1 0x00007ffff7b8e17f in match () from /lib64/libpcre.so.1
2 0x00007ffff7b9b40a in match () from /lib64/libpcre.so.1

@dmiller-nmap

This comment has been minimized.

Show comment
Hide comment
@dmiller-nmap

dmiller-nmap Jan 21, 2018

I cannot reproduce this on CentOS 7.4.1708 with libpcre 8.32. Since the crash is in libpcre, you may have a corrupted libpcre.so, which you can diagnose by running rpm -V pcre. If you still believe there is a problem with Nmap, please provide output of nmap --version and debugging output: nmap -sV -Pn -n -d --version-trace -p82

OS detection does not use libpcre, so the crash is not related to that.

dmiller-nmap commented Jan 21, 2018

I cannot reproduce this on CentOS 7.4.1708 with libpcre 8.32. Since the crash is in libpcre, you may have a corrupted libpcre.so, which you can diagnose by running rpm -V pcre. If you still believe there is a problem with Nmap, please provide output of nmap --version and debugging output: nmap -sV -Pn -n -d --version-trace -p82

OS detection does not use libpcre, so the crash is not related to that.

@liteway

This comment has been minimized.

Show comment
Hide comment
@liteway

liteway Jan 29, 2018

Thanks for your reply. I'm sorry, it's not crashed in os detection, but in service scan, it will still crash without -O. I guess the root cause is improper regex leads stack overflow in pcre match method, and this may lead some security issue. The crash doesn't appear stably, you can reproduce by multiple attempt. The old nmap(7.12) has no this issue, The stack info and version info is as follows.

The complete crash stack is:
#16882 0x00007fca09b4d40a in match () from /lib64/libpcre.so.1
#16883 0x00007fca09b4d40a in match () from /lib64/libpcre.so.1
#16884 0x00007fca09b413fc in match () from /lib64/libpcre.so.1
#16885 0x00007fca09b50c29 in pcre_exec () from /lib64/libpcre.so.1
#16886 0x00000000004985ca in ServiceProbeMatch::testMatch (this=0x3e628d0,
buf=buf@entry=0x420bfe0 "HTTP/1.1 403 Forbidden\nContent-Type: text/html\nContent-Length: 29120\n\n\n\n\n<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />\n<title>Error</title>\n<style ty"...,
buflen=buflen@entry=29190) at service_scan.cc:564
#16887 0x0000000000498e96 in ServiceProbe::testMatch (this=0x3b20250,
buf=buf@entry=0x420bfe0 "HTTP/1.1 403 Forbidden\nContent-Type: text/html\nContent-Length: 29120\n\n\n\n\n<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />\n<title>Error</title>\n<style ty"..., buflen=29190,
n=n@entry=0) at service_scan.cc:1435
#16888 0x000000000049af8e in servicescan_read_handler (nsp=0x41f3060, nse=, mydata=0x41f2cb0) at service_scan.cc:2436
#16889 0x00000000004cac68 in event_dispatch_and_delete (nsp=nsp@entry=0x41f3060, nse=nse@entry=0x41f45e0, notify=notify@entry=1) at nsock_event.c:373
#16890 0x00000000004c80ae in process_event (nsp=nsp@entry=0x41f3060, evlist=evlist@entry=0x41f3090, nse=nse@entry=0x41f45e0, ev=ev@entry=1) at nsock_core.c:1058
#16891 0x00000000004c8565 in process_iod_events (nsp=nsp@entry=0x41f3060, nsi=nsi@entry=0x41f52b0, ev=1) at nsock_core.c:1123
#16892 0x00000000004cd65d in iterate_through_event_lists (evcount=1, nsp=0x41f3060) at engine_epoll.c:345
#16893 epoll_loop (nsp=0x41f3060, msec_timeout=) at engine_epoll.c:312
#16894 0x00000000004c7ef3 in nsock_engine_loop (msec_timeout=-1, nsp=0x41f3060) at nsock_internal.h:431
#16895 nsock_loop (nsp=0x41f3060, msec_timeout=-1) at nsock_core.c:926
#16896 0x000000000049cdfc in service_scan (Targets=std::vector of length 1, capacity 100 = {...}) at service_scan.cc:2801
#16897 0x000000000046060d in nmap_main (argc=argc@entry=7, argv=argv@entry=0x7ffc51d5f078) at nmap.cc:2209
#16898 0x0000000000434096 in main (argc=7, argv=0x7ffc51d5f078) at main.cc:237

This is my nmap version info:
Nmap version 7.60 ( https://nmap.org )
Platform: x86_64-unknown-linux-gnu
Compiled with: nmap-liblua-5.3.3 openssl-1.0.1e nmap-libssh2-1.8.0 libz-1.2.8 libpcre-8.32 nmap-libpcap-1.7.3 nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: epoll poll select

liteway commented Jan 29, 2018

Thanks for your reply. I'm sorry, it's not crashed in os detection, but in service scan, it will still crash without -O. I guess the root cause is improper regex leads stack overflow in pcre match method, and this may lead some security issue. The crash doesn't appear stably, you can reproduce by multiple attempt. The old nmap(7.12) has no this issue, The stack info and version info is as follows.

The complete crash stack is:
#16882 0x00007fca09b4d40a in match () from /lib64/libpcre.so.1
#16883 0x00007fca09b4d40a in match () from /lib64/libpcre.so.1
#16884 0x00007fca09b413fc in match () from /lib64/libpcre.so.1
#16885 0x00007fca09b50c29 in pcre_exec () from /lib64/libpcre.so.1
#16886 0x00000000004985ca in ServiceProbeMatch::testMatch (this=0x3e628d0,
buf=buf@entry=0x420bfe0 "HTTP/1.1 403 Forbidden\nContent-Type: text/html\nContent-Length: 29120\n\n\n\n\n<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />\n<title>Error</title>\n<style ty"...,
buflen=buflen@entry=29190) at service_scan.cc:564
#16887 0x0000000000498e96 in ServiceProbe::testMatch (this=0x3b20250,
buf=buf@entry=0x420bfe0 "HTTP/1.1 403 Forbidden\nContent-Type: text/html\nContent-Length: 29120\n\n\n\n\n<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />\n<title>Error</title>\n<style ty"..., buflen=29190,
n=n@entry=0) at service_scan.cc:1435
#16888 0x000000000049af8e in servicescan_read_handler (nsp=0x41f3060, nse=, mydata=0x41f2cb0) at service_scan.cc:2436
#16889 0x00000000004cac68 in event_dispatch_and_delete (nsp=nsp@entry=0x41f3060, nse=nse@entry=0x41f45e0, notify=notify@entry=1) at nsock_event.c:373
#16890 0x00000000004c80ae in process_event (nsp=nsp@entry=0x41f3060, evlist=evlist@entry=0x41f3090, nse=nse@entry=0x41f45e0, ev=ev@entry=1) at nsock_core.c:1058
#16891 0x00000000004c8565 in process_iod_events (nsp=nsp@entry=0x41f3060, nsi=nsi@entry=0x41f52b0, ev=1) at nsock_core.c:1123
#16892 0x00000000004cd65d in iterate_through_event_lists (evcount=1, nsp=0x41f3060) at engine_epoll.c:345
#16893 epoll_loop (nsp=0x41f3060, msec_timeout=) at engine_epoll.c:312
#16894 0x00000000004c7ef3 in nsock_engine_loop (msec_timeout=-1, nsp=0x41f3060) at nsock_internal.h:431
#16895 nsock_loop (nsp=0x41f3060, msec_timeout=-1) at nsock_core.c:926
#16896 0x000000000049cdfc in service_scan (Targets=std::vector of length 1, capacity 100 = {...}) at service_scan.cc:2801
#16897 0x000000000046060d in nmap_main (argc=argc@entry=7, argv=argv@entry=0x7ffc51d5f078) at nmap.cc:2209
#16898 0x0000000000434096 in main (argc=7, argv=0x7ffc51d5f078) at main.cc:237

This is my nmap version info:
Nmap version 7.60 ( https://nmap.org )
Platform: x86_64-unknown-linux-gnu
Compiled with: nmap-liblua-5.3.3 openssl-1.0.1e nmap-libssh2-1.8.0 libz-1.2.8 libpcre-8.32 nmap-libpcap-1.7.3 nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: epoll poll select

@liteway liteway changed the title from nmap7.60 crash in libpcre.so when scan os fingerprint to nmap7.60 crash in libpcre.so when scan service Jan 29, 2018

@dmiller-nmap

This comment has been minimized.

Show comment
Hide comment
@dmiller-nmap

dmiller-nmap Mar 5, 2018

Seeing those newlines without carriage returns in the response leads me to realize this is the same as #1147, which is where I've started recording my progress.

Thanks very much for reporting this!

dmiller-nmap commented Mar 5, 2018

Seeing those newlines without carriage returns in the response leads me to realize this is the same as #1147, which is where I've started recording my progress.

Thanks very much for reporting this!

@liteway

This comment has been minimized.

Show comment
Hide comment
@liteway

liteway Apr 24, 2018

Hi, I use the nmap 7.70(build from github latest version) with your modification(nmap-service-probes), this issue is still exists, and I attach the core file for debugging convenience.
service_coredump.tar.gz

liteway commented Apr 24, 2018

Hi, I use the nmap 7.70(build from github latest version) with your modification(nmap-service-probes), this issue is still exists, and I attach the core file for debugging convenience.
service_coredump.tar.gz

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment