URL: long strings -> crash [@ MSVCRT.DLL ]

VERIFIED FIXED

Status

()

defect
P1
critical
VERIFIED FIXED
17 years ago
15 years ago

People

(Reporter: cplyon, Assigned: gordon)

Tracking

({crash})

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

17 years ago
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
(Reporter)

Comment 1

17 years ago
Adding crash keyword.
Keywords: crash

Comment 2

17 years ago
can't reproduce this in 0.9.9 or trunk 2002041218 on linux

Comment 3

17 years ago
WFM trunk win32 (xp) 2002041203 - so same build, same os...
(Reporter)

Comment 4

17 years ago

Comment 5

17 years ago
I will research this bug.

Comment 6

17 years ago
i test the long url of attachment,mozilla didn't crash,but it will hang on.

Comment 7

17 years ago
+cc: more URL help...
Summary: Extremely long URLs crash Mozilla → URL: long strings -> crash

Comment 8

17 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

17 years ago
I think this bug should be closed,because browser didn't crash.

Comment 10

17 years ago
WFM
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 11

17 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

17 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

17 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

17 years ago
Crashed for me, WIN98SE, Talkback ID: TB5657688X. Using Mozilla 1.0RC1 Build:
2002041711.

Comment 15

17 years ago
*** Bug 151904 has been marked as a duplicate of this bug. ***

Comment 16

17 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

17 years ago
Noting that it crashes with the latest nightlies on win32.

Comment 18

17 years ago
+neeti
Lets put a sample URL into the URL field of this bug...

Comment 19

17 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

17 years ago
Posted image win32 moz killer (obsolete) —

Comment 21

17 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

17 years ago
Attachment #87773 - Attachment is obsolete: true

Comment 23

17 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

17 years ago
CONFIRMED: Chimera 0.3, while I am at it, using the example from bug 151904.
+nsbeta1, all/all

Keywords: nsbeta1
OS: Windows XP → All
Hardware: PC → All

Comment 25

17 years ago
Should we bump up the priority? Reproducible crash, possible exploit....

Comment 26

17 years ago
-> DNS (gordon)
Assignee: darin → gordon
(Reporter)

Comment 27

17 years ago
I am still experiencing this crash on 2002090708 on WinXP.

Talkback id: TB10556787Z

Comment 28

17 years ago
UPDATE: Mozilla 1.1, Mac OS X and Linux. did not reproduce.
Received DNS error (cannot be found).
(Assignee)

Comment 29

17 years ago
Changing product.
Component: Networking → NSPR
Product: Browser → NSPR
Target Milestone: mozilla1.1beta → ---
(Assignee)

Comment 30

17 years ago
Wan-Teh, shouldn't PR_StringToNetAddr() catch this and fail?
Assignee: gordon → wtc
QA Contact: benc → wtc

Comment 31

17 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

17 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

17 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

17 years ago
+clean-report - this needs to be targeted, unless there is further info needed.
Keywords: clean-report

Comment 35

17 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

17 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 37

16 years ago
adt: nsbeta1-
Keywords: nsbeta1nsbeta1-

Comment 38

16 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

16 years ago
*** Bug 216553 has been marked as a duplicate of this bug. ***

Comment 40

16 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

16 years ago
the dns rewrite eliminates the BufAlloc code, which should have the side-effect
of fixing this bug.
Depends on: 205726

Updated

16 years ago
Summary: URL: long strings -> crash → URL: long strings -> crash [@ MSVCRT.DLL ]

Comment 42

16 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

16 years ago
WFM Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.7a) Gecko/20040117

Comment 44

16 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
Last Resolved: 17 years ago16 years ago
Resolution: --- → FIXED

Updated

16 years ago
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 45

16 years ago
No patch / checkin has been identified for having fixed the bug.

->WORKSFORME
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → WORKSFORME

Comment 46

16 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

16 years ago
That was my thought as well... Jason? It's certainly not a WFM resolution.

Updated

16 years ago
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Comment 48

16 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
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED

Comment 49

16 years ago
Yes, I'm an idiot.  Fixed by bug 205726.

Comment 50

15 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
Crash Signature: [@ MSVCRT.DLL ]
You need to log in before you can comment on or make changes to this bug.