Last Comment Bug 100154 - Connections opened on loopback (127.0.0.1) show in NETSTAT and ZoneAlarm has "server rights" alerts
: Connections opened on loopback (127.0.0.1) show in NETSTAT and ZoneAlarm has ...
Status: VERIFIED WONTFIX
:
Product: NSPR
Classification: Components
Component: NSPR (show other bugs)
: 3.0
: x86 Windows 2000
: -- minor with 2 votes (vote)
: Future
Assigned To: Wan-Teh Chang
: Wan-Teh Chang
Mentors:
http://(none)
: 72844 97084 158518 158864 204539 238806 279707 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2001-09-17 13:43 PDT by Dan Mellem
Modified: 2014-01-30 20:22 PST (History)
26 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Dan Mellem 2001-09-17 13:43:44 PDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20010913
BuildID:    2001091303

Whenever Mozilla is running there are two connections to the loopback address
that are connected to each other. The ports change but they are usually
lower-numbered unregistered ports.

Run one:
  TCP    127.0.0.1:1153         127.0.0.1:1154         ESTABLISHED
  TCP    127.0.0.1:1154         127.0.0.1:1153         ESTABLISHED
Quit and re-launch Mozilla:
  TCP    127.0.0.1:1210         127.0.0.1:1211         ESTABLISHED
  TCP    127.0.0.1:1211         127.0.0.1:1210         ESTABLISHED

It seems unusual to go to the IP stack for internal usage. Can connecting to
these ports with another program cause undesired operation?


Reproducible: Always
Steps to Reproduce:
1. Run Mozilla
2. From DOS, type "netstat -n"
3.

Occurs on Windows '98 (and perhaps others) as well.
Comment 1 Matthias Versen [:Matti] 2001-10-07 20:06:13 PDT
confirming with win2k build 20011007..
There is somewhere a dupe of this one but I can't find it.
Comment 2 benc 2001-10-08 19:16:44 PDT
I vaguely recall some PSM related behavior...
Comment 3 Matthias Versen [:Matti] 2001-10-08 21:39:11 PDT
CC ssaux@netscape.com :
Can you help us with this ? Is this PSM related ?
Comment 4 Stephane Saux 2001-10-09 19:45:12 PDT
Javi, David, can you comment?
Thanks.
Comment 5 Javier Delgadillo 2001-10-10 10:25:53 PDT
PSM 1 used to create sockets to 127.0.0.1, current PSM implementation creates
*zero* new sockets unless instructed to by necko.
Comment 6 dennis 2001-10-26 06:34:52 PDT
Confirmed on Win9x:

  TCP    athlon:1373         loopback:1374          ESTABLISHED
  TCP    athlon:1374         loopback:1373          ESTABLISHED

This is strange, shouldn't happen. If that's needed for PSM or anything else, why ?
Comment 7 Javier Delgadillo 2001-10-26 10:17:01 PDT
This isn't a PSM issue.  kaie looked into this matter, so he'll be better suited
to provide an explanation of what's going on.
Comment 8 benc 2001-10-26 13:04:40 PDT
-> trivial
neeti: who can explain this behavior? It might be some PSM 1.0 leftovers?
Comment 9 Dan Mellem 2001-10-26 14:04:54 PDT
This may be trivial but it is unknown because two ports are opened. If these can
be used as a DoS against Mozilla or it can be used to extract information (such
as from the Personal Security Manager) then this could actually be a critical
condition.
Comment 10 Javier Delgadillo 2001-10-26 14:16:06 PDT
Here are some e-mail threads on this very topic:

wtc responds to kaie's assessment of the problem:
Kai Engert wrote:
>
>I analyzed this and found the problem.
>
>I would like to agree with the reporter that this is an unacceptable security
>hole. However, it is not caused by PSM.
>
>The bug does not apply to Linux and Unix, but to all other platforms including
>Windows and Mac.
>
>Mozilla's lower level libraries, NSPR, creates two listening sockets to
>implement some functionality, to provide for "pollable events".
>

No, the non-Unix implementation of PR_NewTCPSocketPair
creates only one, not two, listening socket.  That
listening socket is bound to the loopback network
interface.  My understanding is that only a local
process can connect to the loopback interface.


>The original author of the code intended to make these sockets bind to the
>loopback interface. But there is a bug, one of the sockets is bound to the
"any" >device, which makes this socket reachable from anywhere.


The socket (f[0]) that is bound to the "any" device
is not a listening socket.  Binding a client socket
to the "any" device is not a bug.

Kai, could you verify by an experiment that only a
local process can connect to the loopback interface?


Wan-Teh


Terry Hayes wrote:

To summarize:

