On May 12, 2014, SAP published updates to Adaptive Server Enterprise versions 15.0. 15.5 and 15.7 on all platforms. These updates addressed a security flaw in a built-in procedure implementation. The flaw allows any authenticated database user to overwrite the master encryption key or execute arbitrary code in the database server process context. Below I will discuss in detail what happens inside the server when the vulnerable procedure is invoked.
In the fall of 2013 I was researching various aspects of SAP ASE functionality and one thing that caught my attention was the SQL Debugger (sqldbgr.jar) using undocumented built-in procedures like dbgrpc_attach, dbgrpc_detach and so on. This opened up a whole set of internal undocumented procedures many of which are publicly callable. I performed further analysis by simply calling each procedure, which revealed that some were vulnerable to buffer overflows and other types of attack.
SAP Adaptive Server Enterprise has many built-in procedures that are callable using stored procedure calls by ordinary database users. One of them is named hacmpmsgxchg and is supposedly responsible for some of the High Availability functionality. In unpatched versions of ASE this procedure is publicly callable. The procedure's code fails to handle invalid user input: if the parameters passed to the procedure are specially crafted, the procedure will either overwrite the server's master encryption key or will trigger stack-based buffer overflow that allows for arbitrary code execution.
The master encryption key (if set) is used to protect other encryption keys. Overwriting the master key will replace the valid master key with an attacker-provided key. This problem happens because internally the procedure calls another one that sets the master key and both have no permission checks.
The other variation of this attack will run attacker-supplied code on the server. To illustrate this vulnerability here is a piece of pseudo-code that mimics the procedure beginning:
int __stdcall hacmpmsgxchg(int a1, int a2)
{
void *Src;
size_t Size;
char Dst[2048];
...
Src = *(void **)(a2 + 20);
Size = *(_DWORD *)(a2 + 24);
if ( Size <= 0x4000 )
memcpy(Dst, Src, Size);
else
memmove_error(Size, 0x4000);
...
Here a1 and a2 are user-controlled parameters passed to the procedure. So the Size variable is taken from user input, as is Src , and then is used in the memcpy call to local (stack-based) buffer Dst of 2048 bytes, a classic stack-based overflow condition.
An interesting point is that in its first attempt to fix this issue SAP added some more checks inside the function, but it was still possible to bypass them using a more sophisticated exploit technique. Finally SAP fixed this issue properly. Our advisory includes information about the necessary patches per version.
There is no workaround for this issue: database administrators must apply the patch. This is because the procedure in question is internal, undocumented and has no mechanism to set permissions or to disable it.
Vulnerable versions are: 15.0.3 below ESD#4.4, 15.5 below ESD#5.4, 15.7 below SP122 (SP62).
