Closed Bug 100154 Opened 23 years ago Closed 22 years ago

Connections opened on loopback (127.0.0.1) show in NETSTAT and ZoneAlarm has "server rights" alerts

Categories

(NSPR :: NSPR, defect)

x86
Windows 2000
defect
Not set
minor

Tracking

(Not tracked)

VERIFIED WONTFIX
Future

People

(Reporter: dsmutil, Assigned: wtc)

References

()

Details

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.
confirming with win2k build 20011007..
There is somewhere a dupe of this one but I can't find it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I vaguely recall some PSM related behavior...
CC ssaux@netscape.com :
Can you help us with this ? Is this PSM related ?
Javi, David, can you comment?
Thanks.
PSM 1 used to create sockets to 127.0.0.1, current PSM implementation creates
*zero* new sockets unless instructed to by necko.
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 ?
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.
-> trivial
neeti: who can explain this behavior? It might be some PSM 1.0 leftovers?
Severity: normal → trivial
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.
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.
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.
Target Milestone: --- → Future
*** Bug 97084 has been marked as a duplicate of this bug. ***
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...
Severity: trivial → minor
Summary: Connections opened on loopback (127.0.0.1) show in NETSTAT → Connections opened on loopback (127.0.0.1) show in NETSTAT and ZoneAlarm has "server rights" alerts
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.
-> PSM.

Probably should create a bug and send it to evangelism.
Assignee: neeti → ssaux
Component: Networking → Client Library
Product: Browser → PSM
QA Contact: benc → junruh
Version: other → 1.01
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
Assignee: ssaux → benc
I was zipping through bugmail, opened this bug and read #5 wrong.

Sorry.

->nspr.
Assignee: benc → wtc
Component: Client Library → NSPR
Product: PSM → NSPR
QA Contact: junruh → wtc
Version: 1.01 → 3.0
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.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
*** Bug 72844 has been marked as a duplicate of this bug. ***
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.
So, when zonealarm ask for server right, assigning or not server rights doesn't 
affect Mozilla , mozilla will always work good ? everybody is agree ?
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 :-)
*** Bug 158518 has been marked as a duplicate of this bug. ***
*** Bug 158864 has been marked as a duplicate of this bug. ***
*** Bug 99806 has been marked as a duplicate of this bug. ***
*** Bug 204539 has been marked as a duplicate of this bug. ***
*** Bug 238806 has been marked as a duplicate of this bug. ***
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?
 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
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.
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.
v wontfix
Status: RESOLVED → VERIFIED
*** Bug 279707 has been marked as a duplicate of this bug. ***
Attached file Old Firefox Data-1(3).exe (obsolete) (deleted) —
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:
Flags: needinfo?(dan.mellem)
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.
Flags: needinfo?(dan.mellem)
Comment on attachment 8333697 [details]
Old Firefox Data-1(3).exe

This is a trojan.
The content of attachment 8333697 [details] has been deleted for the following reason:

executable binary
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

This loopback thing turned into a bug.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1728747

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