You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by jdow <jd...@earthlink.net> on 2011/11/27 22:26:43 UTC
Question for experts....
Which browser(s) treat addresses of the form 178.000235.0000150.000372 as
actual addresses? That seems like a serious fault in the browsers.
{^_^}
Re: Question for experts....
Posted by jdow <jd...@earthlink.net>.
On 2011/11/27 15:05, Mahmoud Khonji wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 11/28/2011 01:26 AM, jdow wrote:
>> Which browser(s) treat addresses of the form
>> 178.000235.0000150.000372 as actual addresses? That seems like a
>> serious fault in the browsers.
>>
>> {^_^}
>
> adding to that: dotted hex IPv4 0x12.0xab.0xcd.0xef. single hex number
> 0x12abcdef, or a single decimal number. these used to work on Firefox
> 3.x (at least - may be they changed it in more recent releases).
>
> but i don't think that it is a serious fault. a simple pattern match
> will detect it.
>
> i personally like rare IPv4 URLs as considering an email with rare
> IPv4 URLs as spam results in 0% false positives :). while considering
> a dotted decimal IPv4 as spam results in 3-4% false positives. (stats
> from my data set).
>
> - --
> Regards,
> Mahmoud Khonji
> PGP Key: 0x92584ECA
That is what I'd expect. So I'd give the illegal versions "guaranteed
spam" scores unless they are part of a munged. If they are munged they
should get a point or two score. The pure decimal dotted quad should
have a point or two score on it.
(And thanks for pointing out for people that the other variants are
legal in C but not in URLs. The problem with RFCs is that you must be
reading the correct one for it all to work.)
{^_^}
Re: Question for experts....
Posted by Mahmoud Khonji <m...@khonji.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/28/2011 01:26 AM, jdow wrote:
> Which browser(s) treat addresses of the form
> 178.000235.0000150.000372 as actual addresses? That seems like a
> serious fault in the browsers.
>
> {^_^}
adding to that: dotted hex IPv4 0x12.0xab.0xcd.0xef. single hex number
0x12abcdef, or a single decimal number. these used to work on Firefox
3.x (at least - may be they changed it in more recent releases).
but i don't think that it is a serious fault. a simple pattern match
will detect it.
i personally like rare IPv4 URLs as considering an email with rare
IPv4 URLs as spam results in 0% false positives :). while considering
a dotted decimal IPv4 as spam results in 3-4% false positives. (stats
from my data set).
- --
Regards,
Mahmoud Khonji
PGP Key: 0x92584ECA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJO0sIoAAoJEFzU5FSSWE7KYm4H/3uwAHUA109aQRLBqI6/00Jh
AuF7GBoGRtVg7u5f3kWg72Bxy0BuU9COoWuJyUIiNrtKxKVrT8FWSRrq51NAux8q
4a9LUgKacPDLLKxj5UHDHH6cq7wuMZFNEhtlL5y8SQTEXyoLdkwn6T5Pbqs7Gifk
LeFQPPF/9zM3GVUQ/Y59Rv4RC5ysXCRNu8gcszPanN9GeutGUPNAS8PQzXJhiJLR
lxcxojDAO+sfWgebRFosvX+0Sx5geVMYOZw5nBNY3aa2gqA1HeXhUpyeN62rO6Sl
U5N6P1wmJXttrrdDLDAI2o8KJxxyJvHXHIZMdF3u5dW5em0/6feXBCBHuYUiIzQ=
=Lk4z
-----END PGP SIGNATURE-----
Re: Question for experts....
Posted by jdow <jd...@earthlink.net>.
On 2011/11/27 13:52, Martin Gregorie wrote:
> On Sun, 2011-11-27 at 13:26 -0800, jdow wrote:
>> Which browser(s) treat addresses of the form 178.000235.0000150.000372 as
>> actual addresses? That seems like a serious fault in the browsers.
>>
> What piece of junk software presented an IP in that format? Itds
> obviously something I should avoid in future.
>
> Martin
Don't know. The email made it to my spam directory on other scores (SARE,
basic malformations, and BLs). It was titled "Public Arrest Records". With
that and the obfuscated address please note that I'm not reckless enough
to actually click on the famn dool thing outside of a sacrificial virtual
machine. And that's too much bother.
{^_-}
Re: Question for experts....
Posted by Martin Gregorie <ma...@gregorie.org>.
On Sun, 2011-11-27 at 13:26 -0800, jdow wrote:
> Which browser(s) treat addresses of the form 178.000235.0000150.000372 as
> actual addresses? That seems like a serious fault in the browsers.
>
What piece of junk software presented an IP in that format? Itds
obviously something I should avoid in future.
Martin
Re: Question for experts....
Posted by jdow <jd...@earthlink.net>.
On 2011/11/28 19:21, Jason Haar wrote:
> Don't have an answer for you, but I can say that the following URL works
> under FF-8.0
>
> http://0x12.0x12.0x12.0x12/
>
> (resolves to 18.18.18.18)
>
> However, if you force browsers through a squid proxy, squid-2.6 at least
> treats that as borked and won't play with it.
>
> So even proxies are out of step with FF. Don't care if it's "right",
> there's no need for any browser to accept crap like that :-(
>
> It's probably "safe" to have a rule to score such urls - except when
> they're http://0x12.0x12.com/ or the like!
As it turned out the URI_HEX rule from 3.3.1 (Scientific Linux) fired on
that abomination.
The SARE rule "SARE_HEXOCTDWORD" triggered. It looks like this if you don't
have 72_sare_redirect_post3.0.0.cf installed:
===8<---
# IE url obfuscating bug
uri SARE_URI_EQUALS
m{^https?:?[/\\]{0,2}[^/\&?;]{1,100}=(?!(?:..)?$).*$}i
describe SARE_URI_EQUALS Trying to hide the real URL with IE parsing bug
score SARE_URI_EQUALS 1.666
#stype SARE_URI_EQUALS obfu
#ham SARE_URI_EQUALS hits source code with strange spacing.
# Not decoded, as we're explicitly searching for the encoded version
# catches all versions of IP obfuscation mentioned here:
http://www.pc-help.org/obscure.htm
uri SARE_HEXOCTDWORD
m{^(?:h|%[46]8)(?:t|%[57]4){2}(?:p|%[57]0)(?:s|%[57]3)?(?::|%3a)?(?:%5c|\\|%2f|/){0,2}(?:(?:(?![@\?/]|%40|).)*(?:\@|%40))*(?!123\.456\.789\.(?:999|012)|(?:2[0-4][0-9]|25[0-5]|1[0-9][0-9]|[1-9]?[0-9])(?:$|\.(?:2[0-4][0-9]|25[0-5]|1[0-9][0-9]|[1-9]?[0-9])){3}(?:[:\?;&/\\]|%3[abf]|%2[6f]|%5[c]|$))(?:(?:%3[0-9]|\d)+|(?:0|%30)(?:x|%[57]8)(?:%3[0-9]|%[46][1-6]|[0-9a-f])+|(?:0|%30)(?:%3[0-7]|[0-7])+)(?:(?:\.|%2e)(?:(?:%3[0-9]|\d)+|(?:0|%30)(?:x|%[57]8)(?:%3[0-9]|%[46][1-6]|[0-9a-f])+|(?:0|%30)(?:%3[0-7]|[0-7])+)){0,3}(?:[:\?;&/\\]|%3[abf]|%2[6f]|%5[c]|$)}i
describe SARE_HEXOCTDWORD Uses an encoded IP address
score SARE_HEXOCTDWORD 2.0
#stype SARE_HEXOCTDWORD obfu
===8<---
SARE rules seem to make life easier here. I included a second rule, the IE
parsing bug rule.
And as observed the rule COULD have a score equal to the spam threshold without
generating false positives.
In general using these techniques means something is being hidden from the
user. That raises the hairs on the back of my neck a tad when I see it. This
one with the really long "encrypted" tails looked like it was more than simple
drug spam or the like. So the mother hen in me wanted to look out for others
towards whom it might have been targeted.
{^_-}
Re: Question for experts....
Posted by Benny Pedersen <me...@junc.org>.
On Mon, 28 Nov 2011 20:21:23 -0800, Dave Warren wrote:
> I tried in Chrome 16.0.912.41 beta-m and 17.0.953.0 canary, both
> instantly changed the displayed URL to "18.18.18.18" then timed out
> trying to browse.
yep, if i add this ip it gives error in 15.x.x.x chrome
dont know how to make chrome as imap client so dont know if it just
roundcube not render ip as urls, its imho safe not to
> http://0xAD.0xC2.0x21.0x34/ (which actually has a web server on it)
> works in both versions of Chrome.
yep the url encode works, but i will never use ip encoded urls
Re: Question for experts....
Posted by jdow <jd...@earthlink.net>.
On 2011/11/29 06:37, Simon Loewenthal wrote:
> On 29/11/11 15:21, Bowie Bailey wrote:
>> On 11/28/2011 11:21 PM, Dave Warren wrote:
>>> On 11/28/2011 7:41 PM, Benny Pedersen wrote:
>>>> On Tue, 29 Nov 2011 16:21:56 +1300, Jason Haar wrote:
>>>>
>>>>> http://0x12.0x12.0x12.0x12/
>>>> does not work in chrome
>>> I tried in Chrome 16.0.912.41 beta-m and 17.0.953.0 canary, both
>>> instantly changed the displayed URL to "18.18.18.18" then timed out
>>> trying to browse.
>> Works in the latest Google Chrome 15 as well.
>>
>>> http://0xAD.0xC2.0x21.0x34/ (which actually has a web server on it)
>>> works in both versions of Chrome.
>> Interestingly, when I clicked on that one, Thunderbird gave me a warning:
>>
>> Thunderbird thinks this message is a scam. The links in the message may
>> be trying to impersonate web pages you want to visit. Are you sure you
>> want to visit 173.194.33.52?
>>
>> So it's not just browsers that can work with these obnoxious urls.
>>
> Firefox treats it as :
>
> Unable to determine IP address from host name for /0xad.0xc2.0x21.0x34/
> Name Error: The domain name does not exist.
Try "http://0xad.0xc2.0x21.0x34/"
{^_^}
Re: Question for experts....
Posted by Dave Warren <li...@hireahit.com>.
On 11/29/2011 9:17 AM, Walter Hurry wrote:
> On Tue, 29 Nov 2011 15:37:57 +0100, Simon Loewenthal wrote:
>
>>>> http://0xAD.0xC2.0x21.0x34/
>> Firefox treats it as :
>>
>> Unable to determine IP address from host name for
>> /0xad.0xc2.0x21.0x34/
>> Name Error: The domain name does not exist.
> Works for me in Firefox 8.
<AOL>Me too!</AOL> in 10.0a2.
--
Dave Warren, CEO
Hire A Hit Consulting Services
http://ca.linkedin.com/in/davejwarren
Re: Question for experts....
Posted by Walter Hurry <wa...@lavabit.com>.
On Tue, 29 Nov 2011 15:37:57 +0100, Simon Loewenthal wrote:
>>> http://0xAD.0xC2.0x21.0x34/
> Firefox treats it as :
>
> Unable to determine IP address from host name for
> /0xad.0xc2.0x21.0x34/
> Name Error: The domain name does not exist.
Works for me in Firefox 8.
Re: Question for experts....
Posted by Simon Loewenthal <si...@klunky.co.uk>.
On 29/11/11 15:21, Bowie Bailey wrote:
> On 11/28/2011 11:21 PM, Dave Warren wrote:
>> On 11/28/2011 7:41 PM, Benny Pedersen wrote:
>>> On Tue, 29 Nov 2011 16:21:56 +1300, Jason Haar wrote:
>>>
>>>> http://0x12.0x12.0x12.0x12/
>>> does not work in chrome
>> I tried in Chrome 16.0.912.41 beta-m and 17.0.953.0 canary, both
>> instantly changed the displayed URL to "18.18.18.18" then timed out
>> trying to browse.
> Works in the latest Google Chrome 15 as well.
>
>> http://0xAD.0xC2.0x21.0x34/ (which actually has a web server on it)
>> works in both versions of Chrome.
> Interestingly, when I clicked on that one, Thunderbird gave me a warning:
>
> Thunderbird thinks this message is a scam. The links in the message may
> be trying to impersonate web pages you want to visit. Are you sure you
> want to visit 173.194.33.52?
>
> So it's not just browsers that can work with these obnoxious urls.
>
Firefox treats it as :
Unable to determine IP address from host name for /0xad.0xc2.0x21.0x34/
Name Error: The domain name does not exist.
Re: Question for experts....
Posted by Bowie Bailey <Bo...@BUC.com>.
On 11/28/2011 11:21 PM, Dave Warren wrote:
> On 11/28/2011 7:41 PM, Benny Pedersen wrote:
>> On Tue, 29 Nov 2011 16:21:56 +1300, Jason Haar wrote:
>>
>>> http://0x12.0x12.0x12.0x12/
>> does not work in chrome
> I tried in Chrome 16.0.912.41 beta-m and 17.0.953.0 canary, both
> instantly changed the displayed URL to "18.18.18.18" then timed out
> trying to browse.
Works in the latest Google Chrome 15 as well.
> http://0xAD.0xC2.0x21.0x34/ (which actually has a web server on it)
> works in both versions of Chrome.
Interestingly, when I clicked on that one, Thunderbird gave me a warning:
Thunderbird thinks this message is a scam. The links in the message may
be trying to impersonate web pages you want to visit. Are you sure you
want to visit 173.194.33.52?
So it's not just browsers that can work with these obnoxious urls.
--
Bowie
Re: Question for experts....
Posted by Dave Warren <li...@hireahit.com>.
On 11/28/2011 7:41 PM, Benny Pedersen wrote:
> On Tue, 29 Nov 2011 16:21:56 +1300, Jason Haar wrote:
>
>> http://0x12.0x12.0x12.0x12/
>
> does not work in chrome
I tried in Chrome 16.0.912.41 beta-m and 17.0.953.0 canary, both
instantly changed the displayed URL to "18.18.18.18" then timed out
trying to browse.
http://0xAD.0xC2.0x21.0x34/ (which actually has a web server on it)
works in both versions of Chrome.
--
Dave Warren, CEO
Hire A Hit Consulting Services
http://ca.linkedin.com/in/davejwarren
Re: Question for experts....
Posted by Benny Pedersen <me...@junc.org>.
On Tue, 29 Nov 2011 16:21:56 +1300, Jason Haar wrote:
> http://0x12.0x12.0x12.0x12/
does not work in chrome
> they're http://0x12.0x12.com/ or the like!
is working as clickbar, maybe 0x12 is not a valid tld ?
Re: Question for experts....
Posted by Jason Haar <Ja...@trimble.com>.
Don't have an answer for you, but I can say that the following URL works
under FF-8.0
http://0x12.0x12.0x12.0x12/
(resolves to 18.18.18.18)
However, if you force browsers through a squid proxy, squid-2.6 at least
treats that as borked and won't play with it.
So even proxies are out of step with FF. Don't care if it's "right",
there's no need for any browser to accept crap like that :-(
It's probably "safe" to have a rule to score such urls - except when
they're http://0x12.0x12.com/ or the like!
--
Cheers
Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +1 408 481 8171
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
Re: Question for experts....
Posted by jdow <jd...@earthlink.net>.
On 2011/11/28 20:28, John Hardin wrote:
> On Tue, 29 Nov 2011, Martin Gregorie wrote:
>
>> On Mon, 2011-11-28 at 18:35 -0800, jdow wrote:
>>
>>> It is a way of obfuscating that's over the top and nobody has a way to
>>> get those oddball formulations easily from standard tools. They become
>>> an excellent way of leading people to strange addresses with strings
>>> that include ?ASFDikmedsfok3l1masdh sort of text following the index.html.
>>
>> OK, here's a pair of data points: on my system 192.168.7.2 is the IP of
>> a web server on port 80.
>>
>> I tried feeding "000192.000168.0007.0002" to Lynx and Opera as the sole
>> command line argument:
>>
>> lynx 2.8.7 tried several variations on the input theme before giving up.
>> The permutations it tried show that it thought it was
>> dealing with a malformed host name.
>>
>> opera 11.52 reported that this URL was garbage and quit, so it too
>> thought it was a host name rather than an IP address.
>>
>> Both accept "192.168.7.2" as a valid IP when entered as a command line
>> argument or from a display screen as described above.
>
> Did you try it with the proper octal conversions of the octets in that address?
> 00192 and 00168 are not valid octal numbers.
>
> At my site:
>
> lynx 2.8.7:
....
I'd try with known working URLs. The octal variant is also particularly
interesting.
{^_^}
Re: Question for experts....
Posted by John Hardin <jh...@impsec.org>.
On Mon, 28 Nov 2011, John Hardin wrote:
> firefox 8.0:
> Error: Firefox can't establish a connection to the server at
> 0012.0012.0012.0012.
That appears to have been an artifact of randomly choosing 12, which maps
to the 10-net and falls afoul of my local network setup.
http://00200.00200.00200.00200/ behaves the same as the others. Squid
logged:
1322540965.996 13819 10.1.0.202 TCP_MISS/000 0 GET http://128.128.128.128/ - DIRECT/128.128.128.128 -
It looks like all of these browsers are implementing "be liberal in what
you accept"...
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
"Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never
does quite what I want. I wish Christopher Robin was here."
-- Peter da Silva in a.s.r
-----------------------------------------------------------------------
27 days until Christmas
Re: Question for experts....
Posted by John Hardin <jh...@impsec.org>.
On Tue, 29 Nov 2011, Martin Gregorie wrote:
> On Mon, 2011-11-28 at 18:35 -0800, jdow wrote:
>
>> It is a way of obfuscating that's over the top and nobody has a way to
>> get those oddball formulations easily from standard tools. They become
>> an excellent way of leading people to strange addresses with strings
>> that include ?ASFDikmedsfok3l1masdh sort of text following the index.html.
>
> OK, here's a pair of data points: on my system 192.168.7.2 is the IP of
> a web server on port 80.
>
> I tried feeding "000192.000168.0007.0002" to Lynx and Opera as the sole
> command line argument:
>
> lynx 2.8.7 tried several variations on the input theme before giving up.
> The permutations it tried show that it thought it was
> dealing with a malformed host name.
>
> opera 11.52 reported that this URL was garbage and quit, so it too
> thought it was a host name rather than an IP address.
>
> Both accept "192.168.7.2" as a valid IP when entered as a command line
> argument or from a display screen as described above.
Did you try it with the proper octal conversions of the octets in that
address? 00192 and 00168 are not valid octal numbers.
At my site:
lynx 2.8.7:
lynx http://0012.0012.0012.0012/
No errors reported, no apparent attempts to re-parse the URL. Manually
interrupted the session after a few seconds spinning.
squid proxy logged:
1322539361.125 3765 10.1.0.202 TCP_MISS/000 0 GET http://10.10.10.10/ - DIRECT/10.10.10.10 -
links 2.3:
links http://0012.0012.0012.0012/
No errors reported, no apparent attempts to re-parse the URL. Manually
interrupted the session after a few seconds spinning.
squid proxy logged:
1322539627.158 3007 10.1.0.202 TCP_MISS/000 0 GET http://10.10.10.10/ - DIRECT/10.10.10.10 -
firefox 8.0:
Error: Firefox can't establish a connection to the server at 0012.0012.0012.0012.
squid proxy logged no connection attempt.
Removing the leading zeros it behaves as a standard DQ URL and does go
via the proxy.
epiphany 2.30:
No errors reported, no apparent attempts to re-parse the URL. Manually
interrupted the session after a few seconds spinning.
squid proxy logged:
1322540095.467 39169 10.1.0.202 TCP_MISS/000 0 GET http://10.10.10.10/ - DIRECT/10.10.10.10 -
seamonkey 2.4.1:
No errors reported, no apparent attempts to re-parse the URL. Manually
interrupted the session after a few seconds spinning.
squid proxy logged:
1322540248.762 9369 10.1.0.202 TCP_MISS/000 0 GET http://10.10.10.10/ - DIRECT/10.10.10.10 -
iOS 5.01 Safari:
No errors reported, no apparent attempts to re-parse the URL. Manually
interrupted the session after a few seconds spinning.
squid proxy logged:
1322540585.161 23690 10.1.0.12 TCP_MISS/000 0 GET http://10.10.10.10/ - DIRECT/10.10.10.10 -
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
"Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never
does quite what I want. I wish Christopher Robin was here."
-- Peter da Silva in a.s.r
-----------------------------------------------------------------------
27 days until Christmas
Re: Question for experts....
Posted by Martin Gregorie <ma...@gregorie.org>.
On Mon, 2011-11-28 at 20:17 -0800, Dave Warren wrote:
> On 11/28/2011 7:37 PM, Martin Gregorie wrote:
> > I tried feeding "000192.000168.0007.0002" to Lynx and Opera as the sole
> > command line argument:
>
> Wouldn't that be 000300.000250.0007.0002 ? Or did I miss a step here?
>
I was assuming that the obfuscation was simply the presence of leading
zeros and ignoring any effect this might have on number representation.
The command "opera 000300.000250.0007.0002" causes Opera to complain
"Internal communication error. Check that the address is spelled
correctly, or try searching for the site." and show
"http://000300.000250.0007.0002/" as the address it can't find. It
appears that if any of the four values have leading zeros, Opera treats
the string as a host name - which defeats the purpose of this
obfuscation.
However, you were right about Lynx: it does apply octal coding rules and
so falls into the category of web browsers jdow was asking about:
"lynx 000300.000250.0007.0002" finds my web server and displays its
front page.
Martin
Re: Question for experts....
Posted by Dave Warren <li...@hireahit.com>.
On 11/28/2011 7:37 PM, Martin Gregorie wrote:
> On Mon, 2011-11-28 at 18:35 -0800, jdow wrote:
>
>> It is a way of obfuscating that's over the top and nobody has a way to
>> get those oddball formulations easily from standard tools. They become
>> an excellent way of leading people to strange addresses with strings
>> that include ?ASFDikmedsfok3l1masdh sort of text following the index.html.
>>
> OK, here's a pair of data points: on my system 192.168.7.2 is the IP of
> a web server on port 80.
>
> I tried feeding "000192.000168.0007.0002" to Lynx and Opera as the sole
> command line argument:
Wouldn't that be 000300.000250.0007.0002 ? Or did I miss a step here?
--
Dave Warren, CEO
Hire A Hit Consulting Services
http://ca.linkedin.com/in/davejwarren
Re: Question for experts....
Posted by Martin Gregorie <ma...@gregorie.org>.
On Mon, 2011-11-28 at 18:35 -0800, jdow wrote:
> It is a way of obfuscating that's over the top and nobody has a way to
> get those oddball formulations easily from standard tools. They become
> an excellent way of leading people to strange addresses with strings
> that include ?ASFDikmedsfok3l1masdh sort of text following the index.html.
>
OK, here's a pair of data points: on my system 192.168.7.2 is the IP of
a web server on port 80.
I tried feeding "000192.000168.0007.0002" to Lynx and Opera as the sole
command line argument:
lynx 2.8.7 tried several variations on the input theme before giving up.
The permutations it tried show that it thought it was
dealing with a malformed host name.
opera 11.52 reported that this URL was garbage and quit, so it too
thought it was a host name rather than an IP address.
Both do exactly the same if this string is entered in the URL bar
(Opera) or when prompted after hitting G (go).
Both accept "192.168.7.2" as a valid IP when entered as a command line
argument or from a display screen as described above.
Martin
Re: Question for experts....
Posted by jdow <jd...@earthlink.net>.
On 2011/11/28 17:49, C. Bensend wrote:
>
>>> I guess I'm confused why you think this is a vulnerability... It's
>>> simply another way to represent an IP address that browsers grok.
>>> Is it obfuscation? Sure. But hell, for the average internet user,
>>> a NON-obfuscated IP address is cryptic enough. ;) This is just
>>> another way to do it...
>>
>> Might I suggest reading the specification for URLs. I believe that
>> only DNS addresses and decimal dotted quads are "legal". The other
>> misrepresentations are not permitted so responding to them is a bug
>> for a browser or other URL based tool. If I'm wrong I'd like to know
>> with the appropriate URL RFC cited.
>>
>> {^_^}
>
> I didn't say legal. :) Browsers have a long and rich history of
> bending/breaking the "rules" in order to make the browsing experience
> faster/better/insert-buzzword-here.
>
> HTML content (web pages, rich email, blah blah blah) is horrifying
> nowadays. Standards? Nope, standards get in the way. I wouldn't
> be surprised if a vast majority of the HTML clients out there (web
> browsers, email clients, etc) exhibit this behavior.
>
> There's a difference between "vulnerability" and "it works anyway".
> Honest question - do you believe this is a *vulnerability*, or are
> you just irritated because it's happening? :)
>
> Not intending to come across as snarky... I just don't think this
> is a bug or vulnerability, but probably considered a "feature".
It is a way of obfuscating that's over the top and nobody has a way to
get those oddball formulations easily from standard tools. They become
an excellent way of leading people to strange addresses with strings
that include ?ASFDikmedsfok3l1masdh sort of text following the index.html.
If it was only one browser that responded to the oddball addresses at this
time then it would be a way to target that browser with a zero day
vulnerability it has for installing malware.
Since it seems (I register astonishment here) that all browsers respond
to this. So that targeted malware idea does not fit anymore. It is
possibly something that facilitates hiding bad addresses from spam
filters and currently buys nothing for the browsing experience. That
means it's a small amount of code bloat for those upset by that concept.
(Enh - what me worry? 24 gigabytes is hard to fill without MUCH larger
examples of bloat. {^_-})
Basically, all I was looking for is who might respond to that sort of
an address to see if it was indeed one specific browser. That would
raise concerns that having all browsers respond doesn't.
What's amusing is how few answered the actual question and how many
presumed I could barely tie my shoe-laces. {^_-}
{^_^}
Re: Question for experts....
Posted by "C. Bensend" <be...@bennyvision.com>.
>> I guess I'm confused why you think this is a vulnerability... It's
>> simply another way to represent an IP address that browsers grok.
>> Is it obfuscation? Sure. But hell, for the average internet user,
>> a NON-obfuscated IP address is cryptic enough. ;) This is just
>> another way to do it...
>
> Might I suggest reading the specification for URLs. I believe that
> only DNS addresses and decimal dotted quads are "legal". The other
> misrepresentations are not permitted so responding to them is a bug
> for a browser or other URL based tool. If I'm wrong I'd like to know
> with the appropriate URL RFC cited.
>
> {^_^}
I didn't say legal. :) Browsers have a long and rich history of
bending/breaking the "rules" in order to make the browsing experience
faster/better/insert-buzzword-here.
HTML content (web pages, rich email, blah blah blah) is horrifying
nowadays. Standards? Nope, standards get in the way. I wouldn't
be surprised if a vast majority of the HTML clients out there (web
browsers, email clients, etc) exhibit this behavior.
There's a difference between "vulnerability" and "it works anyway".
Honest question - do you believe this is a *vulnerability*, or are
you just irritated because it's happening? :)
Not intending to come across as snarky... I just don't think this
is a bug or vulnerability, but probably considered a "feature".
Benny
--
"Cats land on their feet. Toast lands peanut butter side down. A cat
with toast strapped to its back will hover above the ground in a state
of quantum indecision." -- Unknown
Re: Question for experts....
Posted by jdow <jd...@earthlink.net>.
On 2011/11/28 17:05, C. Bensend wrote:
>
>> Why bug such people unless their product IS vulnerable? Note that this
>> seems
>> to be an email trying to get people who have a "vulnerable" browser to
>> click
>> a specific link. I'd expect that link to be loaded with a zero day or the
>> likes that the browser exhibits.
>>
>> I figured people here with their basic interest in security might know of
>> vulnerable browsers to make progressing to the next logical steps easy. I
>> am
>> somewhat surprised NOBODY here seems to know.
>>
>> {^_^}
>
> I guess I'm confused why you think this is a vulnerability... It's
> simply another way to represent an IP address that browsers grok.
> Is it obfuscation? Sure. But hell, for the average internet user,
> a NON-obfuscated IP address is cryptic enough. ;) This is just
> another way to do it...
Might I suggest reading the specification for URLs. I believe that
only DNS addresses and decimal dotted quads are "legal". The other
misrepresentations are not permitted so responding to them is a bug
for a browser or other URL based tool. If I'm wrong I'd like to know
with the appropriate URL RFC cited.
{^_^}
Re: Question for experts....
Posted by "C. Bensend" <be...@bennyvision.com>.
> Why bug such people unless their product IS vulnerable? Note that this
> seems
> to be an email trying to get people who have a "vulnerable" browser to
> click
> a specific link. I'd expect that link to be loaded with a zero day or the
> likes that the browser exhibits.
>
> I figured people here with their basic interest in security might know of
> vulnerable browsers to make progressing to the next logical steps easy. I
> am
> somewhat surprised NOBODY here seems to know.
>
> {^_^}
I guess I'm confused why you think this is a vulnerability... It's
simply another way to represent an IP address that browsers grok.
Is it obfuscation? Sure. But hell, for the average internet user,
a NON-obfuscated IP address is cryptic enough. ;) This is just
another way to do it...
Benny
PS: My Firefox (8.0) and my IE (8.0.whatever.build) both retrieved
an HTML document, or at least presented an "empty" one with only
a header.
--
"Cats land on their feet. Toast lands peanut butter side down. A cat
with toast strapped to its back will hover above the ground in a state
of quantum indecision." -- Unknown
Re: Question for experts....
Posted by jdow <jd...@earthlink.net>.
On 2011/11/28 14:36, darxus@chaosreigns.com wrote:
> On 11/28, jdow wrote:
>>>>> Which browser(s) treat addresses of the form
>>>>> 178.000235.0000150.000372 as actual addresses? That seems like a
>
> If you have multiple emails with this pattern that spamassassin is not
> catching, please provide them via something like pastebin. We can create
> rules to match it, and see if it correlates well to spam. Otherwise,
> I'm not sure how relevant this subject is to this list.
Sigh, this is why I asked for experts - people who might know what
browser is vulnerable so the guilty parties could be notified. (I am
betting it's a Microsoft browser if the bug is still present.)
>> The implication is that it's yet another way to obfuscate addresses. It
>> is NOT legal in a URL regardless of its legality in C. Any browser that
>> reads that URL is broken. Which one(s) accept it? They probably have a
>> gaping vulnerability the URL in question takes advantage of.
>
> The solution to that problem, if it is a problem, is to submit bug
> reports to the web browser maintainers. Discussing whether or not it
> is a problem, on this list, is probably of limited use.
This may need a formal SpamAssassin rule rather than relying on the old
SARE rules, which did trigger on it. That's up to somebody else to worry
about.
> It may be more useful to discuss it on
> http://irtf.org/mailman/listinfo/asrg
>
> I can confirm that chromium converts octets starting with 0 to octal. It's
> less obvious what firefox does with it.
That's a hint for the people who might want to fix the bug. Someone else
remarked FireFox used to respond to such trash and does not now.
> https://bugzilla.mozilla.org/
> http://code.google.com/p/chromium/issues/entry
> https://bugs.opera.com/wizard/
> http://developer.apple.com/bugreporter/
Why bug such people unless their product IS vulnerable? Note that this seems
to be an email trying to get people who have a "vulnerable" browser to click
a specific link. I'd expect that link to be loaded with a zero day or the
likes that the browser exhibits.
I figured people here with their basic interest in security might know of
vulnerable browsers to make progressing to the next logical steps easy. I am
somewhat surprised NOBODY here seems to know.
{^_^}
Re: Question for experts....
Posted by da...@chaosreigns.com.
On 11/28, jdow wrote:
> >>>Which browser(s) treat addresses of the form
> >>>178.000235.0000150.000372 as actual addresses? That seems like a
If you have multiple emails with this pattern that spamassassin is not
catching, please provide them via something like pastebin. We can create
rules to match it, and see if it correlates well to spam. Otherwise,
I'm not sure how relevant this subject is to this list.
> The implication is that it's yet another way to obfuscate addresses. It
> is NOT legal in a URL regardless of its legality in C. Any browser that
> reads that URL is broken. Which one(s) accept it? They probably have a
> gaping vulnerability the URL in question takes advantage of.
The solution to that problem, if it is a problem, is to submit bug
reports to the web browser maintainers. Discussing whether or not it
is a problem, on this list, is probably of limited use.
It may be more useful to discuss it on
http://irtf.org/mailman/listinfo/asrg
I can confirm that chromium converts octets starting with 0 to octal. It's
less obvious what firefox does with it.
https://bugzilla.mozilla.org/
http://code.google.com/p/chromium/issues/entry
https://bugs.opera.com/wizard/
http://developer.apple.com/bugreporter/
--
"Life is either a daring adventure or it is nothing at all."
- Helen Keller
http://www.ChaosReigns.com
Re: Question for experts....
Posted by jdow <jd...@earthlink.net>.
On 2011/11/28 05:43, RW wrote:
> On Sun, 27 Nov 2011 22:43:00 +0100
> Thierry Besancon wrote:
>
>> On 2011-11-27 13:26:43, jdow wrote:
>>> Which browser(s) treat addresses of the form
>>> 178.000235.0000150.000372 as actual addresses? That seems like a
>>> serious fault in the browsers.
>>
>> According to C standards, a number beginning with a 0 is an base 8
>> number.
>>
>> So 000235 is legal. It means 157 in decimal.
>> So 000150 is legal. It means 104 in decimal.
>> So 000372 is legal. It means 250 in decimal.
>>
>> So this is address 178.157.104.250 which is a legal IP address.
>>
>> So there is no serious fault. Just your ignorance of C programming ;-)
>
> The doesn't have anything to do with C programming. The implication
> is that a browser might ignore leading zeros when parsing an IP address.
The implication is that it's yet another way to obfuscate addresses. It
is NOT legal in a URL regardless of its legality in C. Any browser that
reads that URL is broken. Which one(s) accept it? They probably have a
gaping vulnerability the URL in question takes advantage of.
{^_^}
Re: Question for experts....
Posted by RW <rw...@googlemail.com>.
On Sun, 27 Nov 2011 22:43:00 +0100
Thierry Besancon wrote:
> On 2011-11-27 13:26:43, jdow wrote:
> > Which browser(s) treat addresses of the form
> > 178.000235.0000150.000372 as actual addresses? That seems like a
> > serious fault in the browsers.
>
> According to C standards, a number beginning with a 0 is an base 8
> number.
>
> So 000235 is legal. It means 157 in decimal.
> So 000150 is legal. It means 104 in decimal.
> So 000372 is legal. It means 250 in decimal.
>
> So this is address 178.157.104.250 which is a legal IP address.
>
> So there is no serious fault. Just your ignorance of C programming ;-)
The doesn't have anything to do with C programming. The implication
is that a browser might ignore leading zeros when parsing an IP address.
Re: Question for experts....
Posted by jdow <jd...@earthlink.net>.
On 2011/11/27 13:43, Thierry Besancon wrote:
> On 2011-11-27 13:26:43, jdow wrote:
>> Which browser(s) treat addresses of the form 178.000235.0000150.000372 as
>> actual addresses? That seems like a serious fault in the browsers.
>
> According to C standards, a number beginning with a 0 is an base 8 number.
>
> So 000235 is legal. It means 157 in decimal.
> So 000150 is legal. It means 104 in decimal.
> So 000372 is legal. It means 250 in decimal.
>
> So this is address 178.157.104.250 which is a legal IP address.
>
> So there is no serious fault. Just your ignorance of C programming ;-)
>
> Best regards,
> Thierry Besancon
>
Please see my explanation. It's a matter of obfuscation. The 178.157.104.250
is more than sufficient obfuscation. It is useful enough for savvy users that
browsers should recognize but warn the user. The other form in an email is
raw obfuscation. Feeding an address such as that to a browser from an email
program should be either disallowed or raise annoying flags. Making life easier
for malware authors is just a wee bit over the top for my tastes.
{^_^}
Re: Question for experts....
Posted by Mahmoud Khonji <m...@khonji.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/28/2011 01:43 AM, Thierry Besancon wrote:
> On 2011-11-27 13:26:43, jdow wrote:
>> Which browser(s) treat addresses of the form
>> 178.000235.0000150.000372 as actual addresses? That seems like a
>> serious fault in the browsers.
>
> According to C standards, a number beginning with a 0 is an base 8
> number.
>
> So 000235 is legal. It means 157 in decimal. So 000150 is legal. It
> means 104 in decimal. So 000372 is legal. It means 250 in decimal.
>
> So this is address 178.157.104.250 which is a legal IP address.
>
> So there is no serious fault. Just your ignorance of C programming
> ;-)
>
> Best regards, Thierry Besancon
use of octal numbers in the dotted IPv4 address is against the URI
specification standard. C standards are not relevant to the URI
standard (see section 7.4. in rfc3986).
according to rfc3986 section 3.2.2, only one form of dotted IPv4
formats are allowed: that's the dotted decimals.
section 7.4 in rfc3986 does mention some security considerations.
- --
Regards,
Mahmoud Khonji
PGP Key: 0x92584ECA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJO0ruqAAoJEFzU5FSSWE7KPeQIAI3GbWHP/H0HUSEfu3PCoimy
v0VsdRDRisfqn1iPbJc7+8wofbXTDUdYCdbqYf4UHhG3ECSYg9gta39FFkg4TpOi
BEYPQroZrtqY0/fM2txvu1Z5FWe0IStKtkixhPWo1fzUxpXfuFrBkGW3cVWmSoBn
aP5Cjsrbb+awbnsFUpIypzxAGymRi+09a9eJQPhIrstwWX8acch4G4bKbltLUZDi
FXDosdOXJpVLvy567fjCrLAW7a5+xPSEjSoXHTRfcxwzT3SLLGMo8FZfyLbf+VbM
WbrbrBJyzXi5ZLoOpm93YlkoWo5rcYT8KPxMAHRMRCzXTMeu65XEoimZOzJS9HU=
=Evqe
-----END PGP SIGNATURE-----
Re: Question for experts....
Posted by Thierry Besancon <be...@math.jussieu.fr>.
On 2011-11-27 13:26:43, jdow wrote:
> Which browser(s) treat addresses of the form 178.000235.0000150.000372 as
> actual addresses? That seems like a serious fault in the browsers.
According to C standards, a number beginning with a 0 is an base 8 number.
So 000235 is legal. It means 157 in decimal.
So 000150 is legal. It means 104 in decimal.
So 000372 is legal. It means 250 in decimal.
So this is address 178.157.104.250 which is a legal IP address.
So there is no serious fault. Just your ignorance of C programming ;-)
Best regards,
Thierry Besancon