| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
…eTests heuristicCheckDbms() returned False instead of None on failure, breaking the is None convention used elsewhere and producing nonsensical "could be 'False'" log messages. Separately, the kb.reduceTests fallback assignment ignored injection.dbms even though the guarding condition and prompt message both accounted for it, causing kb.reduceTests to become [None] and wrongly skip all DBMS-specific tests when no DBMS was actually identified. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
this whole process doesn't work this way. there is not original issue, there is no "grace period" for ME to actually fix something, and i am here presented with something that i just have to merge because of "fixes". nope |
Sorry, something went wrong.
|
Well actually it is happening in real life, servers can crash and sqlmap thinks databases name is "None" or "False". |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Summary
Two related bugs in lib/controller/checks.py combine to make sqlmap skip legitimate
DBMS-specific test payloads (logged as "...the heuristic tests showed that the back-end DBMS could be 'False'" or '...None'), even though no DBMS was actually determined.
Bug 1 — heuristicCheckDbms() returns False instead of None on failure
heuristicCheckDbms() (lib/controller/checks.py:920) initializes:
and returns this unchanged when no candidate DBMS matches. Every other consumer of
kb.heuristicDbms in the file checks it with is None (e.g. lines 166, 175, 183), not
falsiness. Since False is None evaluates to False, a prior failed heuristic call leaves
kb.heuristicDbms = False, which then:
simultaneously failing the is None guards that gate re-running the heuristic for a
different parameter later in the same scan,
producing the nonsensical could be 'False' log line.
Fix
Change the initial/failure value to None:
This matches the is None convention used by every caller.
Bug 2 — kb.reduceTests fallback ignores which value actually triggered the branch
At lib/controller/checks.py:183-186:
The guarding if can be satisfied by any of three truthy signals:
Backend.getErrorParsedDBMSes(), kb.heuristicDbms, or injection.dbms. The prompt message
(msg = ...) correctly falls back through all three. But the actual assignment on the next line
only falls back through the first two — Backend.getErrorParsedDBMSes() or [kb.heuristicDbms] —
ignoring injection.dbms entirely.
Concretely: when the branch is entered because injection.dbms is truthy while
Backend.getErrorParsedDBMSes() is empty and kb.heuristicDbms is None (a real scenario: a
generic/DBMS-agnostic test confirmed the injection, and the heuristic separately failed), the
assignment becomes:
kb.reduceTests is then a truthy list ([None]), so later at line 323:
every DBMS-specific test gets skipped ("could be 'None'"), even though no DBMS was actually
determined — the opposite of the intended behavior (only skip once a DBMS is known).
Fix
Make the assignment mirror the message's fallback order, deriving from whichever signal actually
satisfied the guard:
After lines 873. it's starting to printing 'False' which is causing detected database name lost and not executing injections on the server. If verbosity level is 1 or 2 it's not visible to user.
Here is my scan output on vulnserver
out.txt
To reproduce I need to make some changes on vulnserver, which is returning "Network Error" random, that make sqlmap to fail. Which happened me before... here is changed file, I didn't want to put in the changes...
vulnserver.py