CNE question? 127 loopback addressed

I'm not sure this is really a security issue. I talked to IANA.ORG
staff because ARIN indicated them as tied to 127 block addresses and
they thought it was a spoof/spam issue.

OK, what happens is my index.html page has an image with another web
page's URL linked to it, the second page is also called index.html but
in another subdirectory. This method has worked until I switched server
packages.

The 2nd page has a Javascript script. If I link to the second page, two
script identifier tags are inserted into my 'first' index.html page. I
become aware of this because some browsers choke on it and my html
editor doesn't like it either. The code that is inserted is a script
declaration statement and has a 127 loopback address in it.

I very much suspect there is a problem with how I am calling the
Javascript or exiting that page because I can delete the 'offending'
code, republish the page via FTP, view it to confirm the problem code
is NOT back in there, then access that page repeatedly, apparently
without it recurring. It seems that accessing the link to the JS causes
it to be written into the linking page.

I'm going to do some more experiments to see if I can access the JS
directly (then there is no referring page for an 'artifact' to be left
in.


I have two questions after reading the IANA and RFC info below:

1) If a 127 IP address is used only for a computer to identify itself,
to itself, over a network, at what level does this happen? Inside a
packet my pc sends out while communication over the web? So possibly, I
am seen at some level by the hosting location as IP address 127.0.0.1?

2) Any idea what process on a server would have admin rights to insert
code into someone's pages? Gosh, that sound like what happens everyday
to sites with advertising!

If I can understand this well enough I may be able to figure out what's
causing it. It's no surprise asking ISP and hosting companies results
in finger pointing - it's alwasy been that way.

IANA web page provided me with two pieces of info...

"Loopback" IP addresses:

127.0.0.0 - 127.255.255.255

Each computer on the Internet uses 127.0.0.0/8 to identify itself, to
itself. 127.0.0.0 to 127.255.255.255 is earmarked for what is called
"loopback". This construct allows a computer to establish/validate its
IP stack. Most software only uses 127.0.0.1 for loopback purposes (the
other addresses in this range are seldom used). All of the addresses
within the loopback address are treated with the same levels of
restriction in Internet routing, so it is difficult to use any other
addresses within this block for anything other than node specific
applications, generally bootstraping. This is documented in RFC 3330.

The second was RFC3330. I don't know what an RFC is, perhaps a
bureaucratic document...I read it where it discusses 127 block of IP
addresses.

127.0.0.0/8 - This block is assigned for use as the Internet host
loopback address. A datagram sent by a higher level protocol to an
address anywhere within this block should loop back inside the host.
This is ordinarily implemented using only 127.0.0.1/32 for loopback,
but no addresses within this block should ever appear on any network
anywhere [RFC1700, page 5].


My host company is blaming my web publishing software but I can
demonstrate that is not how it occurs.

I think there is some call that is written poorly and it causes some
process to be handled incorrectly and the server somehow thinks it's
fixing the problem. It's definitely automated.

Murray
Holland MI

murrayatuptowngallery@yahoo.com

On 17 Feb 2006 16:09:08 -0800, wrote:

>I have two questions after reading the IANA and RFC info below:
>
>1) If a 127 IP address is used only for a computer to identify itself,
>to itself, over a network, at what level does this happen? Inside a
>packet my pc sends out while communication over the web? So possibly, I
>am seen at some level by the hosting location as IP address 127.0.0.1?
######################################
That can't be because the hosting location sees itself as 127.0.0.1
All machines see themselves as that AFAIK.
######################################

>
>2) Any idea what process on a server would have admin rights to insert
>code into someone's pages? Gosh, that sound like what happens everyday
>to sites with advertising!
#######################################
An script, cron job (unix terminology) or scheduled task (windows
teminology) running as root or admin has the right to insert anything
into anything.
#######################################

>If I can understand this well enough I may be able to figure out what's
>causing it. It's no surprise asking ISP and hosting companies results
>in finger pointing - it's alwasy been that way.
########################################
I don't see what the ISP would have to do w/ it. Try another hosting
company.

donnie

I don't see what the ISP has to do with it either, but that's what IANA
suggested.

Only thingI can think of that involves ISP even tangentially is the
fact that they are my connection and possibly who pass the 127 along,
assuming my pc generates it (TCP/IP or some other networking process I
and most users have no need to be involved in).

Yes, a different hosting co. is an option, but considering the
randomness of me having a problem with any given hosting co., the
potential of me producing or misusing html/JS inadvertently, etc.,
still puts me in the position of figuring out all I can about what
causes it in case it IS something I need to fix. If I change hosts for
inadequate answers, upload the same code to another host and find I
have the same problem, I still get to say 'Duh, what's happening?'.
I'll get further by understanding the circumstances and trying to adapt
to them than trying to change the tech support I get.That's another
random variable. Changing companies in my experience doesn't
necessarily put me in touch with a more competent person.
Unfortunately, sometimes if you want something done right you have to
do it yourself (and make who knows how many errors in the process).


Maybe it would be instructive to set this up on another site (a free
one for the sake of experimentation) and see if it acts the same.

I think in the end it may come down to the server doing this because it
doesn't like something I'm asking it to do & I have to find another
way.

Thanks for the reply.

M

murrayatuptowngallery@yahoo.com

On 18 Feb 2006 10:20:05 -0800, wrote:

