Closed Bug 100154 Opened 23 years ago Closed 23 years ago

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

Categories

(NSPR :: NSPR, defect)

Product:
NSPR
Component:
NSPR
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX
Milestone:
Future

People

(Reporter: dsmutil, Assigned: wtc)

References

(
URL
)

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: 23 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.