View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0007574 | Kali Linux | [All Projects] General Bug | public | 2022-02-09 16:30 | 2022-02-24 08:48 |
Reporter | Lumikor | Assigned To | arnaudr | ||
Priority | normal | Severity | tweak | Reproducibility | always |
Status | resolved | Resolution | unable to reproduce | ||
Product Version | 2021.4 | ||||
Target Version | Fixed in Version | ||||
Summary | 0007574: *** buffer overflow detected ***: terminated | ||||
Description | error occurs after increasing open file limit to 50000 (the default 1024 gave me too many open files error) and running a SQLMap script. | ||||
Steps To Reproduce | dump a database using SQLMap (time based to blind) , receive too many open files error, change open file limit to 50000 using ulimit -n, run SQLMap script again. | ||||
Additional Information | This error does not occur in Ubuntu 21.10 with default settings (SQLMap is 1.5.9 though), I believe the error is somewhere in Kali settings. It happens in both zsh and bash shells with history size set to 256 lines | ||||
|
Screen Shot 2022-02-04 at 16.34.31.png (1,677,884 bytes) |
|
Sqlmap in Kali is in version 1.6, so this issue might be caused by the latest update, and that's why it doesn't happen in Ubuntu (with version 1.5.9) This bug must be filled against the sqlmap project, as we in Kali only provide the package and is actually built by Debian. |
|
Unfortunately in sqlmap they blame Kali Linux for this bug...I already reported the issue, they sent me here. |
|
That's weird, because we don't package sqlmap. We use the package from Debian, as I mentioned. I'll check if there's anything that could be causing it, but it doesn't make much sense to me. Thanks for reopening it then ;) |
|
Sharing the link to the github issue for sqlmap https://github.com/sqlmapproject/sqlmap/issues/4972 |
|
In the github issue it is said: « this doesn't look like a sqlmap issue, but related to torsocks ». So... did you try without torsocks? |
|
Tried with and without torsocks. And unfortunately again, I managed to replicate the issue again with kali 5.16.0 22-02-10 and sqlmap 1.6.2#stable |
|
Hi, I just started a Kali rolling VM, and I launched the command provided in the GitHub issue, minus torsocks:$ sqlmap -u "http://testphp.vulnweb.com/artists.php?artist=1" --batch --technique=B --threads=10 --dump -D acuart -T artists Works for me, no error. If you can provide another command that allow me to reproduce the issue, I can try. |
|
same command but without the --batch and it occurs randomly, sometimes it takes an hour sometimes 3 hours. However, I do have some better news. Running my command in Kali SQLMap 1.6.2 I still get "too may open files" error, setting ulimit -n to 102400 (seems like a magic number) did not cause the buffer overflow error. I'm not sure if you can consider it fixed or a workaround. |
|
For the record: I tried again with --batch option, and it works fine. Takes around 30 minutes to run. Also, to clarify: so far I've never seen any "too may open files" error message, and I never had to touch ulimit. This is with sqlmap 1.6.2-1 from Kali Rolling. |
|
Then I have no idea what's going on, I'm running Kali without any change in settings. now with the new ulimit everything works fine...without it I get too many open files, any other ulimit will give me buffer overflow. |
|
I also tried to run sqlmap as root and as non-root, just to be sure. Still no issue on my side. So I'm closing this ticket as I can't reproduce the issue, and it seems that it's more or less solved for you as well. |
Date Modified | Username | Field | Change |
---|---|---|---|
2022-02-09 16:30 | Lumikor | New Issue | |
2022-02-09 16:30 | Lumikor | File Added: Screen Shot 2022-02-04 at 16.34.31.png | |
2022-02-09 16:30 | Lumikor | File Added: Screen Shot 2022-02-09 at 18.26.23.png | |
2022-02-21 17:25 | daniruiz | Note Added: 0015782 | |
2022-02-21 17:25 | daniruiz | Assigned To | => daniruiz |
2022-02-21 17:25 | daniruiz | Status | new => closed |
2022-02-21 17:25 | daniruiz | Resolution | open => no change required |
2022-02-21 17:32 | Lumikor | Status | closed => feedback |
2022-02-21 17:32 | Lumikor | Resolution | no change required => reopened |
2022-02-21 17:32 | Lumikor | Note Added: 0015784 | |
2022-02-21 17:34 | daniruiz | Note Added: 0015785 | |
2022-02-21 17:41 | daniruiz | Note Added: 0015786 | |
2022-02-22 08:21 | arnaudr | Note Added: 0015792 | |
2022-02-22 10:51 | Lumikor | Note Added: 0015797 | |
2022-02-22 10:51 | Lumikor | Status | feedback => assigned |
2022-02-23 07:07 | arnaudr | Note Added: 0015802 | |
2022-02-23 11:00 | Lumikor | Note Added: 0015803 | |
2022-02-24 06:58 | arnaudr | Note Added: 0015808 | |
2022-02-24 07:00 | Lumikor | Note Added: 0015809 | |
2022-02-24 08:46 | arnaudr | Note Added: 0015810 | |
2022-02-24 08:47 | arnaudr | Assigned To | daniruiz => arnaudr |
2022-02-24 08:48 | arnaudr | Status | assigned => resolved |
2022-02-24 08:48 | arnaudr | Resolution | reopened => unable to reproduce |