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 all

(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 all

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 `\0'); 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 all

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 "\000" 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!