Buffer Overflow in CAM.exe

Platforms affected

This was disassembled on cam.exe version 3.11.26.10 as part of the Unicenter Message Quieuing suite of products.

• cam.exe is used by multiple CA products
• Vendor has indicated that multiple platforms are affected

Summary

cam.exe is process which belongs to CA Unicenter suite. It is used and shared by multiple CA products. The vendor has indicated that it affects multiple platforms.

A vulnerability was discovered in one of the socket routines of cam.exe. The subroutine fails to check for boundaries of the received buffer size against the allocated stack size. This vulnerability is remotely exploitable which may result in remote code execution under the running system context and complete compromise of the hosts.

The flaw has been validated by Computer Associates, and it has been determined that this is the same flaw first discovered by and credited to CA's own internal audit team. A fix has already been made available and users are encouraged to apply the fix immediately.

Details

In procedure _log_security, 256 bytes is allocated onto the stack. A recv routine retrieves data from the socket parsed by handle 's' adopted from the _event_handler subroutine. The following routine handling the recv call function fails to check for the max size of the recv function buffer during looping and retrieval of data from the socket. Due to the direct exposure to sockets, if this vulnerability becomes exposed, it may be remotely exploitable and leveraged to overwrite frame pointer data further down the stack. This results in remote code execution by direct manipulation of frame pointers with system level privileges. The Dir of Vuln Research from CA, has reacted swiftly without hesitation to help assess the findings. Ken Williams of CA has confirmed the same vulnerability was discovered by their internal security team, and a patch is available for immediate download.

	.text:0040E0F0 ; int __cdecl log_security(int,SOCKET s)
	.text:0040E0F0 _log_security   proc near               
	.text:0040E0F0                 sub     esp, 100h        ; stack allocation, 256 bytes large
	.text:0040E0F6                 push    esi
	.text:0040E0F7                 push    edi
	.text:0040E0F8                 mov     edi, [esp+108h+s]
	.text:0040E0FF                 lea     esi, [esp+108h+buf]
	.text:0040E103
	.text:0040E103 loc_40E103:                            
	.text:0040E103                 push    0               
	.text:0040E105                 push    1                ; len
	.text:0040E107                 push    esi              ; buf
	.text:0040E108                 push    edi              ; s
	.text:0040E109                 call    _recv@16         ; recv(x,x,x,x)
	.text:0040E10E                 cmp     eax, 1
	.text:0040E111                 jnz     short loc_40E103 ; if not size of 1, simply loop. Else check for null
	.text:0040E111                                          ; note that no further memory is allocated
	.text:0040E113                 cmp     byte ptr [esi], 0
	.text:0040E116                 jz      short loc_40E11B ; jump if null - escape out of loop
	.text:0040E118                 inc     esi
	.text:0040E119                 jmp     short loc_40E103 ; This reads the buffer byte by byte until a NULL is received
	.text:0040E119                                          ; Which escapes and jumps to loc_40E11B
	.text:0040E11B ; ---------------------------------------------------------------------------
	.text:0040E11B loc_40E11B:                             
	.text:0040E11B                 lea     eax, [esp+108h+buf]
	.text:0040E11F                 push    eax
	.text:0040E120                 call    _log_sv
	.text:0040E125                 add     esp, 4
	.text:0040E128                 pop     edi
	.text:0040E129                 pop     esi
	.text:0040E12A                 add     esp, 100h
	.text:0040E130                 retn
	.text:0040E130 _log_security   endp

A back trace finds the responsible call for this function in the _get_message procedure. The function _get_message is called upon by subroutine _event_handler in cam.exe

Recommendations

• Apply the appropriate security patches immediately to address the issue
• Administratively disallow unsolicited connections by the use of a firewall
• Enterprise users should ensure that only trusted traffic are allowed into the internal network. All untrusted traffic should be disallowed at perimeter firewalls.

Vendor Status

Vendor notification - Vendor initially notified on the 10th of Jan 2006
Publicly released on - August 2005 by CA Internal Audit Team

In reply by CA Vuln Research on 12 Jan 2006 ...

We have completed our review of your report. This vulnerability was addressed in the CAM fixes that were published in August 2005.

References

• http://marc.theaimsgroup.com/?l=bugtraq&m=112475767805818&w=2
• http://supportconnectw.ca.com/public/ca_common_docs/camsecurity_notice.asp
• An exploit was released by H D Moore of the Metasploit Project http://metasploit.com/projects/Framework/exploits.html#cacam_logsecurity_win32

Disclaimer

This advisory may change without prior notice

There are no warranties, implied or express, with regard to the information in this advisory. In no event shall the author or associated parties be liable for any direct or indirect damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk.

Other stuff