MySQL client allows MySQL server to request any local file
gwillem.gitlab.io
gwillem.gitlab.io
This has been an issue with MySQL client drivers for years. I found and fixed the same issue in MariaDB Connector/J (JDBC driver (wire compatible with MySQL databases) in 2015. It rejects LOCAL DATA requests from the server unless the client app preregistered an InputStream (Java interface for generic stream of bytes) as data for the command being executing.
This is one of the many many reasons I love open source database drivers. I was able to find and fix this issue only because I could see the source code. Similar "features" in proprietary databases could go unnoticed for years and even when discovered may not have feature flags to disable them.
IIRC, there was a flaw in Flash patched in this manner; it was using memcpy(), which requires the source and destination regions to not overlap, but, they did. In this case, it's fairly simple: one just needs to call memmove(), which conveniently takes the same args in the same order.
(IIRC, there was a lot of consternation getting Adobe to fix that properly, given how obvious the bug was.)
For me it is an example of bad protocol design in the first place.
However, with proprietary software the protocol is unknown unless it has been published. With OSS, you at least have the source code of the implementation.
As you should know, proprietary software relies on the owners to fix the problem. With OSS, "anyone" can provide a fix - and even if the owner does not wish to include the fix in the official build (which would look very bad on them, in this instance), "anyone" can apply it to their own copy.
Meaning, it's vastly easier for a 3rd party to discover and fix OSS, than proprietary software.
1) IIS is proprietary server, but speaks open HTTP protocol. Proprietary software may implement well known protocol. This is probably most of the cases. 2) SQL Server is proprietary software, but speaks documented protocol - TDS. Specification is published. 3) Oracle Database is proprietary software and speaks undocumented TNS protocol.
Protocol is just a specification. If design meant to be secure it is way better.
There are proprietary HTTP clients, but no HTTP server can request file from client. So HTTP protocol is better than MySql protocol. If someone will write custom open source MySql client it will probably be affected. So this is bad design. If someone will write custom open source HTTP client it will not be affected. So this is good design.
Open source does not overweight bad design. I see no sense in "open source v. bad design". Bad design is bad design, no matter what the license is. There is nothing good is keeping bad software alive just because it's open source. The fact that you can play with code and fix security bug is very nice at most. The fact that protocol was misdesigned is paramount.
No one has said nor implied that OSS had any effect on the protocol.
The assertion was, the patcher was thankful it was open source. If it were not, (s)he would not have been able to fix it.
Unless I'm missing some kind of use case this seems like a bad protocol design.
COPY with a file name instructs the PostgreSQL server to directly read from or
write to a file. The file must be accessible by the PostgreSQL user (the user
ID the server runs as) and the name must be specified from the viewpoint of the
server.
PostgreSQL COPY can read or write to server files, though it requires superuser permissions.
There is also COPY FROM/TO STDIN/STDOUT, which allows the client to send the files on the same connection.
> The file name must be given as a literal string.
(From https://dev.mysql.com/doc/refman/8.0/en/load-data.html )
However, you raise an interesting point about parsing. It is reasonable to want the server to do the parsing. You could, for example, tweak the grammar to add a new feature and do it entirely in an server update without needing to deploy a new client binary to every user. But then that makes it a bit harder to fix bugs like this.
There are surely some commands parsed and implemented by the client, though. Like connect, quit, and source for example. So another way to have designed this would be to make a local command to designate a file that the server will be allowed to access. You could define the path name on the client side and pass a symbolic reference to the server. Then the client could parse that command without taking on the burden of parsing SQL, and the client could still own opening files rather than taking orders from the server.
But sounds great for a honeypot. Put up an easy-to-hack WordPress server, and when attacker connects to mysql, start downloading all the PII files you can think of from the client.
No, just because I don't expect my client to kill me, does not mean that therefore there is no reason to be concerned about a rogue employee of theirs being able to gain access to any other of my clients' servers that I have access to by patching an exploit into their MySQL server.
Nor is it reasonable to assume that everyone is on top of their IT security and their infrastructure is only under their own control, and that includes your own organization once it grows beyond one or two people.
If that is the kind of mental model you are working with, your IT security probably is shit. Even the slightest external vulnerability anywhere in your systems or the systems of people whose systems you access/(co-)manage is going to grant an attacker total control over your organization if that is how you manage security.
Pledge is meant to be used for stopping your software from doing unanticipated things, not anticipated things. In this case they anticipated this behavior and purposely kept it even though it's potentially dangerous.
EDIT: Sorry, perhaps you meant that the application which is embedding the MySQL client ought to use pledge. In that case, that does seem like a good defensive usage of pledge which would prevent this kind of attack, notwithstanding the need to fix the issue in the client itself.