netdev - Re: [PATCH] parse ip:port strings correctly in in4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4624A105.26924.380F9F@j.borsboom.erasmusmc.nl>
Date:	Tue, 17 Apr 2007 10:27:17 +0200
From:	"Jerome Borsboom" <j.borsboom@...smusmc.nl>
To:	Jerome Borsboom <j.borsboom@...smusmc.nl>,
	Patrick McHardy <kaber@...sh.net>
CC:	netdev@...r.kernel.org
Subject: Re: [PATCH] parse ip:port strings correctly in in4_pton

> Jerome Borsboom wrote:
> > in4_pton converts a textual representation of an ip4 address into an
> > integer representation. However, when the textual representation is of
> > in the form ip:port, c.f. 192.168.1.1:5060, and 'delim' is set to -1,
> > the function bails out when parsing the colon.
> > 
> > It makes sense to allow the colon as a delimiting character without
> > explicitly having to set it through the 'delim' variable as there can be
> > no ambiguity in the point where the ip address is completely parsed.
> > Furthermore, this function is indeed called from nf_conntrack_sip.c in
> > this way to parse textual ip:port combinations which fails as stated above.
> 
> 
> What about IPv6? in6_pton behaves similar and is also used by
> nf_conntrack_sip.
> 

I have looked a bit more into this. The current behaviour of 
in6_pton is correct. As I said before, the colon is the separator 
within the IPv6 address and hence cannot be used to indicate a tcp 
or udp port. RFC 2732 states that when a tcp or udp port is included 
in an IPv6 URL it must be in the form '[IPv6-address]:port'. Here 
the rectangular braces make clear where the ip-address part ends and 
the port part begins. However, in[46]_pton are made to only change 
the representation of an ip-address and do not and should not bother 
about any other stuff like the rectangular braces in an IPv6 
reference or the colon in an IPv4+port combination. My patch 
corrects the unnecessary error in the case in an IPv4-address+port 
combination.

Related to this is the fact that nf_conntrack_sip wrongly assumes 
unbraced IPv6 adresses. RFC 3261 states that in all cases where an 
IPv6 reference is used, it should be enclosed in rectangular braces. 
Current behaviour is clearly wrong. I will see if I can come up with 
a patch to correct this error in nf_conntrack_sip.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html