Potential memory leak in reverse_https payload

[FunnyWolf]

Steps to reproduce

1. use msfconsole to start a handler

   
   msf6 > use payload/windows/x64/meterpreter/reverse_https 
   msf6 payload(windows/x64/meterpreter/reverse_https) > set LHoST 192.168.146.130
   LHoST => 192.168.146.130
   msf6 payload(windows/x64/meterpreter/reverse_https) > to_handler 
   [*] Payload Handler Started as Job 0
   msf6 payload(windows/x64/meterpreter/reverse_https) > 
   [*] Started HTTPS reverse handler on https://192.168.146.130:8443

msf6 payload(windows/x64/meterpreter/reverse_https) > show options

Module options (payload/windows/x64/meterpreter/reverse_https):

Name Current Setting Required Description

---

EXITFUNC process yes Exit technique (Accepted: '', seh, thread, process, none) LHOST 192.168.146.130 yes The local listener hostname LPORT 8443 yes The local listener port LURI no The HTTP Path

msf6 payload(windows/x64/meterpreter/reverse_https) >

2. msf memory use at this moment

root@wolf:~# ps -e -o 'pid,comm,args,pcpu,rsz,vsz,stime,user,uid' | grep ruby 25727 ruby ruby ./msfconsole 3.8 500964 1220844 12:34 root 0 25961 grep grep --color=auto ruby 0.0 724 6300 12:40 root 0

3. run a python script to test handler

import requests for i in range(3000): requests.get("https://192.168.146.130:8443/UxuctMFs/123123123123123", verify=False)

4. after finish python script, msf memory use

root@wolf:~# ps -e -o 'pid,comm,args,pcpu,rsz,vsz,stime,user,uid' | grep ruby 25727 ruby ruby ./msfconsole 4.2 563200 1286380 12:34 root 0 26047 grep grep --color=auto ruby 0.0 720 6300 12:43 root 0

5. the memory will not free after wait for 10min

## Expected behavior

Considering that the payload will send heartbeat requests to the handler regularly, the memory information should not grow indefinitely

## Current behavior

Memory usage grow unlimited

### Metasploit version

Framework: 6.1.32-dev
Console  : 6.1.32-dev

[FunnyWolf]

https://github.com/rapid7/metasploit-framework/issues/11576

[adfoster-r7]

Just to confirm - is this a memory leak, or just an inefficient usage of memory? 👀

In computer science, a memory leak is a type of resource leak that occurs when a computer program incorrectly manages memory allocations in a way that memory which is no longer needed is not released

In this scenario it seems like we'd want to keep the resources around for the registered payloads to connect back to msfconsole again in the future

[FunnyWolf]

Probability is a default method of memory used by ruby (hold the malloc memory and do not release it to the Linux kernel), but if you need to use msfconsole for a long time (like one month), the memory will continue to grow until the process is unresponsive,many api in msf have this issue and handler is the eaiest one to show.

[adfoster-r7]

If you use the omnibus installers, we ship with jemalloc to help with memory bloating issues https://github.com/rapid7/metasploit-omnibus/pull/119

If you want to dig into where memory may be leaking, there's rough papertrail for a previous memory leak being fixed over here https://github.com/rapid7/metasploit-framework/pull/13488

In your replication case, I have a feeling it's not a memory leak - but memory being allocated for queues etc as part of handling 3k sessions, which are permanently left around intentionally for when the client reconnects. This would include the TLV packets that are queued up as pat of the 'health check' pings that are sent to meterpreters.

[FunnyWolf]

after analyze reverse_http handler code I also think it is not a memory leak, but a memory release problem of ruby. I always thought that ruby3 + had been compiled using jemalloc by default I will use jemalloc to recompile ruby3 0.2, test whether the problem will reappear. If the problem reappears, I will analyze the code occupied by memory according to the method you provide Thanks for your help

[adfoster-r7]

Thanks! Feel free to raise the issue again if you were able to confirm this as a bug :+1: