0

as the title states I don't understand the relation between permission to access a db and the permission to write/read files on the underlying OS.

In one of my latest CTF's I had to obtain access to a database and then read files of the server containing the flag. I know this is only possible if the compromised user has the file privilege, but my question remains the same.

Sqlmap states in its features it can accomplish this:

Support to download and upload any file from the database server underlying file system when the database software is MySQL, PostgreSQL or Microsoft SQL Server.

Now my specific questions:

  • What is the core feature/problem that allows this OS access?
  • Why are the permission connected?
  • Are other DBMS also vulnerable to this and is it a general problem (meaning sqlmap just doesn't provide the exploit for other dbms yet)?

In my eyes the permissions should be treated differently and the db user should not have permissions on the OS, except the files with relation to the DBMS.

Thanks in advance, I know the question is not limited to one aspect and contains various fundamental topics. I'm also willing to do more research, but maybe there is an answer that facilitates my learning process.

dombg
  • 311
  • 3
  • 18
  • Your question is way too broad. Consider that all DBMS products use the OS to function. Many allow execution of shell commands if configured to do so and the OS security used for shell commands varies by product and the DBMS security context too. – Dan Guzman May 07 '20 at 11:08
  • @DanGuzman I understand where you are going with this, I mentioned this in my question too. But nonetheless I believe there is an relatively easy to follow answer to parts of my questions. Surely not to all of them. – dombg May 08 '20 at 14:41

1 Answers1

1

I am not sure about the others, but the below is true of MySQL and MariaDB.

You would need an additional exploit for local privilege escalation to gain access to any files the database user has no access to. The file path available for access is in the system variable secure_file_priv. Dumping/loading data from any other location will not be possible.

Additionally, executing commands is not possible without a UDF plugin that would allow you to execute arbitrary commands. Such things exist, but are not part of MySQL / MariaDB - it is something the sysadmin/DBA on the DB server would have to install themselves. Without this, you wouldn't be able to get the list of files.

Then there are the OS level protections:

1) POSIX level privileges This is regular user/group file systems permissions.

2) Secondary hardening, e.g. SELinux or AppArmor This will prevent the running process from accessing paths, ports and other resources that don't match the context or path defined in the security policy.

In short, you cannot access/retrieve arbitrary files through the database layer unless the server is deliberately (mis)configured in a way that would allow you to do so, and it would take active effort to configure a MySQL or MariaDB server in a way that would leave it open to this.

Gordan Bobić
  • 1,748
  • 13
  • 16
  • I was not talking about privililege escalation, my question was why does a db user have privileges for files which have nothing to do with the dbms in the first place? Do you include reading/writing files as arbirtrary commands? Or do you mean any OS command? So what you are saying is that the MySQL Server in case of the CTF was misconfigured (not just executed by a user with too many privileges?) – dombg May 08 '20 at 14:31
  • The latter. If you were able to access an arbitrary file from MySQL or MariaDB, that server was either badly and deliberately misconfigured or had an unpatched exploit in it. Even if you were able to gain ability to execute arbitrary commands or open() system calls against arbitrary files as the database user (mysql user), and thus access files outside of the explicitly allowed paths (/var/lib/mysql, /var/lib/mysql-files), SELinux or AppArmor should have prevented you from accessing them if the server was in it's standard, default configuration. – Gordan Bobić May 08 '20 at 14:44
  • I understand. And SELinux (or alternatives) is included and has its standard configuration in various Linux distributions (by default) which would prevent that correct? Then I get the picture you were painting for me ;) Thank you – dombg May 08 '20 at 15:10
  • Yes, that is exactly what I am saying. – Gordan Bobić May 08 '20 at 15:16