I've been asked to determine if the client (be it dbisql, ODBC/SQL Anywhere driver, etc) can disallow the reading/writing of client files. I know this is normally controlled by the IQ / SQL Anywhere servers but if a bad guy was able to gain control of the db server or place a proxy inbetween the client and the server, the bad guy could potentially read/write files on the clients.
TLS doesn't guarantee no man in the middle attacks, it just makes them less likely.
As far as os permissions, if the user running the application connects to multiple sources of information, it is possible for a "bad guy" to use the read client file to obtain information that the user is authorized to have but the bad guy isn't. For write client file, the "bad guy" could create a file that contains an exploit or overwrite data files that would normally go into another system.
The number of people who could actually accomplish what you are suggesting is incredibly small.
IMO your time would be better spent securing the server and adding mitigation - expect to be attacked and put tools in place to detect/alert and shut down the attack as soon as possible.
You opinion "time would be better spent" may indeed be correct, but in this context it reads too much like "SQL Anywhere can't do that, therefore it shouldn't be done".
"SQLA can't do it, therefore it shouldn't be done". I don't understand this comment. Sure, SQLA can't do this, but it could. We are constantly looking for ways to improve the product, and to actually decide whether or not a feature *should* be added to the futures list, we need to actually have an informed opinion, which I was expressing. I guess you can assume my goal is to minimize the amount of work I or the SQL Anywhere team have to do, or that I am so intoxicated by the SQLA Koolaid that I am incapable of having an independent thought or opinion, but you'd be wrong.
As to your other points, I had already considered them whenI was told forming my opinion. The government 'hacking' teams are (IMO) still an incredibly small number of the total developer population, who have specific goals and targets.
Yes, the cost of a breach can be incredibly high (in trust, dollars, etc...) but that is a risk that has to be measured by the business owner against the potential benefit of having something possibly exposed, and/or the cost of locking it down, which is what I was referring to in suggesting spending time elsewhere. I assume this is the reason this question was asked - in order to determine risk and whether or not it could be minimized.
I gave an opinion, which I thought was useful and possibly could encourage further positive conversation/comment, which may lead to a different type of request that could have broader benefits to the security of the SQL Anywhere product. Insinuations otherwise are simply incorrect.
As it stands because of the client security hole, my recommendation to my clients is NOT to use the SQL Anywhere drivers/api on any client box that accesses multiple sensitive systems or has sensitive information stored anywhere on that device or where the user that the software would run as has access to.
I hope that SAP takes this seriously and fixes the security issue immediately.
I will bring this up with the SQL Anywhere team. However, for the record, I don't see this as a serious security issue, unless I am missing something fundamental.
I don't disagree that this *could* happen, but there are just too many security destroying pre-requisites that need to occur for it to happen. Two of the biggest IMO are that the attacker has to be on the client network and have completely compromised the database server machine (not just the database server process). Both of these things are way way way bigger breaches than what you are talking about in most cases. If they are already into the network that far, the database client security isn't going to prevent an attacker from doing damage.
On top of that, they would need to reverse engineer the complete SQL Anywhere communications protocol (not just the file access pieces) to fool the client into thinking it is talking to a server, and the client application would have actually issue the commands in question for the mitm to inject a malicious read/write. If the application never issues LOAD/UNLOAD table from file, or uses the read/write file procedures, that would be sufficient to prevent this attack.
Given this information, can you give me more information on why you think this is so serious/important to fix?
no, they wouldn't have to reverse engineer the complete protocol, just certain parts of it which honestly wouldn't take very long at all. There are several howtos for wireshark and other security tools that walk you through the reverse engineering.
As far as SQL Anywhere client knowing whether it was connecting directly to the server or through a proxy... you can set up a proxy server with ssh (also known as an ssh tunnel). Use a compromised ssh and you can directly manipulate the data stream.
Consider a user that has two applications. First application connects to a rather mundane SQL Anywhere database on the network.
Second application connects to a HR database running Oracle. Second application caches information locally and saves reports, etc.
Malicious user (perhaps former admin) compromises the connection to the SQL Anywhere server (redirect tcp connection to a malicious application that acts largely as a tcp pass through). Malicious user knows about the HR application and where it stores the information. By using the compromised SQL Anywhere connection it starts looking for said file(s) on inactive connections. Since the application has NO ABILITY to stop this, the HR users are quickly identified and the data is loaded into temporary tables. The data is retrieved, perhaps connection information to the HR database / perhaps the desired data itself.
This is basic hacking/exploit 101 stuff here. SAP needs to close the security hole. How long does this be ignored before an exploit is made public and SAP PR and Engineering have to scramble for a KNOWN ISSUE.
I am not sure why you think this is being ignored. I responded 5 minutes after you posted your question... I am trying make sure I understand exactly what you are claiming is a potential problem. We are dealing with many different layers/aspects of security, and regardless of how easy you think it is, how easy it *actually* is to do this (if it is actually possible) and what it means to the overall security environment are important factors. For example, if your SSH proxy can so easily defeat client/server TLS, why bother hacking the SQLA client at all? It would be far easier/faster to just compromise the Oracle connection using the *exact* same method and intercept the HR application data directly.
If there is one thing I have learned regarding security issues, its that jumping to conclusions before understanding the real exposure and having all the facts verified is not a good idea.
In any case, I was in the middle of addressing your scenario above and found that there may already be a solution after all. As I said earlier, I was discussing this with the SQL Anywhere team. They reminded me that we actually do have something that should address your concern. There is a callback you can implement that is triggered by the client on any file transfer (dcx link):
The callback provides the file name and whether it is being read/written, and in some cases it is actually required (eg. when the read/write is initiated from a server stored procedure). Returning 0 will deny the file read/write operation. So it seems you can actually prevent file reads/writes from the client.
On a side note and please take this as constructive criticism. No one was attacking you. The hostility towards Breck and myself was uncalled for. Before you reply to someone, take a breather and read what the person wrote again. Even if you still think the person is attacking you, as an SAP employee you should take the high road or hand it off to another SAP employee.
FWIW, excluding my response to Breck, there was no hostility on my part in any of our exchange, nor did I feel 'attacked' by any of your posts. If you would like to discuss further, please PM me, as personal comments are not appropriate in this forum.
Would (denial of) the WRITE CLIENT FILE system privilege have been useful here? So, user has a role that specifically doesn't include the WRITE CLIENT FILE system privilege.
Not really because the hypothetical exploit would come from the IQ/SQL Anywhere server (think data stream injection).
The call back DB_CALLBACK_VALIDATE_FILE_TRANSFER supplied by Jason allows the developer to close this hole by denying file transfers. It would be nice if the default behavior was to disallow file transfers and require the developers to enable it.
Of course, this is just one potential hole. It would be easier to infect the (assuming) windows client boxes IMO - see metasploit for the numerous methods of doing that.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.