Skip to content
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

Nmap os scan hangs #2104

Closed
ameidatou opened this issue Aug 15, 2020 · 9 comments
Closed

Nmap os scan hangs #2104

ameidatou opened this issue Aug 15, 2020 · 9 comments
Labels

Comments

@ameidatou
Copy link

@ameidatou ameidatou commented Aug 15, 2020

Bug
When triggering a nmap OS scan for a specific host, nmap hangs with CPU usage 100%. This doesn't happen systematically but quite often

To Reproduce
sudo nmap -O -p 1027,1028,5000,443,8081,80,8080,1026,1025 --open -Pn -ddd -vv 85.2.144.13
if it doesn't happen the first time, please repeat for 3 to 5 times and you should encounter the issue.

  • Log:
    The log hangs at this point
Host 85.2.144.13. ProbesToSend 8:       ProbesActive 6
SENT (3.2078s) TCP [192.168.1.6:38140 > 85.2.144.13:443 SFPU seq=2929557940 ack=217905394 off=10 res=0 win=256 csum=0xCED1 urp=0 <wscale 10,nop,mss 265,timestamp 4294967295 0,sackOK>] IP [ver=4 ihl=5 tos=0x00 iplen=60 id=14722 foff=0 ttl=47 proto=6 csum=0xab7c]
Send probe (type: OFP_T1_7, subid: 2) to 85.2.144.13
pcap wait time is 24807.
Rejecting TCP packet because of bad TCP header
Host 85.2.144.13. ProbesToSend 7:       ProbesActive 7
pcap wait time is 23720.
Host 85.2.144.13. ProbesToSend 8:       ProbesActive 6
SENT (3.2331s) TCP [192.168.1.6:38141 > 85.2.144.13:443 A seq=2929557940 ack=217905394 off=10 res=0 win=1024 csum=0xCBEB urp=0 <wscale 10,nop,mss 265,timestamp 4294967295 0,sackOK>] IP [ver=4 ihl=5 tos=0x00 iplen=60 id=49426 flg=D foff=0 ttl=45 proto=6 csum=0xe5eb]
Send probe (type: OFP_T1_7, subid: 3) to 85.2.144.13
pcap wait time is 24787.
  • gdb bt:
(gdb) bt
#0  0x000055b6c370f232 in readip_pcap(pcap*, unsigned int*, long, timeval*, link_header*, bool) ()
#1  0x000055b6c370f33d in readipv4_pcap(pcap*, unsigned int*, long, timeval*, link_header*, bool) ()
#2  0x000055b6c36d1bd7 in OSScan::os_scan_ipv4(std::vector<Target*, std::allocator<Target*> >&) ()
#3  0x000055b6c36d2a26 in OSScan::os_scan(std::vector<Target*, std::allocator<Target*> >&) ()
#4  0x000055b6c36c47c0 in nmap_main(int, char**) ()
#5  0x000055b6c3695cc6 in main ()
  • Top:
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                                                        
19718 root      20   0   67876  22928   1316 R 100.0  0.1  45:47.65 nmap                                                                                                                                                                                                                                                                             
  • ps:
$ ps -ef |grep nmap
root     19717 20920  0 10:24 pts/11   00:00:00 sudo nmap -O -p 1027,1028,5000,443,8081,80,8080,1026,1025 --open -Pn -ddd -vv 85.2.144.13
root     19718 19717 99 10:24 pts/11   00:46:35 nmap -O -p 1027,1028,5000,443,8081,80,8080,1026,1025 --open -Pn -ddd -vv 85.2.144.13

Expected behavior
Nmap os scan finishes in less than 30s.

Version info (please complete the following information):

  • OS: Linux 5.4.0-42-generic #46~18.04.1-Ubuntu x86_64 x86_64 x86_64 GNU/Linux
  • Output of nmap --version:
Platform: x86_64-unknown-linux-gnu
Compiled with: nmap-liblua-5.3.5 openssl-1.0.2n nmap-libssh2-1.8.2 libz-1.2.11 libpcre-8.39 nmap-libpcap-1.9.0 nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: epoll poll select
@ameidatou ameidatou added the Nmap label Aug 15, 2020
@ameidatou
Copy link
Author

@ameidatou ameidatou commented Aug 15, 2020

after some debugging, I found there is an infinite loop in file tcpip.cc in function validateTCPhdr() in line:

