Security Issue If You Use SQL Server (May Affect <0.02% Backpack Projects)

This is the first security post we have to write, in the 5 years since we've been running Backpack. We're trying to be as direct and tr...

Cristian Tabacitu

Published on 4 March 2021 in News

Share:

• 
• 

This is the first security post we have to write, in the 5 years since we've been running Backpack. We're trying to be as direct and transparent as possible, so here it is:

Bad news:

• we've recently found out there is an SQL Injection vulnerability inside the Backpack ListOperation, for certain server configurations;

Good news:

• our stats and tests show that 99.9836% of the apps that use Backpack are NOT affected by this issue; furthermore, the only apps affected by this issue are those who use database types that Backpack does not officially support (we only know about SQL Server for sure);
• we've already fixed the problem, and getting the fix is as easy as running a composer update;
• thanks to our usage stats, we have been able to make a list of all live apps that are possibly affected by this, and we've already reached out to each license holder individually to let them know about it;

Cause & Effect

Because Backpack did not properly sanitize the input inside an orderByRaw() statement, our ListOperation technically allowed a malicious actor to run custom SQL statements on the database.

Fortunately, the modern databases that Backpack officially supports (MySQL and PostgreSQL) have protections against this. You can't do nasty stuff in ORDER BY statements, the DB won't let you. Furthermore, NoSQL systems have nothing to do with this, as we never could do orderByRaw() inside those. But we know people use Backpack with unsupported DBMSs, because it works, so it is indeed an issue for some apps. That's why we're taking this seriously.

We will not give steps to reproduce here, but if you are a Backpack contributor or license holder, and want to try it out, please send an email to [email protected] and we'll happily give you easy-to-follow steps.

Who Is Affected?

Your database might be in danger if ALL of the conditions below are true:

• your application gives access to Backpack CRUDs to non-admins (people you don't trust);
• AND your application is running Backpack 4.1.17-4.1.34;
• AND you're using something other than MySQL, PostgreSQL or MongoDB for your database;

Severity

Again, this is only a problem for projects that use Backpack for something other than an admin panel (ex: user-facing datatables). Furthermore, out of those possibly affected projects, where people you do not trust have access to the table view of your CRUDs, you might still be safe, depending on your database system. We're still analysing different DBMSs and versions, but as of this moment, we consider the possibility of database damage to be:

• IMPORTANT for SQL Server;
• Low for SQLite;
• Low for MySQL 5.5+;
• Low for PostgreSQL 10+;
• Non-issue for NoSQLs like MongoDB;

We're estimating on the safe side here. Technically all SQL systems are running the problematic piece of code, but some DBMSs do a better job than others in preventing these types of attacks.

But. Even if you are not affected by this particular issue, we recommended you run a composer update anyway, because:

• Laravel itself has patched a security problem in Jan 2021, and they too recommend running a composer update to get to Laravel 6.20.11+, 7.30.2+, 8.22.1+;
• since version 4.1.17, Backpack has received more than 130 other patches, improvements and bug fixes; all non-breaking, which you’ll be getting in seconds with a composer update;

Summary

The impact is limited. We could only confirm an IMPORTANT vulnerability when Backpack is used:

• outside its intended purpose (for user-panels instead of admin-panels);
• with databases that Backpack does not officially support (SQL Server);

We know this means that very few Backpack installations are actually affected. But just to be on the safe side, we decided to write this post to let as many people know as possible.

Let this be a reminder to all of us that important security issues do come up sometimes, even in well-maintained projects like Laravel and Backpack, and it’s a good idea to keep our projects up-to-date. This is a particularly good time to run composer update, and get the fixes for both Laravel and Backpack, even if you're unaffected by this issue.

What We're Doing About This

We've taken this seriously:

• we've plugged the security hole in Backpack 4.1.35;
• we've tested and are still testing different DBMSs and versions, to see which ones are possibly affected;
• we've made a list of all Backpack license holders who have apps that might be affected, and have reached out to each one individually;
• we've created this post, for full transparency, and have published it a week after the fix, to give affected projects enough time to update;
• we have decided NOT to email everybody in our Security Newsletter; since we've already contacted individually everybody who's possibly affected, emailing 20k+ people who are not affected would just be... spam;

Conclusion

Needless to say… we are very sorry for this incident. It is the first time we’ve ever had a security issue we consider Important (even for a small subset of our customers), in the 5 years since we started Backpack. Of course, that doesn’t make it ok, but we hope that it shows that we take security seriously, we're transparent about it, and we try to protect our customers' projects as much as we can. In this particular case - we failed to do that for a small number of our customers, and we are sorry for that. We absolutely promise to pay even more attention from now on.

To reiterate & rephrase - if you have a project in production that you last updated between July 2020 and Feb 2021, and you do NOT trust the users of your Backpack table views, you should run a composer update on the project. But even if you don’t care about this security issue, you should probably run a composer update anyway, just to get the latest secure Laravel version.

Again, we’re deeply sorry for the trouble we might have caused. I hope our quick and decisive reaction to this shows how much we care, and how much we’re invested in keeping your projects secure - even if you’re using Backpack in a way that we do not officially support.

Tip: You can find out your project’s Backpack, Laravel and database version by running php artisan backpack:version in the command line.