does net-receive-from return complete IP?

[ino-news]

newLISP v.9.1.0 on freebsd-6-stable:



i have an application doing:

Code Select Expand


(define (do-udp-connect fd)
  (letn ((peer (net-receive-from fd 1))
         (last-error (net-error)))
        (if (nil? last-error)
          (let ((ip (nth 1 peer)))
            (if (!= last-udp-ip-seen ip)
              (begin
                (log-n-block ip (target-ip fd) (target-port fd) "udp")
                (set 'last-udp-ip-seen ip)))
            true)
          (begin
            (set 'prob-fd fd)
            (set 'last-net-error last-error)
            nil))))


this is to temporarily block UDP connections from hosts attacking,

eg. the micro$oft pop-up "service" peddling registry-fix software.

funny thing is this: i have all sorts of entries in the log showing

11-digit IPs like (example) "221.208.208.10". when checking the firewall

log i notice that this particular IP _never_ showed up, but eg.

"221.208.208.101" or "221.208.208.100". pulling my hair, time passes. it

occurs to me to count the digits of the IPs and voila: never once does

a (valid!) _12_ digit IP (like xxx.xxx.xxx.xxx, with x=anydigit) get

returned!



all sorts of other IPs of varying string length, as if there was a

limit built-in to newlisp stating that IPs like "221.208.208.101"

cannot happen. could someone please check newlisp's C-source or verify

this? oh, by the way, a similiar routine "do-tcp-connect" exists using

"net-peer" to aquire the peers IP, and it, too, shows this behaviour.



i can corelate events logged by "log-n-block", which keeps timestamps,

to firewall entries made by tcpdump, and it really looks like 12-digit

IPs triggered the events, but got logged by newlisps routines with the

last digit chopped off!



-- clemens

[ino-news]

all sorts of other IPs of varying string length, as if there was a

limit built-in to newlisp stating that IPs like "221.208.208.101"

cannot happen. could someone please check newlisp's C-source or verify

this?

i think i found the bug:  look at "newlisp-9.1.0/nl-sock.c".  there are

three occurences of the idiom:

Code Select Expand


snprintf(IPaddress, 15, "%d.%d.%d.%d", ipNo[0], ipNo[1], ipNo[2], ipNo[3]);


the man page states:



"The snprintf() and vsnprintf() functions will write at most size-1 of

the characters printed into the output string (the size'th character

then gets the terminating `'); if the return value is greater than

or equal to the size argument, the string was too short and some

of the printed characters were discarded.  The output is always

null-terminated."



so the buffer receiving "IPaddress" must be at least 16 bytes of size,

the line should say:

Code Select Expand


snprintf(IPaddress, 16, "%d.%d.%d.%d", ipNo[0], ipNo[1], ipNo[2], ipNo[3]);


and the last byte of "IPaddress" will have the customary "00" null

byte.  glancing at the code, the calling functions have their buffer for

the string representation of the IP address correctly sized to be 16

bytes, so maybe changing those snprintf-lines would be enough to fix the

problem.  i don't dare to do this beeing unfamiliar with the code base,

but i strongly recommend a bug-fix release.  i'd be happy with a patch

for the time beeing, as i really need the functionality.



-- clemens

[Lutz]

Yes, thanks Clemens, I just found it too and in 2 other places. I will post development release 9.1.2 with a fix for this soon.



Lutz

[newdep]

nice catch!