nmap/tcpip.cc

Line 1374 in 0acdeb5

while (optlen > 0) {

@ameidatou
Copy link
Author

@ameidatou ameidatou commented Aug 15, 2020

with extra logging, notice that tcpc and optlen are not changing, and the loop goes infinite:

Host 85.2.144.13. ProbesToSend 11:      ProbesActive 3
pcap wait time is 2000.
Issue 2104 - call readipv4_pcap().
Issue 2104 - call readip_pcap().
Issue 2104 - call validatepkt().
Issue 2104 - call validateTCPhdr().
Issue 2104 - in validateTCPhdr: tcpc 2, len 32, optlen 12.
Issue 2104 - start while: tcpc 2, len 32, optlen 12.
Issue 2104: OPTLEN_IS expected/optlen: 4/12.
Issue 2104 - end while: tcpc 4, len 32, optlen 8.
Issue 2104 - start while: tcpc 4, len 32, optlen 8.
Issue 2104: OPTLEN_IS expected/optlen: 2/8.
Issue 2104 - end while: tcpc 1, len 32, optlen 6.
Issue 2104 - start while: tcpc 1, len 32, optlen 6.
Issue 2104 - end while: tcpc 1, len 32, optlen 5.
Issue 2104 - start while: tcpc 1, len 32, optlen 5.
Issue 2104 - end while: tcpc 98, len 32, optlen 4.
Issue 2104 - start while: tcpc 98, len 32, optlen 4.
Issue 2104 - end while: tcpc 98, len 32, optlen 4.
Issue 2104 - start while: tcpc 98, len 32, optlen 4.
Issue 2104 - end while: tcpc 98, len 32, optlen 4.
Issue 2104 - start while: tcpc 98, len 32, optlen 4.
Issue 2104 - end while: tcpc 98, len 32, optlen 4.
Issue 2104 - start while: tcpc 98, len 32, optlen 4.
Issue 2104 - end while: tcpc 98, len 32, optlen 4.
Issue 2104 - start while: tcpc 98, len 32, optlen 4.
Issue 2104 - end while: tcpc 98, len 32, optlen 4.
Issue 2104 - start while: tcpc 98, len 32, optlen 4.
Issue 2104 - end while: tcpc 98, len 32, optlen 4.
@ameidatou
Copy link
Author

@ameidatou ameidatou commented Aug 17, 2020

it may be related to:

@dmiller-nmap
Copy link

@dmiller-nmap dmiller-nmap commented Aug 17, 2020

The target has a very weird behavior during OS detection; the TCP End-of-Options-List option is corrupted in many cases, essentially being replaced by 2 random bytes. I will look at our code and see if I can eliminate the parsing problem.

@dmiller-nmap
Copy link

@dmiller-nmap dmiller-nmap commented Aug 18, 2020

@ameidatou What version of Nmap are you actually using? These values don't match the existing code. It would also be helpful to have a packet capture of a scan where the actual bug triggers.

@ameidatou
Copy link
Author

@ameidatou ameidatou commented Aug 18, 2020

@dmiller-nmap below is my nmap version:

Nmap version 7.80SVN ( https://nmap.org )
Platform: x86_64-unknown-linux-gnu
Compiled with: nmap-liblua-5.3.5 openssl-1.0.2n nmap-libssh2-1.9.0 libz-1.2.11 libpcre-8.39 nmap-libpcap-1.9.1 nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: epoll poll select

Not sure what you mean by:

These values, don't match the existing code?

and attached are:

@dmiller-nmap
Copy link

@dmiller-nmap dmiller-nmap commented Aug 18, 2020

ok, I think I see the issue. If the bogus option has a length of 0, then *tcpc == 0, and this line moves it back one place and the loop gets stuck:

tcpc += (*tcpc - 1);

I'll put in a check for this.

@dmiller-nmap
Copy link

@dmiller-nmap dmiller-nmap commented Aug 18, 2020

Fix incoming. Interestingly, this bug was introduced in my fix to #1204, which is a transposition of this issue number :)

@nmap-bot nmap-bot closed this in cfff367 Aug 18, 2020
@ameidatou
Copy link
Author

@ameidatou ameidatou commented Aug 18, 2020

Thanks @dmiller-nmap for your quick feedback and quick fix!
I tested it on that specific host and it works fine!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.