> Changing companies in my experience doesn't
>necessarily put me in touch with a more competent person.
###########################################
Agreed, but before you change, talk to someone at the company that
you may decide to use. Determine if they have the knowledge and the
interest to help you.
You could also register another domain and put your web site there or
run a mirror somewhere as a test.

donnie

On 17 Feb 2006, in the Usenet newsgroup alt.computer.security, in article
<. com>,
wrote:

>I'm not sure this is really a security issue.

No, it's a web authoring problem.

>The code that is inserted is a script declaration statement and has a
>127 loopback address in it.

Google suggests you are using windoze (which I never bothered with). Is
your system able to figure out it's "real name" (meaning an Internet
resolvable name and IP address) or does it "assume" the "localhost"
because it can't determine otherwise? Servers should know their
proper name, and thus your web authoring software should insert the
full hostname (or at least the IP address) in your page. It's not doing
that, and that is the root sum of your problem.

>I very much suspect there is a problem with how I am calling the
>Javascript or exiting that page

Yes. A packet sniffer would show you that the URL _in_ your web page
is localhost. Looking at the raw text of the page would ALSO show this.

>1) If a 127 IP address is used only for a computer to identify itself,
>to itself, over a network, at what level does this happen?

The application requests the kernel to send this packet to "some" host.
The kernel then makes a decision of which interface to use as well as
which IP address. However that's different from your authoring tool
telling the client to get the page from "this" computer (which it is
identifying as localhost or 127.0.0.1).

>Inside a packet my pc sends out while communication over the web?

If you are thinking hypertext, the packet may contain what ever the
web page author told it. It may or may not be valid. Your packet may
for example contain a URL which tells the client computer to load another
page from some address. It's up to you to see that the URL is valid.

>So possibly, I am seen at some level by the hosting location as IP
>address 127.0.0.1?

Never. 127.0.0.1 always refers to "me" Just for giggles, think about
sending a packet to some _other_ host that has a Destination Address in
the RFC0791 (IP) header of Some.Valid.IP.Address, and a Source Address
of 127.0.0.1. Ignoring the fact that any sanely configured router
should drop the packet per RFC 2827 (Network Ingress Filtering: Defeating
Denial of Service Attacks), how would the remote computer even acknowledge
your connection attempt - _never_mind_ actually getting so far as to
exchange data? The concept of "localhost" is _within_ the computer,
and should never be seen outside of the computer.

>2) Any idea what process on a server would have admin rights to insert
>code into someone's pages?

When you coded the web page, you were not able to get the URL to point
to the real hostname or IP address where the page resides. This sounds
like a crappy web authoring tool or improperly configured server (that
doesn't know it's FQDN) more than the server application inserting code
into an existing page.

>Gosh, that sound like what happens everyday to sites with advertising!

Advertising is inserted into the web page by the author, not any
intermediate application.

>If I can understand this well enough I may be able to figure out what's
>causing it.

Your coding isn't valid.

>It's no surprise asking ISP and hosting companies results in finger
>pointing - it's alwasy been that way.

True - it's not their job to see what's inside the web page. They're
only there to provide connectivity.

>The second was RFC3330. I don't know what an RFC is, perhaps a
>bureaucratic document

RFC Request For Comment. When adopted, these provide standards, information,
and recommendations. See RFC2026 and referenced documents.

2026 The Internet Standards Process -- Revision 3. S. Bradner. October
1996. (Format: TXT=86731 bytes) (Obsoletes RFC1602, RFC1871) (Updated
by RFC3667, RFC3668, RFC3932, RFC3979, RFC397 (Also BCP0009)
(Status: BEST CURRENT PRACTICE)

>My host company is blaming my web publishing software but I can
>demonstrate that is not how it occurs.

They're correct. It's inside the packet at the application level, not
in the transferral of the packet (which might actually be their
responsibility).

>I think there is some call that is written poorly and it causes some
>process to be handled incorrectly and the server somehow thinks it's
>fixing the problem. It's definitely automated.

I strongly believe it's either an incorrect identification of the
included page (you are using a 'file' tag rather than a full host
address and directory path), or your computer doesn't know what
hostname to put in there and is assuming 'localhost'. It's an
application error, not networking. Unfortunately, you don't see

... ... File not found, I'll load something *I* think is interesting.

In Message-ID <. com>
you continue:

>I don't see what the ISP has to do with it either, but that's what IANA
>suggested.

No, you're mis-interpreting things. Your web page says to go to 127.0.0.1
(more likely to "localhost"). The other computer tries to do what you
told it, and it can't find the referred page. Your ISP or IANA has nothing
to do with how you coded the page. Maybe RFC1180 might help you:

1180 TCP/IP tutorial. T.J. Socolofsky, C.J. Kale. Jan-01-1991.
(Format: TXT=65494 bytes) (Status: INFORMATIONAL)

>If I change hosts for inadequate answers, upload the same code to
>another host and find I have the same problem, I still get to say 'Duh,
>what's happening?'.

Precisely.

>Maybe it would be instructive to set this up on another site

If the other server knows it's full name, this might change. But I
doubt it very much.

>I think in the end it may come down to the server doing this because it
>doesn't like something I'm asking it to do & I have to find another
>way.

You know computers hate you, because they do EXACTLY what you tell them to

Old guy

Moe Trin