Re: Potential bug in nmap 4.21ALPHA4 (and before)

[Sebastian Wolfgarten <sebastian () wolfgarten com>]

Hi Kris,

thanks for the patch. I used the following command to patch nmap:

nmap-4.21ALPHA4 # patch -p0 < osscan-port0.patch
patching file osscan.cc

Then I did a "make clean", "configure" and "make" again. However the bug
is still there I believe:

nmap-4.21ALPHA4 # ./nmap -v -sS -sV -O -P0 -oA bla
-p0,21-23,25,80,111,139,443,445,512,1521,2049,3389,8080 www.nestor-hotels.de

Starting Nmap 4.21ALPHA4 ( http://insecure.org ) at 2007-05-17 07:38 CEST
Initiating Parallel DNS resolution of 1 host. at 07:38
Completed Parallel DNS resolution of 1 host. at 07:38, 0.00s elapsed
Initiating SYN Stealth Scan at 07:38
Scanning kundenserver.de (82.165.95.212) [15 ports]
Discovered open port 22/tcp on 82.165.95.212
Discovered open port 80/tcp on 82.165.95.212
Discovered open port 21/tcp on 82.165.95.212
Completed SYN Stealth Scan at 07:38, 0.05s elapsed (15 total ports)
Initiating Service scan at 07:38
Scanning 3 services on kundenserver.de (82.165.95.212)
Completed Service scan at 07:38, 6.04s elapsed (3 services on 1 host)
Initiating OS detection (try #1) against kundenserver.de (82.165.95.212)
Retrying OS detection (try #2) against kundenserver.de (82.165.95.212)
Initiating gen1 OS Detection against 82.165.95.212 at 9.824s
For OSScan assuming port 21 is open, 0 is closed, and neither are firewalled
send_closedudp_probe: One or more of your parameters suck!
send_closedudp_probe: One or more of your parameters suck!
For OSScan assuming port 21 is open, 0 is closed, and neither are firewalled
send_closedudp_probe: One or more of your parameters suck!
send_closedudp_probe: One or more of your parameters suck!
For OSScan assuming port 21 is open, 0 is closed, and neither are firewalled
send_closedudp_probe: One or more of your parameters suck!
send_closedudp_probe: One or more of your parameters suck!
SCRIPT ENGINE: Initiating script scanning.
Host kundenserver.de (82.165.95.212) appears to be up ... good.
Interesting ports on kundenserver.de (82.165.95.212):
PORT     STATE    SERVICE      VERSION
0/tcp    closed   unknown
21/tcp   open     ftp          ProFTPD
22/tcp   open     ssh          OpenSSH 4.3 Debian 1:4.3p2-2 (protocol 1.99)
23/tcp   filtered telnet
25/tcp   filtered smtp
80/tcp   open     http         Apache httpd 1.3.33 ((Unix))
111/tcp  filtered rpcbind
139/tcp  filtered netbios-ssn
443/tcp  closed   https
445/tcp  filtered microsoft-ds
512/tcp  filtered exec
1521/tcp closed   oracle
2049/tcp closed   nfs
3389/tcp closed   ms-term-serv
8080/tcp closed   http-proxy
Device type: broadband router|general purpose|load balancer|web proxy|WAP
Running (JUST GUESSING) : Linksys embedded (90%), Linux 2.6.X|2.4.X
(90%), Kemp embedded (89%), Cisco ACNS (88%), Siemens Linux (88%)
Aggressive OS guesses: Linksys WRT54GS v4 running OpenWrt w/Linux kernel
2.4.30 (90%), Linux 2.6.9-42 (Red Hat ES4) (90%), Linux 2.6.14-gentoo-r2
(Gentoo, x86) (90%), KEMP Technologies LoadMaster 1500 load balancer
(89%), Cisco Content Engine CE590 running Application and Content
Networking System Software 5.5.5 (88%), Siemens Gigaset SE515dsl
wireless broadband router (88%), Centos 4.3 Linux 2.6.17.11-grsec
(Centos 4.3, X86) (87%), Linux 2.6.15-27 (Ubuntu 6.06) (86%), Linux
2.4.33 (85%), Linux 2.6.18-em64t (x86-64) (85%)
No exact OS matches for host (test conditions non-ideal).
TCP Sequence Prediction: Difficulty=4344599 (Good luck!)
IPID Sequence Generation: All zeros
Service Info: OSs: Unix, Linux

OS and Service detection performed. Please report any incorrect results
at http://insecure.org/nmap/submit/ .
Nmap finished: 1 IP address (1 host up) scanned in 18.835 seconds
               Raw packets sent: 101 (8344B) | Rcvd: 79 (4242B)

Cheers,
Sebastian

Kris Katterjohn schrieb:
> On 5/16/07, *Fyodor* <fyodor () insecure org <mailto:fyodor () insecure org>>
> wrote:
>
>     On Wed, May 16, 2007 at 11:19:12PM +0200, Sebastian Wolfgarten wrote:
>     >
>     > And here is the problem: Which option does actually suck
>     > (send_closedudp_probe: One or more of your parameters suck!)? Why
>     do I
>     > get these messages when to me the command-line call above looks quite
>     > alright, doesn't it?
>
>     Thanks for the report, Sebastian.  This is definitely an Nmap bug
>     related to a combination of scanning port zero and OS scan, but after
>     looking into the code, I think this only affects the old OS detection
>     system.  Since I hope to get rid of that 1st generation system
>     completely, it probably isn't worth fixing and testing.  Though if
>     someone wants to, I'd certainly accept a patch.  And if you are able
>     to reproduce this with -O2 (sencond generation system), please post
>     the log.
>
>
> I'm on a Windows (XP SP2) machine tonight with lame dialup, so no LAN or
> anything to test on :(
>
> I attached a patch that should (I hope) work... or maybe somebody can
> use it as a base to work with if it fails.  I was able to compile it
> fine, I just couldn't play with it.  It tries to get another closed port
> (or unfiltered, I added the code there too) to use instead of 0.  I
> should be able to test it out tomorrow, but wanted to go ahead and throw
> it out here since I made the patch all ready :)
>
> So please test anybody (especially you Sebastian ;))
>
> Thanks,
> Kris Katterjohn


_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org