Closed
Bug 95488
Opened 23 years ago
Closed 23 years ago
Port number blocking uses 16 - 32 bit compares
Categories
(Core :: Security, defect)
Tracking
()
VERIFIED
FIXED
mozilla0.9.4
People
(Reporter: dougt, Assigned: dougt)
Details
(Keywords: topembed, Whiteboard: [ckritzer] verify linux)
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•23 years ago
|
Severity: normal → critical
OS: Windows 2000 → All
Hardware: PC → All
Assignee | ||
Comment 1•23 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
Comment 2•23 years ago
|
||
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•23 years ago
|
||
sr=darin
Assignee | ||
Comment 4•23 years ago
|
||
fixed on trunk.
Comment 5•23 years ago
|
||
Teh bug is still opne. Do you inteend to check it in on the 0.9.2 branch?
Comment 6•23 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•23 years ago
|
Severity: normal → blocker
Target Milestone: --- → mozilla0.9.4
Assignee | ||
Comment 7•23 years ago
|
||
fix checked into 0.9.2 branch. Marking this bug fixed.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 8•23 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•23 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.
Description
•