December 2020 - Developers - lists.phpmyadmin.net

Re: [phpMyAdmin Developers] Question regarding fix of CVE 2020-26935 - SQL Injection via SearchController
by studentProject 26 Dec '20

26 Dec '20

Hi, 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? Regards MKrebs & JHiller Students @ HAW Hof ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ Am Freitag, 18. Dezember 2020 00:01 schrieb Isaac Bennetch <bennetch(a)gmail.com>: > Hi, > > 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. > > If you believe the code is still vulnerable, you're welcome to write back here or send an email to security(a)phpmyadmin.net. Of course, if I have left off some detail, I'm happy to answer further questions as well as I can. > > Cheers, > Isaac from the phpMyAdmin project > > On Thu, Dec 17, 2020 at 8:45 AM studentProject via Developers <developers(a)phpmyadmin.net> wrote: > >> Hello, >> >> 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. >> >> The issue has already been documented by phpmyadmin: >> https://www.phpmyadmin.net/security/PMASA-2020-6/ >> >> And the responsible fix has also been linked as a git commit in the link above: >> https://github.com/phpmyadmin/phpmyadmin/commit/d09ab9bc9d634ad08b866d42bb8… >> >> 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. >> >> 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? >> >> Regards >> MKrebs & JHiller >> Students @ HAW Hof >> _______________________________________________ >> Developers mailing list >> Developers(a)phpmyadmin.net >> https://lists.phpmyadmin.net/mailman/listinfo/developers

1 0

phpMyAdmin 5.1.0-rc1 is released
by Isaac Bennetch 18 Dec '20

18 Dec '20

Hi, We at the phpMyAdmin project are delighted to offer a release candidate for the upcoming version 5.1.0. This release, phpMyAdmin 5.1.0-rc1, is meant as a testing release before the official release of 5.1.0, and is expected to be the only release candidate before the full release. There are many new features and bug fixes; a few highlights include: * Improve virtuality dropdown for MariaDB > 10.1 * Added an option to perform ALTER ONLINE (ALGORITHM=INPLACE) when editing a table structure * Added ip2long transformation * Improvements to linking to MySQL and MariaDB documentation * Add "Preview SQL" option on Index dialog box when creating a new table * Add a new vendor constant "CACHE_DIR" that defaults to "libraries/cache/" and store routing cache into this folder * Add $cfg['CaptchaSiteVerifyURL'] for Google ReCaptcha siteVerifyUrl * Add the password_hash PHP function as an option when inserting data * Improvements to editing and displaying columns of the JSON data type. * Added support for "SameSite=Strict" on cookies using configuration "$cfg['CookieSameSite']" * Fixed AWS RDS IAM authentication doesn't work because pma_password is truncated * Add config parameters to support third-party ReCaptcha v2 compatible APIs like hCaptcha * Add $cfg['MysqlSslWarningSafeHosts'] to set the red text black when ssl is not used on a private network * Export blobs as hex on JSON export * Fix leading space not shown in a CHAR column when browsing a table * Added a rename Button to use RENAME INDEX syntax of MySQL 5.7 (and MariaDB >= 10.5.2) * Fixed missing option to enter TABLE specific permissions when the database name contains an "_" (underscore) * Fixed a PHP notice "Trying to access array offset on value of type null" on Designer PDF export * Fix for several PHP 8 warnings or errors, giving this release full compatibility with PHP 8 There are, of course, many more fixes you can see in the ChangeLog file included with this release or online at https://demo.phpmyadmin.net/master-config/index.php?route=/changelog Downloads are available now at https://phpmyadmin.net/downloads/ Isaac for the phpMyAdmin team

1 0

Cache warmup fails if composer is run with --no-dev
by Isaac Bennetch 18 Dec '20

18 Dec '20

I'm trying to fix the build script so I can release phpMyAdmin 5.1.0, but I've hit a strange issue with Composer and the cache warmup. I've manually defined all the "dev" packages as required, so that whether I run "composer update" or "composer update --no-dev" there are no changes to the installed packages. # composer update --no-dev # ./scripts/console cache:warmup --routing PHP Fatal error: Uncaught Error: Class 'PhpMyAdmin\Tests\Stubs\DbiDummy' not found in /var/www/pma-dev/fork/release/phpMyAdmin-5.1.0-rc1/scripts/console:41 Stack trace: #0 {main} thrown in /var/www/pma-dev/fork/release/phpMyAdmin-5.1.0-rc1/scripts/console on line 41 But # composer update # ./scripts/console cache:warmup --routing runs correctly... Any thoughts about this? I'd like to build the release without requiring all of the dev packages, but if I can't warm up the cache as part of the build, on first run phpMyAdmin throws an error message because ./cache/ isn't writable by the webserver process. Any thoughts about this?

1 0

Question regarding fix of CVE 2020-26935 - SQL Injection via SearchController
by studentProject 17 Dec '20

17 Dec '20

Hello, 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. The issue has already been documented by phpmyadmin: https://www.phpmyadmin.net/security/PMASA-2020-6/ And the responsible fix has also been linked as a git commit in the link above: https://github.com/phpmyadmin/phpmyadmin/commit/d09ab9bc9d634ad08b866d42bb8… 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. 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? Regards MKrebs & JHiller Students @ HAW Hof

1 0