1) Wan-teh and I believe that this is not a serious security problem.
2) Personal firewall products will report that the browser is listening.  There
are two ways to deal with this:
 a) Get Zonealarm and others to report that the browser is listening only on the
LOCAL machine. In other words, distinguish the local case from listening
on the  network in general.
 b) Document this behavior in our release notes and on our web site (in
a FAQ or similar)
3) There is a small chance that a program running on the LOCAL machine
can connect to the listener socket rather than the other socket of the
pair (the timing has to be good).  In this case the browser applcation may
not function correctly.  There are probably two modes:
 a) The "attacker" feeds events continuously, causing N6 do use a large
amount of CPU for no reason.
 b) The "attacker" does nothing, which means that N6 will not get
events that were intended for it.  In this case a POLL timeout may cause
normal processing to occurr, but at a slow rate.  If the POLL is not
given a timeout, then the application may appear to hang.
4) There does not appear to be any possibility of a buffer overrun (NSPR
reads single bytes from the socket).
5) No sensitive data is ever written to this port.


It was also determined that the Win2K version of netstat was reporting "weird"
states as far as sockets listening.

dougt also tried telneting to a macine running the browser to try and exploit
this weaknes and was denied access.
Comment 11 Kai Engert (:kaie) 2001-10-26 15:36:27 PDT
Javi, thanks for adding the comments.

See also: bug 106496 which has been opened to avoid the risk of someone else
connecting to the internally used socket.
Comment 12 Mike Young 2002-02-15 01:18:20 PST
*** Bug 97084 has been marked as a duplicate of this bug. ***
Comment 13 Mike Young 2002-02-15 01:27:12 PST
Discussion in bug 97084 brought up the issue of ZoneAlarm (and possibly other),
a free personal firewall program, which alerts the user to the fact that Mozilla
is requesting "server rights" by opening a port for listening.

see http://bugzilla.mozilla.org/showattachment.cgi?attach_id=65811
attachment 65811 [details]

I've bumped this up from trivial to minor, because this is not only irritating,
but also might cause some problems for end users if they receive a scary dialog
when using Mozilla. (And don't get it in any other browser) There really is no
reason for mozilla to have this port open...

Adding ZoneAlarm to summary to catch dups...
Comment 14 Ilgaz Öcal 2002-03-24 22:35:48 PST
This "bug" can be fixed by another way if it can't be fixed via code change.

I figured latest zonealarm build installs asks user if they want Zonealarm to
seek for their default (or all?) browsers and give them apporiate access rights.

As I am an end user, they won't listen to me. Mozilla/Netscape developers can
contact zonealarm stating that PSM is an open source product, a part of
Mozilla/Netscape browser and they should give local server (loopback) rights to
it if they already "trust" to Netscape 6/Mozilla.

As whole project is open source, zonealarm can easily (I bet they know network
things better than all) review the code before giving it access to 127.0.0.1 .

So, the point is, if they identify mozilla.exe, netscp6.exe and give it network
access rights, they should give PSM.exe the rights to make its job right.
Comment 15 benc 2002-03-25 08:03:34 PST
-> PSM.

Probably should create a bug and send it to evangelism.
Comment 16 Stephane Saux 2002-03-25 10:04:15 PST
This is not a PSM issue. See comment #10
Can you change it back to whatever it was or assign it to the proper component?
->benc
Comment 17 benc 2002-03-25 12:20:09 PST
I was zipping through bugmail, opened this bug and read #5 wrong.

Sorry.

->nspr.
Comment 18 Wan-Teh Chang 2002-03-25 14:49:48 PST
NSPR pollable events are implemented with a pair of
TCP sockets on Windows.  Unfortunately this requires opening
listening sockets on the loopback address temporarily.

In NSPR 4.2 I added code to PR_NewTCPSocketPair to
only accept a connection from the other socket created
by the same invocation of the function (bug 106496).
This should eliminate the security issue, but not the
temporary listening sockets.

I don't know how to implement NSPR pollable events
on Windows without using a pair of TCP sockets, so I am
marking this bug WONTFIX.
Comment 19 Matthias Versen [:Matti] 2002-03-25 15:36:57 PST
*** Bug 72844 has been marked as a duplicate of this bug. ***
Comment 20 crawdad 2002-06-20 07:07:35 PDT
No other browser does this. A browser should NOT require server rights to operate.
Since unruly behavior is HIGHLY undesireable and will cause SOME folx to
mistrust mozilla.
Justifiably so.

Leaving this bug as "resolved/wontfix" is WRONG!
This SHOULD BE FIXED!
In this age of paranoia, it should be obvious that this is undesireable behavior.
Comment 21 neojedi 2002-07-19 01:06:35 PDT
So, when zonealarm ask for server right, assigning or not server rights doesn't 
affect Mozilla , mozilla will always work good ? everybody is agree ?
Comment 22 Dimitrios 2002-07-19 12:18:25 PDT
At least, this is my experience from Mozilla and ZoneAlarm. Blocking serber
rights request permanently doesn't seem to affect Mozilla. But don't expect
everyone here to verify that. You need to experiment a little :-)
Comment 23 Matthias Versen [:Matti] 2002-07-21 03:52:46 PDT
*** Bug 158518 has been marked as a duplicate of this bug. ***
Comment 24 Matthias Versen [:Matti] 2002-07-23 17:11:55 PDT
*** Bug 158864 has been marked as a duplicate of this bug. ***
Comment 25 Jesse Ruderman 2002-09-08 17:38:45 PDT
*** Bug 99806 has been marked as a duplicate of this bug. ***
Comment 26 Asa Dotzler [:asa] 2004-02-24 16:04:46 PST
*** Bug 204539 has been marked as a duplicate of this bug. ***
Comment 27 Frank Wein [:mcsmurf] 2004-03-26 14:22:44 PST
*** Bug 238806 has been marked as a duplicate of this bug. ***
Comment 28 Dimitrios 2004-04-24 04:13:37 PDT
I don't get "server rights" alert with ZoneAlarm 4.5.538 (free version).  Thus,
the annoyance of this bug doesnt seem to exist anymore. Can someone else verify
please?
Comment 29 Matthias Versen [:Matti] 2004-04-24 07:46:45 PDT
 Proto  Lokale Adresse         Remoteadresse          Status
 TCP    127.0.0.1:1046         127.0.0.1:1047         HERGESTELLT
 TCP    127.0.0.1:1047         127.0.0.1:1046         HERGESTELLT

easy to check yourself with netstat
Comment 30 Dimitrios 2004-04-24 09:51:11 PDT
I didn't mean that there are no connections to the localhost address. The
original description to the bug is still valid. But my ZoneAlarm now doesn't ask
for granting server access to Mozilla/Firefox/Thunderbird. And I know of no
other application that might be disturbed by NSPR's behaviour.
Comment 31 Mike Capp 2004-09-26 18:21:38 PDT
No, it's still there. Firefox 1.0PR, ZoneAlarm (free version) 5.1.011. The
message now reads "Firefox wants to accept connections from the Internet". It
was rather disconcerting.

It doesn't appear all that often, and I think I've only seen it on one site (the
forums at http://www.fireflymovie.com/). Not a blocker by any means, but it'd be
nice to get rid of it if at all possible.
Comment 32 Matthias Versen [:Matti] 2004-09-27 16:16:52 PDT
v wontfix
Comment 33 Matthias Versen [:Matti] 2005-01-26 06:37:28 PST
*** Bug 279707 has been marked as a duplicate of this bug. ***
Comment 34 a4_roadrunner 2013-11-17 23:14:37 PST
Created attachment 8333697 [details]
Old Firefox Data-1(3).exe

NOTE: This flag is now for security issues only. Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
User impact if declined: 
Testing completed: 
Risk to taking this patch (and alternatives if risky): 
String or UUID changes made by this patch:

NOTE: This flag is now for security issues only. Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
User impact if declined: 
Testing completed: 
Risk to taking this patch (and alternatives if risky): 
String or UUID changes made by this patch:

[Approval Request Comment]
Regression caused by (bug #): 
User impact if declined: 
Testing completed (on m-c, etc.): 
Risk to taking this patch (and alternatives if risky):
String or IDL/UUID changes made by this patch:

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
User impact if declined: 
Testing completed (on m-c, etc.): 
Risk to taking this patch (and alternatives if risky): 
String or IDL/UUID changes made by this patch:
Comment 35 Dan Mellem 2013-11-18 00:10:24 PST
The attachment from a4_roadrunner@yahoo.com is a trojan (W32Autorun.worm.c). I don't know how to get it deleted or report the bogus account.
Comment 36 Dan Mellem 2013-11-18 00:12:03 PST
Comment on attachment 8333697 [details]
Old Firefox Data-1(3).exe

This is a trojan.
Comment 37 Byron Jones ‹:glob› 2013-11-18 00:50:36 PST
The content of attachment 8333697 [details] has been deleted for the following reason:

executable binary
Comment 38 dp 2014-01-30 20:22:19 PST
firefox.exe	1556	TCP	househp	1062	localhost	ESTABLISHED	4,110			1		 			
firefox.exe	1556	TCP	househp	1063	localhost	ESTABLISHED	4,113		1		 		                                                packets received !!

FF v 25

Note You need to log in before you can comment on or make changes to this bug.