95488 - Port number blocking uses 16 - 32 bit compares

Status: VERIFIED FIXED

(Core :: Security, defect)

Description

[Doug Turner (:dougt)]

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.

Comment 1

[Doug Turner (:dougt)]

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;

Comment 2

[Bradley Baetz (:bbaetz)]

r=bbaetz, and nominating for topembed

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

Comment 3

[Darin Fisher]

sr=darin

Comment 4

[Doug Turner (:dougt)]

fixed on trunk.

Comment 5

[Ben Bucksch (:BenB)]

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

Comment 6

[Marek Z. Jeziorek]

[e-mail], please verify this on trunk build that has this fix.
[e-mail], when this is verified please check it into 0.9.2 branch

Comment 7

[Doug Turner (:dougt)]

fix checked into 0.9.2 branch.

Marking this bug fixed.

Comment 8

[ckritzer (gone)]

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.

Comment 9

[ckritzer (gone)]

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.