<div>Hi,<br></div><div><div><br></div></div><div><span style="background-color:transparent"><span style="color:rgb(0, 0, 0)"><span style="font-family:Arial"><span style="font-size:11pt">Thank
 you for the quick answer. There is only one thing which confuses us, as
 how the vulnerability marked with CVE 2020-26935 has any danger to the
system? All "dangerous" characters used for SQL injections get escaped.
It is possible to send a union or a sleep command in the query but the
union command is limited by the user privileges and sleep only makes
everything on the attackers side slower. You can also try to send a
second sql command in the where_clause but through dbi it only takes the
 first sql command and ignores the rest. So far as we see it, there
isn't a realistic danger to the system. So why excatly did you create a
cve for that, which has a relatively high score? </span></span></span></span><br></div><div><div><br></div></div><div>Regards<br></div><div>MKrebs & JHiller<br></div><div>Students @ HAW Hof<br></div><div><br></div><div>‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐<br></div><div> Am Freitag, 18. Dezember 2020 00:01 schrieb Isaac Bennetch <bennetch@gmail.com>:<br></div><div> <br></div><blockquote class="protonmail_quote" type="cite"><div dir="ltr"><div>Hi,<br></div><div><br></div><div>The attack vector is someone intercepting the search parameter and injecting some arbitrary SQL command there. If I recall correctly, the where_clause is not presented in the graphical interface at all and is simply present in the POST variables. It's used to build the query, but isn't going to be modified by the user, and prior to the fix we were just recalling the statement from the POST data without confirming that the user had not modified it. The fix verifies the signature of the returned portion of the query to make sure the user (or some attacker) has not injected their own statement in to the where_clause.<br></div><div><br></div><div>If you believe the code is still vulnerable, you're welcome to write back here or send an email to <a href="mailto:security@phpmyadmin.net">security@phpmyadmin.net</a>. Of course, if I have left off some detail, I'm happy to answer further questions as well as I can.<br></div><div><br></div><div>Cheers,<br></div><div>Isaac from the phpMyAdmin project<br></div></div><div><br></div><div class="gmail_quote"><div dir="ltr">On Thu, Dec 17, 2020 at 8:45 AM studentProject via Developers <<a href="mailto:developers@phpmyadmin.net">developers@phpmyadmin.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Hello,<br></div><div><br></div><div>we are two students from the university of applied sciences Hof in Germany and for a module about IT-security we are researching the vulnerability marked with CVE 2020-26935, which describes a possible SQLi attack via SearchController.<br></div><div><br></div><div>The issue has already been documented by phpmyadmin:<br></div><div><a href="https://www.phpmyadmin.net/security/PMASA-2020-6/" target="_blank">https://www.phpmyadmin.net/security/PMASA-2020-6/</a><br></div><div><br></div><div>And the responsible fix has also been linked as a git commit in the link above:<br></div><div><a href="https://github.com/phpmyadmin/phpmyadmin/commit/d09ab9bc9d634ad08b866d42bb8c4109869d38d2" target="_blank">https://github.com/phpmyadmin/phpmyadmin/commit/d09ab9bc9d634ad08b866d42bb8c4109869d38d2</a><br></div><div><br></div><div>We are writing because we do not fully understand in which way the commit in question fixes any possible SQLi attacks mentioned in the CVE. As far as our research goes, we have figured out that the where_clause gets signed with an HMAC signature, which doesn't necessarily provide security against said attacks.<br></div><div><br></div><div>Would you mind elaborating how the commit mentioned in the issue linked above fixes the CVE (2020-26935) in question? We are clueless considering the given commit doesn't seem to clear up the question for us. Is the commit linked in the PMASA-2020-6 note perhaps wrong? Does the fix lie in another method/class or even in the frontend instead?<br></div><div><br></div><div>Regards<br></div><div>MKrebs & JHiller<br></div><div>Students @ HAW Hof<br></div><div>_______________________________________________<br></div><div> Developers mailing list<br></div><div> <a href="mailto:Developers@phpmyadmin.net" target="_blank">Developers@phpmyadmin.net</a><br></div><div> <a href="https://lists.phpmyadmin.net/mailman/listinfo/developers" rel="noreferrer" target="_blank">https://lists.phpmyadmin.net/mailman/listinfo/developers</a><br></div></blockquote></div></blockquote><div><br></div>