GNOME Bugzilla – Bug 679957
g_inet_address_new_from_string is not able to handle dots and numbers IPv4 addresses
Last modified: 2014-02-15 20:02:12 UTC
Created attachment 218850 [details] [review] Make use of inet_aton for IPv4 addresses instead of inet_pton in g_address_new_from_string Hi, g_inet_address_new_from_string is not able to handle dots and numbers IPv4 addresses and here is a patch to correct this. Cheers
Review of attachment 218850 [details] [review]: Needs a test case at a minimum. "git annotate gio/ginetaddress.c" says this was added in: 68fc0556 (Dan Winship 2008-12-12 13:13:55 -0500). Dan watches bugzilla so he should review this one.
The test case attached should print 127.0.0.1. Instead it currently prints Error.
Created attachment 218852 [details] Test case
I meant adding a test case to gio/tests that would get run automatically.
The additional formats parsed by inet_aton() are not actually part of any standard, were not much used historically, and are only ever used now by phishers trying to obscure the domain name in URLs (eg, http://yourbank.com@1539136771/)
Dan, you're right but for my GSOC project (an anti-phishing daemon for GNOME) I use the Google Safe Browsing API which explicitly requires me to handle these formats, that's why I did this patch.
(In reply to comment #6) > Dan, you're right but for my GSOC project (an anti-phishing daemon for GNOME) I > use the Google Safe Browsing API which explicitly requires me to handle these > formats Well... I think at a higher level, the requirement is "you must be able to stop people from connecting to phishing sites via URLs using those formats". But since libsoup/gio don't support those formats at all, this is trivially achieved even without the use of the safe browsing API. Put another way, it would be silly to add this feature to GInetAddress solely so that we could then block anyone who is trying to using it. :-)
(In reply to comment #7) > Well... I think at a higher level, the requirement is "you must be able to stop > people from connecting to phishing sites via URLs using those formats". But > since libsoup/gio don't support those formats at all, this is trivially > achieved even without the use of the safe browsing API. Epiphany doesn't use libsoup? Because http://3584377034/ leads me to the GMX website as expected. > > Put another way, it would be silly to add this feature to GInetAddress solely > so that we could then block anyone who is trying to using it. :-) Sure ;-) But I thought libsoup was handling that as Epiphany handles that. Cheers
hm... it uses libsoup, but the URIs get passed through webkit code too... that must be getting resolved by webkit. (either that or you're testing with your patched glib?)
(In reply to comment #9) > hm... it uses libsoup, but the URIs get passed through webkit code too... that > must be getting resolved by webkit. > > (either that or you're testing with your patched glib?) Hum, that was what I thought at first but I did sudo make uninstall so I guess it's good?
(In reply to comment #9) > hm... it uses libsoup, but the URIs get passed through webkit code too... that > must be getting resolved by webkit. Maybe that should be solved by Webkit but beware that until it gets my daemon won't caught phishing tentatives that use this trick. And everything in GNOME uses libsoup or not to get web content?
Hm... looks like g_resolver_lookup_by_name() decides its not an IP address, so it eventually calls getaddrinfo() to resolve the hostname, but getaddrinfo() does recognize that format, so it parses it as an IP address. I guess given that, maybe we do want the patch... still pondering.
Created attachment 267791 [details] [review] gio: don't accept nonstandard IPv4 "numbers-and-dots" addresses I'm planning to commit this if there are no objections
Attachment 267791 [details] pushed as 5575a3e - gio: don't accept nonstandard IPv4 "numbers-and-dots" addresses
See bug 724434 for a regression.