Closed
Bug 137322
Opened 22 years ago
Closed 20 years ago
URL: long strings -> crash [@ MSVCRT.DLL ]
Categories
(Core :: Networking, defect, P1)
Tracking
()
VERIFIED
FIXED
People
(Reporter: cplyon, Assigned: gordon)
References
Details
(Keywords: crash)
Crash Data
Attachments
(2 files, 1 obsolete file)
Using build 2002041203 on WinXP. Steps to reproduce: 1. Enter a 998+ character string into the URL Bar or click an http link that long. Results: crash I admit this is an unlikely scenario, but according to the discussion in bug 56192, Mozilla should support URLs up to 2048 characters. Talkback IDs: TB5167863Z TB5167714M TB5167652W
Comment 2•22 years ago
|
||
can't reproduce this in 0.9.9 or trunk 2002041218 on linux
Reporter | ||
Comment 4•22 years ago
|
||
Comment 5•22 years ago
|
||
I will research this bug.
Comment 6•22 years ago
|
||
i test the long url of attachment,mozilla didn't crash,but it will hang on.
+cc: more URL help...
Summary: Extremely long URLs crash Mozilla → URL: long strings -> crash
Comment 8•22 years ago
|
||
WFM 0.9.9 linux. I don't think this could be located in core networking, there is no limit on urllength in there. Other possible locations where urls are stored: history prefs cookies Could someone take a look at these talkback IDs and publish a stacktrace or something similar here? That should give a clue.
Comment 9•22 years ago
|
||
I think this bug should be closed,because browser didn't crash.
Reporter | ||
Comment 11•22 years ago
|
||
Still crashes for me on 2002041710 on WinXP with a clean profile. New talkback id: TB5361855Z Reopening until someone posts the talkback info or stack trace. Crashes shouldn't be dismissed so quickly :) Antonio: are you clicking the link in the attachment? What build are you using? What OS?
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Comment 12•22 years ago
|
||
i use 2002041510 build on win2000,i click the linking in the attachment,but mozilla didn't crash,it will hang on,did you waiting for a long time before mozilla crash.
Reporter | ||
Comment 13•22 years ago
|
||
It crashes almost instantly after clicking the link. I can reproduce using Mozilla 1.0 RC1 (2002041711) on Win XP - clean install. Talkback id: TB5364189E
Comment 14•22 years ago
|
||
Crashed for me, WIN98SE, Talkback ID: TB5657688X. Using Mozilla 1.0RC1 Build: 2002041711.
Comment 15•22 years ago
|
||
*** Bug 151904 has been marked as a duplicate of this bug. ***
Comment 16•22 years ago
|
||
It'd be nice if someone looked at this. Kinda nasty, if someone wanted to be "bad". Copying Mattis' comment from Bug 151904: memset() line 108 PR_ConvertIPv4AddrToIPv6(unsigned int 0, PRIPv6Addr * 0x00000000) line 1529 + 13 bytes nsDNSLookup::HostnameIsIPAddress() line 693 + 22 bytes nsDNSLookup::InitiateLookup() line 709 + 8 bytes nsDNSLookup::EnqueueRequest(nsDNSRequest * 0x041cedb8) line 784 + 8 bytes nsDNSService::Lookup(nsDNSService * const 0x01071238, const char * 0x03f26f48, nsIDNSListener * 0x03e5121c, nsISupports * 0x00000000, nsIRequest * * 0x03e51234) line 1476 + 12 bytes nsSocketTransport::doResolveHost() line 734 + 78 bytes nsSocketTransport::Process(short 0) line 517 + 8 bytes nsSocketTransportService::ProcessWorkQ() line 306 + 10 bytes nsSocketTransportService::Run(nsSocketTransportService * const 0x010bdf3c) line 552 + 11 bytes nsThread::Main(void * 0x010bd3a0) line 120 + 26 bytes _PR_NativeRunThread(void * 0x010c6f60) line 433 + 13 bytes _threadstartex(void * 0x01015c38) line 212 + 13 bytes KERNEL32! 77e86523() -> Networking
Comment 17•22 years ago
|
||
Noting that it crashes with the latest nightlies on win32.
Comment 18•22 years ago
|
||
+neeti Lets put a sample URL into the URL field of this bug...
Comment 19•22 years ago
|
||
If I was still "there" (refer to old BA postings as race@netscape.com) I woulda done it. This is ugly. This will generate bad PR. This has been around since the first Moz-based public releases. Someone will exploit this. I'm just sayin. Adding my cheesy attachment. Adding Darin too. I'm just a QA guy. If I knew how to code, I'd be dangerous. -jim
Comment 20•22 years ago
|
||
Comment 21•22 years ago
|
||
D'oh. Sorry. The above attachment will not crash your browser if you open it. You have to click on a link first. I'm being "nice". :)
Comment 22•22 years ago
|
||
Attachment #87773 -
Attachment is obsolete: true
Comment 23•22 years ago
|
||
since our DNS implementation varies from platform to platform, its perhaps no surprise that this crash is only reported under windows. i'll take a look...
Assignee: new-network-bugs → darin
Severity: normal → major
Status: REOPENED → NEW
Priority: -- → P2
Target Milestone: --- → mozilla1.1beta
Comment 24•22 years ago
|
||
CONFIRMED: Chimera 0.3, while I am at it, using the example from bug 151904. +nsbeta1, all/all
Comment 25•22 years ago
|
||
Should we bump up the priority? Reproducible crash, possible exploit....
Reporter | ||
Comment 27•21 years ago
|
||
I am still experiencing this crash on 2002090708 on WinXP. Talkback id: TB10556787Z
Comment 28•21 years ago
|
||
UPDATE: Mozilla 1.1, Mac OS X and Linux. did not reproduce. Received DNS error (cannot be found).
Assignee | ||
Comment 29•21 years ago
|
||
Changing product.
Component: Networking → NSPR
Product: Browser → NSPR
Target Milestone: mozilla1.1beta → ---
Assignee | ||
Comment 30•21 years ago
|
||
Wan-Teh, shouldn't PR_StringToNetAddr() catch this and fail?
Assignee: gordon → wtc
QA Contact: benc → wtc
Comment 31•21 years ago
|
||
Gordon, PR_StringToNetAddr() probably should catch this and fail. I suggest that you work around this in your code. Two possible workarounds: 1. Check the string's length before passing it to PR_StringToNetAddr(). 2. Check the return value of BufAlloc and handle a nsnull return value as you do in nsDNSLookup::ConvertHostEntry(). #2 seems like a good thing to do anyway.
Assignee: wtc → gordon
Component: NSPR → Networking
Product: NSPR → Browser
QA Contact: wtc → benc
Assignee | ||
Comment 32•21 years ago
|
||
Okay, I'll work around it in our code, and write up a separate bug for PR_StringToNetAddr().
Status: NEW → ASSIGNED
Priority: P2 → P1
Reporter | ||
Comment 33•21 years ago
|
||
I can still reproduce this on 20021130 on WinXP upgrading to critical since this is an exploitable crasher.
Severity: major → critical
Comment 34•21 years ago
|
||
+clean-report - this needs to be targeted, unless there is further info needed.
Keywords: clean-report
Comment 35•21 years ago
|
||
re comment 28: When I have my proxy enabled (as usual) this also does not crash, only give the said DNS error. But when I switch to "directly connected to the internet" I get this crash. So maybe proxy settings make the difference. 2003012508 on Win2k.
Comment 36•21 years ago
|
||
Andreas: if I understand the problem correctly, the crash occurs in handling DNS/IP addressing. A proxy configuration does not do this, the URL is directly sent to the proxy.
Comment 38•21 years ago
|
||
Still as reported using Moz 1.4: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Talkback ID: TB22264128M
Comment 39•20 years ago
|
||
*** Bug 216553 has been marked as a duplicate of this bug. ***
Comment 40•20 years ago
|
||
crash loading testcase, TalkbackID of latest Mozilla: TB22857576X with Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5b) Gecko/20030818
Comment 41•20 years ago
|
||
the dns rewrite eliminates the BufAlloc code, which should have the side-effect of fixing this bug.
Depends on: 205726
Updated•20 years ago
|
Summary: URL: long strings -> crash → URL: long strings -> crash [@ MSVCRT.DLL ]
Comment 42•20 years ago
|
||
As Darin said, this bug is gone. Tested with current cvs build on Win2k. Can anybody test on Linux/Mac? (I guess it makes no difference...) So this can be resolved, right?
Comment 43•20 years ago
|
||
WFM Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.7a) Gecko/20040117
Comment 44•20 years ago
|
||
WFM: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 Marking resolved. -jim
Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 20 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 45•20 years ago
|
||
No patch / checkin has been identified for having fixed the bug. ->WORKSFORME
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → WORKSFORME
Comment 46•20 years ago
|
||
Jason:
> the dns rewrite eliminates the BufAlloc code, which should have
> the side-effect of fixing this bug.
This comes close enough, no?
Comment 47•20 years ago
|
||
That was my thought as well... Jason? It's certainly not a WFM resolution.
Updated•20 years ago
|
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Comment 48•20 years ago
|
||
Okay, fair enough. Fixed by "DNS rewrite". But if anybody knows the bug number for that, please reference it here.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
Comment 49•20 years ago
|
||
Yes, I'm an idiot. Fixed by bug 205726.
Comment 50•20 years ago
|
||
Verified, per windows users comments above. has not been a problem in mac or linux since 1.1 (see #28). BTW, fixed w/ a dependency is best way to resolve this!
Status: RESOLVED → VERIFIED
OS: All → Windows XP
Hardware: All → PC
Updated•13 years ago
|
Crash Signature: [@ MSVCRT.DLL ]
You need to log in
before you can comment on or make changes to this bug.
Description
•