Closed mastercho closed 2 months ago
I found this problem, too!。During routine scan, I found that the memory was suddenly high, occupying more than 10 G, and then OOM appeared.After testing, it was found that this happens when -t javascript/enumeration/pgsql
is specified.
The reproduction process is as follows:
nuclei -u x.x.x.x:22 -t javascript/enumeration/pgsql
But oddly enough, this did not happen when I tested each template file in the pgsql directory in turn
@mastercho @zlgxzswjy This should be fixed in https://github.com/projectdiscovery/nuclei/pull/5291 - Could you confirm if with that branch the issue is still reproducible? Thanks!
@Mzack9999 just tested, and still spikes pretty high all resources CPU and RAM at 80-90% but not to 100% as before to cause it crash, but this is list with 69 subdomains. If they are more pretty sure will crash, if they are less i think will be fine.
After short test on this PR we notice now is crashing even on mysql javascript module, we reverting changes until fixed...
@mastercho I am unable to reproduce the crash you are mentioning. Can you provide more context like the specifics of the machine you are testing on, CLI flags and targets?
I've just tested a full run of postgres modules on a class c network (254 hosts) of which 60 exposes a postgres instances, 10 having SSH exposed on postgres port (the cause of this memory leak, as the module kept reading on an internal buffer) and the other unresponsive. The memory peak I got was max 1Gb.
Feel free to reach out to mzack9999 on discord in case of sensitive info.
@zlgxzswjy hows in your end?
@mastercho I am unable to reproduce the crash you are mentioning. Can you provide more context like the specifics of the machine you are testing on, CLI flags and targets?
I've just tested a full run of postgres modules on a class c network (254 hosts) of which 60 exposes a postgres instances, 10 having SSH exposed on postgres port (the cause of this memory leak, as the module kept reading on an internal buffer) and the other unresponsive. The memory peak I got was max 1Gb.
Feel free to reach out to mzack9999 on discord in case of sensitive info.
Yes, especially when scanning port 22 with these boards, there will be large-scale OOM, consuming tens of GB.
@zlgxzswjy hows in your end?
From my verification results, it seems that the problem has been fixed.There were also no problems scanning mysql Repeat steps:
go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@bugfix-5254-psql-mem cd ~/go/bin && ./nuclei -u X.X.X.X:22 -t /root/.local/nuclei-templates/javascript/enumeration/pgsql No more tens of gigabytes of memory, no more OOM
Ok will run few tests on my side and will come back
i tried old list which is 64 subdomains and was causing crash before PR, did spikes memory to 80-90% as i said before but doesn't crash but if i went for double bigger list with 140 subdomains/ips its still spikes 100% and cause crash! just like in screenshot
This can't be considered as fix as nuclei must be able to scan bigger lists... Also dont ask me for Discord because your CEO said Discord is considered for PD offline chat and nothing must be discussed there and everything must be here...
I did build it from PR instead installing with go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@bugfix-5254-psql-mem
And now i have no issues with it tried on 3 different instances with 10GB ram each, so go install
seems didn't update files every time, PR can be merged and issue closed
Nuclei version: 3.2.8
Current Behavior:
Nuclei gets killed if you scan postgres ips on list longer than 50 in high severity
Expected Behavior:
To not crash and finish scan
Steps To Reproduce:
Site list was provided to @tarunKoyalwar for reproducing
Anything else:
Every details was send to @tarunKoyalwar discord and he is acknowledged about the issue