Insufficient validation of ticket comment parameters

[mrenzmann@…]

I've stumbled over an issue in Trac 0.10.3.1 that is - as far as I can tell without digging through the source - caused by not properly validating the parameters passed when a ticket comment is posted. This issue has been "exploited" by a spammer who tried to post his spamvertizement to the replyto parameter of the corresponding form. Actually this is how I noticed that issue.

Obviously Trac expects that value to contain an integer value, but it does not validate the actual content of that parameter before storing the comment to the database. When one later tries to view a ticket that has received such a POST, the following Traceback occurs:

Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 387, in dispatch_request
    dispatcher.dispatch(req)
  File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 237, in dispatch
    resp = chosen_handler.process_request(req)
  File "/usr/lib/python2.4/site-packages/trac/ticket/web_ui.py", line 303, in process_request
    get_reporter_id(req, 'author'))
  File "/usr/lib/python2.4/site-packages/trac/ticket/web_ui.py", line 620, in _insert_ticket_data
    for change in self.grouped_changelog_entries(ticket, db):
  File "/usr/lib/python2.4/site-packages/trac/ticket/web_ui.py", line 695, in grouped_changelog_entries
    current['cnum'] = int(this_num)
ValueError: invalid literal for int(): <spamvertizement goes here> 

In the last line, the Traceback really shows part of the spamvertizement containing URLs - I removed that for obvious reasons, but check the attached screenshot.

I've been able to "catch" the corresponding POST request in a mod-security audit log. I'll try to attach the relevant part of that log to this ticket, too, I just hope that the spamfilter doesn't prevent that ;)

As this issue is already exploited (although I think this happens "accidentally" because of wrong assumtions in the used spam submission software) I strongly vote for a fix of this bug before 0.10.4 gets released. Thus I set the priority to "high".

[mrenzmann@…]

Attaching the screenshot failed due to the reasons detailed in ticket #4087. It's available for download: ​http://otaku42.de/download/trac-traceback.png

[mrenzmann@…]

mod-security audit log excerpt of POST request that "exploits" the issue that is described in this ticket

[Christian Boos]

Fixed by r5215 on trunk.

[Christian Boos]

And by r5216 for 0.10-stable. Can you please double check the fix?

[mrenzmann@…]

The patch seems to work. In my experiments I posted stuff like "thisisnonumber" to the replyto variable. There was no error raised as I would have expected after looking at the patch (but this could simply be because my limited Python knowledge), but the Traceback also didn't occur.

From what I can tell the patch fixes this issue, so this ticket could be closed. Thanks for your support.

[Christian Boos]

The replyto is not a number, only cnum. replyto is either a number or "description".

Now that I think about it, there's probably a way to exploit this as well. I'll follow-up with a second fix.

[Christian Boos]

OK, now with [5224] and [5225], I think we're really safe (for that issue).

Thanks again for the report!