[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #9901 [TorBrowserButton]: DoS of TBB 2.4/3.0 when no Content-Type header and more than 512 bytes of content are sent



#9901: DoS of TBB 2.4/3.0 when no Content-Type header and more than 512 bytes of
content are sent
----------------------------------+----------------------------------
     Reporter:  sqrt2             |      Owner:  mikeperry
         Type:  defect            |     Status:  new
     Priority:  normal            |  Milestone:
    Component:  TorBrowserButton  |    Version:
   Resolution:                    |   Keywords:  tbb dos content-type
Actual Points:                    |  Parent ID:
       Points:                    |
----------------------------------+----------------------------------

Comment (by gk):

 Resurrecting some relevant comments from above:
 {{{
 see #9115 for some details about it.
 }}}
 {{{
 Problem is "return null" from external-app-blocker.js
 Removing it solves everything except spamming of error console with
 warning, that is why hack with returning null was needed in first place.

 Proposed new hack solves noise in console by returning string "text/plain"
 that code can accept. Code will use "text/plain" anyway for case like this
 ticket describes. Hopes nothing another will be broken with new hack. Need
 to test.
 }}}
 {{{
 [http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.2.1 RFC 2616]:
 Any HTTP/1.1 message containing an entity-body SHOULD include a Content-
 Type header field defining the media type of that body. If and only if the
 media type is not given by a Content-Type field, the recipient MAY attempt
 to guess the media type via inspection of its content and/or the name
 extension(s) of the URI used to identify the resource. If the media type
 remains unknown, the recipient SHOULD treat it as type "application/octet-
 stream".

 Returning string prevents inspecting of content. And returning
 "text/plain" violates specification.
 Doubly wrong way to fix bug.

 Only choice: Spam or DoS.
 }}}
 {{{
 Firefox 10ESR had not ability to handle null from Torbutton too, no
 recursion and almost no CPU eating, but still blank page in result.
 }}}

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9901#comment:13>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs