Port number blocking uses 16 - 32 bit compares

VERIFIED FIXED in mozilla0.9.4

Status

()

Core
Security
--
blocker
VERIFIED FIXED
16 years ago
16 years ago

People

(Reporter: dougt, Assigned: dougt)

Tracking

({topembed})

Trunk
mozilla0.9.4
x86
Windows 2000
topembed
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ckritzer] verify linux)

(Assignee)

Description

16 years ago
from BugTraq
Re: HTML Form Protocol Attack

mozilla 0.9.1

Pops up message:
"Access to the port number given has been disabled for security reasons."
When I tried to get it to connect to ftp (port 21) - however if you add
65536 to this value, so try submitting the form to 65557 it doesn't
complain and will connect to port 21, but gets stuck halfway through
the transmission, without submitting the evil data. Maybe there is a
way round that though.

Updated

16 years ago
Severity: normal → critical
OS: Windows 2000 → All
Hardware: PC → All
(Assignee)

Comment 1

16 years ago
since changin all the signatures would be a drag, an explict conversion here
will do.

Index: nsIOService.cpp
===================================================================
RCS file: /cvsroot/mozilla/netwerk/base/src/nsIOService.cpp,v
retrieving revision 1.101
diff -u -r1.101 nsIOService.cpp
--- nsIOService.cpp	2001/08/14 07:59:50	1.101
+++ nsIOService.cpp	2001/08/15 20:56:49
@@ -56,7 +56,7 @@
 // TODO: I am sure that there are more ports to be added.  
 //       This cut is based on the classic mozilla codebase
 
-PRInt32 gBadPortList[] = { 
+PRInt16 gBadPortList[] = { 
   1,    // tcpmux          
   7,    // echo     
   9,    // discard          
@@ -765,8 +765,9 @@
 
 
 NS_IMETHODIMP
-nsIOService::AllowPort(PRInt32 port, const char *scheme, PRBool *_retval)
+nsIOService::AllowPort(PRInt32 inPort, const char *scheme, PRBool *_retval)
 {
+    PRInt16 port = inPort;
     if (port == -1) {
         *_retval = PR_TRUE;
         return NS_OK;
Severity: critical → normal
OS: All → Windows 2000
Hardware: All → PC
r=bbaetz, and nominating for topembed

Anyone feel like changing all port numbers in the code to unsigned 16 bit ints
at some point?
Keywords: topembed

Comment 3

16 years ago
sr=darin
(Assignee)

Comment 4

16 years ago
fixed on trunk.

Comment 5

16 years ago
Teh bug is still opne. Do you inteend to check it in on the 0.9.2 branch?

Comment 6

16 years ago
ckritzer@netscape.com, please verify this on trunk build that has this fix.
dougt@netscape.com, when this is verified please check it into 0.9.2 branch
(Assignee)

Updated

16 years ago
Severity: normal → blocker
Target Milestone: --- → mozilla0.9.4
(Assignee)

Comment 7

16 years ago
fix checked into 0.9.2 branch.

Marking this bug fixed.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 8

16 years ago
Okay, http://voodoolady.mcom.com/security/bugs/bugzilla95488.html has the
testcase[s].


For today's trunk bits of 2001-08-17-xx-trunk on Win98SE, MacOSX & OS9,
everything is perfect.  All ports listed throw the correct alert.

Today's commercial linux bits crash for me, so I'll have to check again for some
mozilla bits.  

On the linux build of the 15 (commercial), I get no error dialog thrown on ports:
65536, 65557, 65561, 65671, 67585, 69581, 71536, 131093
and on port 65675,  I get a download type application/octet-stream dialog.  Very
weird.
Whiteboard: [ckritzer] verify linux

Comment 9

16 years ago
Okay, also verified this on 2001-08-17-15-trunk for LinRH62, and it looks great.
 The problems I was seeing (mentioned above) for the linux build a few days ago
are non-existent.

Marking VERIFIED FIXED.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.