338736 - hang with sprundels ircfuzzer

Status: RESOLVED INVALID

(Other Applications :: ChatZilla, defect)

Description

[Bernd]

I was eager to get the fuzzer running under winXP and it does hang chatzilla after a few cycles, it seldom takes more than 15.
To test this:
1. start irc.exe from the command line 
2. start firefox
3. open chatzilla
4. /attach 127.0.0.1
5. wait till the console with irc.exe does not change anymore (it should produce every second one line) 


As I am not sure whats going on I file this security sensitive to protect the tool. Remove the security setting if you think thats over eager.

Comment 1

[Bernd]

Attachment: original file

Comment 2

[Bernd]

Attachment: winxp variant

Comment 3

[Bernd]

Attachment: executable

Comment 4

[Samuel Sieb]

Does the program leave a log of what it sends?  Does it hang just chatzilla or the browser as well?

Comment 5

[Samuel Sieb]

This is not a security-sensitive bug.  This program sends a huge line (up to 1KB) of binary data to the irc client every 10ms.  Any "hang" you see is the munger working on the long lines.  I did get the slow script dialog once at the beginning.  Unless anyone has any other comments, I'll mark this invalid in a few days.

Comment 6

[:Gijs (he/him)]

(In reply to comment #5)
> This is not a security-sensitive bug.  This program sends a huge line (up to
> 1KB) of binary data to the irc client every 10ms.  Any "hang" you see is the
> munger working on the long lines.  I did get the slow script dialog once at the
> beginning.  Unless anyone has any other comments, I'll mark this invalid in a
> few days.

Can we, per the spec, truncate lines at 512 chars, and would that speed things up? If we do so, it might be worthwhile...

Comment 7

[Samuel Sieb]

From http://www.faqs.org/rfcs/rfc1459.html
IRC messages are always lines of characters terminated with a CR-LF (Carriage Return - Line Feed) pair, and these messages shall not exceed 512 characters in length, counting all characters including the trailing CR-LF. Thus, there are 510 characters maximum allowed for the command and its parameters.

Comment 8

[Bernd]

>This program sends a huge line (up to
>1KB) of binary data to the irc client every 10ms.

dump_sendbuffer(char* buf)
{
  SYSTEMTIME st;
  Sleep(1000); <==== this waits for 1000ms on every line it sends.

The original code did as you say send the information without any delay, the modified code however pauses just to avoid the impression that the hang is due to heavy load. Usually as I wrote when no new lines are printed one can easily kill irc.exe and chatzilla will keep the machine at 100% load for as long as you want.

When chatzilla hangs as I described why is this bug invalid?

Comment 9

[Bernd]

I would be happy if you lift the security flag, but as the tool did hang for me rather soon so one can not test chatzilla decently. See http://www.donationcoder.com/Software/Mouser/mircryption/index.php for example why I am so cautious.

Comment 10

[Samuel Sieb]

I used the attached "original file" which sends a line every 10ms.  ChatZilla of course used 100% CPU time, but it didn't hang.  After I killed the fuzzer program, ChatZilla ran for quite a while before hitting the end of its input queue.  I'll try again with a reasonable delay so it can run for a while.  Which version of ChatZilla did you try?

The reason this is unlikely to cause a problem is because ChatZilla is written in JavaScript, so the only way we can have a buffer overflow is if there's a bug in the JS interpreter.

Comment 11

[Bernd]

>Which version of ChatZilla did you try?
CVS trunk

OK, if you feel good, lets make it open.

Comment 12

[James Ross]

I can pretty much guarantee that all the time is spent in Gecko (for displaying the crap data) and SpiderMonkey's RegExp engine (trying to parse the crap data).

The random data does not test anything in ChatZilla. Even the pretend commands doesn't really test anything of interest.

Hence, this bug not security sensitive, and INVALID.

Comment 13

[Bernd]

removing flag

Comment 14

[Bernd]

Attachment: stacktrace

yeah the fuzzer has a weakness 

case 0:			// long string 
      end = (rand () % 12000) + 10;
      for (i = 0; i < end; i++)
	{
	  do
	    {
	      buf[i] = rand () % 256;
	    }
	  while (buf[i] == '\n' || buf[i] == '\r' || buf[i] == '\0');
	}
its missing a buf[i]= 0; here 
      break;
which is causing these very long strings.
Once this if fixed it takes a finite amount of time to exit via the shown stack trace.

Comment 15

[:Gijs (he/him)]

So what are you actually saying? You're saying it 'exits' - do you mean crash, or what? If all the hanging is in Gecko, and the stack points at nspr, then why is this bug on file against *us* ? :-)

Crashes (as I think Silver pointed out on this bug already) are never our own fault - you'll want to find a better place for whatever it is you're seeing, and Silver would be right - this bug is now INVALID.