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

Status: VERIFIED FIXED

(Core :: Networking, defect, P1)

Description

[Chris Lyon]

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 1

[Chris Lyon]

Adding crash keyword.

Comment 2

[Vadim Berezniker]

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

Comment 3

[rossi]

WFM trunk win32 (xp) 2002041203 - so same build, same os...

Comment 4

[Chris Lyon]

Attachment: Testcase html file with long http link

Comment 5

[Antonio.Xu]

I will research this bug.

Comment 6

[Antonio.Xu]

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

Comment 7

[benc]

+cc: more URL help...

Comment 8

[Andreas Otte]

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

[Antonio.Xu]

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

Comment 10

[Gagan]

WFM

Comment 11

[Chris Lyon]

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?

Comment 12

[Antonio.Xu]

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.

Comment 13

[Chris Lyon]

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

[Paul Figura]

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

Comment 15

[Jim Race]

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

Comment 16

[Jim Race]

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

[Jim Race]

Noting that it crashes with the latest nightlies on win32.

Comment 18

[benc]

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

Comment 19

[Jim Race]

If I was still "there" (refer to old BA postings as [e-mail]) 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

[Jim Race]

Attachment: win32 moz killer

Comment 21

[Jim Race]

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

[Jim Race]

Attachment: Second shot. Bugzilla te the first one. win32 Moz Killer

Comment 23

[Darin Fisher]

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...

Comment 24

[benc]

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

Comment 25

[Jim Race]

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

Comment 26

[Darin Fisher]

-> DNS (gordon)

Comment 27

[Chris Lyon]

I am still experiencing this crash on 2002090708 on WinXP.

Talkback id: TB10556787Z

Comment 28

[benc]

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

Comment 29

[gordon]

Changing product.

Comment 30

[gordon]

Wan-Teh, shouldn't PR_StringToNetAddr() catch this and fail?

Comment 31

[Wan-Teh Chang]

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.

Comment 32

[gordon]

Okay, I'll work around it in our code, and write up a separate bug for
PR_StringToNetAddr().

Comment 33

[Chris Lyon]

I can still reproduce this on 20021130 on WinXP

upgrading to critical since this is an exploitable crasher.

Comment 34

[benc]

+clean-report - this needs to be targeted, unless there is further info needed.

Comment 35

[Andreas Kunz]

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

[benc]

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

[Samir Gehani]

adt: nsbeta1-

Comment 38

[Jim Race]

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

[Adam Hauner]

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

Comment 40

[Hermann Schwab]

crash loading testcase, TalkbackID of latest Mozilla:
TB22857576X with Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5b) Gecko/20030818

Comment 41

[Darin Fisher]

the dns rewrite eliminates the BufAlloc code, which should have the side-effect
of fixing this bug.

Comment 42

[Andreas Kunz]

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

[Sven Krohlas]

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

Comment 44

[Jim Race]

WFM: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113

Marking resolved.

-jim

Comment 45

[Jason Bassford]

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

->WORKSFORME

Comment 46

[Andreas Kunz]

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

[Jim Race]

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

Comment 48

[Jason Bassford]

Okay, fair enough.  Fixed by "DNS rewrite".  But if anybody knows the bug number
for that, please reference it here.

Comment 49

[Jason Bassford]

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

Comment 50

[benc]

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!