Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Sometimes a complete freeze may happen when editing and issuing a request in the repeater

Manuel | Last updated: Aug 25, 2019 04:11PM UTC

I'm not sure what is causing this, but sometimes when editing a request in the repeater and possibly removing the last CRLF characters by keeping pressed the CANC key, after issuing the request all the windows will freeze and CPU usage is fixed at 10/15%. I'm attaching a `jstack -l` dump, i'm not sure how to reproduce it consistently, but usually modifying the ending characters of a request and issuing it will possibly make it hangs. Dump: https://pastebin.com/mCvYqfnv Kali Linux java.runtime.name Java(TM) SE Runtime Environment java.runtime.version 1.8.0_191-b12 java.specification.vendor Oracle Corporation java.version 1.8.0_191 java.vm.info mixed mode java.vm.name Java HotSpot(TM) 64-Bit Server VM java.vm.specification.name Java Virtual Machine Specification java.vm.specification.vendor Oracle Corporation java.vm.specification.version 1.8 java.vm.vendor Oracle Corporation java.vm.version 25.191-b12 jdk.tls.allowUnsafeServerCertChange true jdk.tls.server.protocols TLSv1,TLSv1.1,TLSv1.2 os.arch amd64 os.name Linux os.version 5.2.0-kali2-amd64

Mike, PortSwigger Agent | Last updated: Aug 28, 2019 11:50AM UTC

Hi Manuel, Those characters are needed for HTTP requests as defined in the protocol documentation: https://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html#sec2.2 bq. HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body I have a few questions I would like to ask; 1. Do you need to remove these characters, or is this something that you have noticed while testing? as removing/modifying them would cause issues. 2. Does the application hang indefinitely, or does it eventually come back with a result? 3. Do you have performance feedback enabled (User options > Misc > Performance feedback)? If so, could you provide us with your DebugID and diagnostics (Help > Diagnostics)?

Burp User | Last updated: Aug 28, 2019 05:51PM UTC

Hi Mike, yes sure my explanation was missing that part, but I meant: 1) fiddling with the ending bytes of the request and also removing the final CRLF, for example, sending to the repeater a request with a long body, then selecting all the body bytes there and CANC it away, then manually building the body and ensuring the final CRLF is there. 2) Issuing these requests has higher chances to freeze the whole application and any open window if any, to close it I can only kill -9 on it. 3) Yes, debug id is g7ff9i0clf0dulct6w1z:m6xe Diagnostics: https://pastebin.com/qFtcZz1W

Mike, PortSwigger Agent | Last updated: Aug 30, 2019 07:38AM UTC

Hi Manuel, Thank you for supplying your diagnostic information. Looking through the information that your Burp has passed back to us, I can see some exceptions being passed through that could be related to your issue, can you remember roughly what date & time you were having these issues? Also, can you provide an example of the request you are trying to send in the repeater?

Burp User | Last updated: Aug 30, 2019 02:37PM UTC

I can't remember date and times sorry, but I can do better and provide solid instructions for replication as well as a video that demonstrate the problem. I mapped the Repeater's "Send" request to CTRL+R because I'm much more comfortable when issuing multiple requests fast. I'm not sure this is a feature, but while clicking the "Send" button actually grays it out until a response is received or an event occurs, the shortcut will actually "enqueue" my requests; so i often use this to actually see the response panel refresh multiple times, one after another, in order to spot simple differences in the headers and then stop it and go back to history to actually see the occurrence. The problem lies when multiple requests get enqueued AND you modify the request in between: so, while a request has been issued and the response has yet to arrive, modifying the request at the end of the text and enqueuing it as well via CTRL+R will make the caret disappear from the panel. If you click on the panel around the caret will eventually come back, but if you enqueue just another request this way you'll have the freeze. I've prepared a video PoC for you, can you tell me where to send it?

Burp User | Last updated: Aug 30, 2019 02:42PM UTC

Forgot to mention: as you will notice in the video, the modified request will not persist; in the video the content "abca" is reverted back to "abc" as soon as the first response arrives, then the cursor will disappear.

Mike, PortSwigger Agent | Last updated: Sep 02, 2019 08:08AM UTC

Thank you for the steps to reproduce, I will attempt to reproduce your issue and come back to you with more information. In regards to the video, if you could email it to support@portswigger.net that would be great. Could you also confirm the version of Burp Suite you are using?

Mike, PortSwigger Agent | Last updated: Sep 02, 2019 02:58PM UTC

Hi Colin, this might be due to an invalid request causing the server to be unable to return a valid response. We have validated that the behavior reported by Manuel is a bug due to being able to edit requests while making a request. So I'm not sure if they are related.

Burp User | Last updated: Sep 02, 2019 04:31PM UTC

Hi, i'm using version 2.1.03 Pro: sending in the video now.

Burp User | Last updated: Sep 28, 2019 01:32AM UTC

Hi Mike, I also am experiencing this where in repeater if I by mistake delete something in the request body and it freezes completely on every window and doesn't come back. I think I also clicked the back button in repeater to go back to the previous request but not entirely sure. Here's something from the jre debug.log: [0927/200717.448334:WARNING:x11_util.cc(1422)] X error received: serial 603, error_c ode 170 (GLXBadWindow), request_code 152, minor_code 32 (X_GLXDestroyWindow) [0927/200717.448753:WARNING:x11_util.cc(1422)] X error received: serial 607, error_code 3 (BadWindow (invalid Window parameter)), request_code 4, minor_code 0 (X_DestroyWindow) Not sure if that is useful but I wanted to throw my two cents in and confirm that this bug does exist and this never happened in the past. I only started noticing it recently in the past couple releases.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.