742457 - [traceback] OverflowError: long int too large to convert to int

Status: RESOLVED WONTFIX

(Mozilla Reps Graveyard :: reps.mozilla.org, task)

Description

[Stephen Donner [:stephend] Not actively reading bugmail]

I'm punting this to 0.3, but we should probably try to fix ASAP (shouldn't block next release, though).

I got this from using the XSS Me! add-on while logged in to https://reps-dev.allizom.org/u/stephen_donner/r/2012/January/edit/

Traceback (most recent call last):

  File "/data/www/reps-dev.allizom.org/remo/vendor/src/django/django/core/handlers/base.py", line 111, in get_response
    response = callback(request, *callback_args, **callback_kwargs)

  File "/data/www/reps-dev.allizom.org/remo/vendor/src/django/django/views/decorators/cache.py", line 79, in _wrapped_view_func
    response = view_func(request, *args, **kwargs)

  File "/data/www/reps-dev.allizom.org/remo/remo/base/decorators.py", line 54, in wrapper
    return func(request, *args, **kwargs)

  File "/data/www/reps-dev.allizom.org/remo/remo/reports/views.py", line 144, in edit_report
    report_event_formset = forms.ReportEventFormset(data, instance=report)

  File "/data/www/reps-dev.allizom.org/remo/vendor/src/django/django/forms/models.py", line 682, in __init__
    queryset=qs)

  File "/data/www/reps-dev.allizom.org/remo/vendor/src/django/django/forms/models.py", line 415, in __init__
    super(BaseModelFormSet, self).__init__(**defaults)

  File "/data/www/reps-dev.allizom.org/remo/vendor/src/django/django/forms/formsets.py", line 47, in __init__
    self._construct_forms()

  File "/data/www/reps-dev.allizom.org/remo/vendor/src/django/django/forms/formsets.py", line 107, in _construct_forms
    for i in xrange(self.total_form_count()):

OverflowError: long int too large to convert to int

Comment 1

[Giorgos Logiotatidis [:giorgos]]

Hey Stephen,

Why do you think this is an error? As far as I understand 'XSS Me!' posted huge values within the form and django is unable to handle them. Still the resulting error it's not security bug nor functionality bug since if you post something way out of scope you should expect a 500.

Can you please share your thoughts?

Thanks!

Comment 2

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to Giorgos Logiotatidis [:giorgos] from comment #1)
> Hey Stephen,
> 
> Why do you think this is an error? As far as I understand 'XSS Me!' posted
> huge values within the form and django is unable to handle them. Still the
> resulting error it's not security bug nor functionality bug since if you
> post something way out of scope you should expect a 500.
> 
> Can you please share your thoughts?
> 
> Thanks!

Hi Giorgos - while it's not explicitly a security bug, the fact that we're not safeguarding from potentially large error values (and thus, get a traceback) means we're likely doing something wrong with the data.

In general, the application should be robust and handle all kinds of nasty input, and error gracefully.

Jen, can you also shed some insight into why fixing exceptions is typically pretty important?

Comment 3

[Giorgos Logiotatidis [:giorgos]]

Stephen,

I few clarifying questions so I can understand the issue better.

1. You tried a huge number with a XSS Me on DEV server
2. DEV server had DEBUG=False (we switched to that over a month ago. see bug 725417)
3. DEV server returned a page with traceback instead of our 500 page

Is that correct?

Comment 4

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to Giorgos Logiotatidis [:giorgos] from comment #3)
> Stephen,
> 
> I few clarifying questions so I can understand the issue better.
> 
> 1. You tried a huge number with a XSS Me on DEV server
> 2. DEV server had DEBUG=False (we switched to that over a month ago. see bug
> 725417)
> 3. DEV server returned a page with traceback instead of our 500 page
> 
> Is that correct?

Yes, that's correct.

Comment 5

[Giorgos Logiotatidis [:giorgos]]

OK, so the dev server returned a traceback while on production mode. Since this would be a quite serious django vulnerability, probably affecting many more sites than reps, we should cross check that.

Stephen could you please re-produce the issue on dev and / or send me instructions on how reproduce it myself? I already downloaded the XSS Me addon and run all tests on the page, without being able to reproduce that.

Thanks!

Comment 6

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to Giorgos Logiotatidis [:giorgos] from comment #5)
> OK, so the dev server returned a traceback while on production mode. Since
> this would be a quite serious django vulnerability, probably affecting many
> more sites than reps, we should cross check that.
> 
> Stephen could you please re-produce the issue on dev and / or send me
> instructions on how reproduce it myself? I already downloaded the XSS Me
> addon and run all tests on the page, without being able to reproduce that.
> 
> Thanks!

I literally just log in, select a report link,  fire up XSS Me!, and choose "Test all forms with top attacks".

Comment 7

[Giorgos Logiotatidis [:giorgos]]

I still can't reproduce that. Stephen you say that server returned a page (just to clarify a page, *not* an email) with a traceback. Could you please provide a screenshot?

Thanks!

Comment 8

[Stephen Donner [:stephend] Not actively reading bugmail]

Sorry about that, Giorgos; here's a screencast that should help clarify: http://screencast.com/t/nSa8Jz9rb

Comment 9

[Giorgos Logiotatidis [:giorgos]]

Thanks for the informative screencast Stephen. I believe that this is not a security issue. XSS Me feeds a huge number to Django which successfully handles generated exceptions and generates a 500 error page and sends to the admins the traceback.

I'll mark this one as invalid and if Jen or other engineers or security experts suggest that this is a security bug, we should file upstream.

Thanks!

Comment 10

[Andy McKay]

The formset data is being deliberately broken and Django responds by throwing 500 errors. Instead you might just want a nice quiet error.

This was occuring on AMO when QA sent deliberately bad data in, so we wrote this.

https://github.com/andymckay/django-quieter-formset

It might work for you.

Comment 11

[Giorgos Logiotatidis [:giorgos]]

Nice tip Andy! I'll go ahead revisit this one on 0.3.

Thanks!

Comment 12

[Michael Kohler [:mkohler]]

I’m closing this issue as this is quite old now and it’s probably not needed anymore I’m cleaning up all issues to make sure we have a good overview of open bugs.

If you think this should not be closed, please feel free to reopen it.

Thanks!
Michael