Today I wake up with an advisory published by Laurent Gaffié where a possible BSOD is announced. The advisory does not provide any technical detail and it is only based on empirical results so it needs to be verified. This is the result of my brief research. Change DoS to Remote Code Execution and Local Privilege Escalation.

Why?

Module: srv2.sys

; int __stdcall Smb2ValidateProviderCallback(PVOID DestinationBuffer)
_Smb2ValidateProviderCallback@4 proc near
…
…
.text:000156B3 loc_156B3:                              ; CODE XREF: Smb2ValidateProviderCallback(x)+4D5j
.text:000156B3                                         ; Smb2ValidateProviderCallback(x)+4DEj
.text:000156B3                 movzx   eax, word ptr [esi+0Ch]; packet->SBM_Header->Process_ID_High
.text:000156B7                 mov     eax, _ValidateRoutines[eax*4]; BUG - out-of-bounds dereference.
.text:000156BE                 test    eax, eax
.text:000156C0                 jnz     short loc_156C9
.text:000156C2                 mov     eax, 0C0000002h
.text:000156C7                 jmp     short loc_156CC
.text:000156C9 ; —————————————————————————
.text:000156C9
.text:000156C9 loc_156C9:  ; CODE XREF: Smb2ValidateProviderCallback(x)+4F3j
.text:000156C9                 push    ebx
.text:000156CA                 call    eax ; Smb2ValidateNegotiate(x) ; Smb2ValidateNegotiate(x) - KABOOOM!!
  As you can see,[ ESI+0xC ] points to our packet, exactly to the ProcessIDHigh header field whose size is 16 bits. We can fully control this value. Later on this value is used as index to a Function Pointer within the function table _ValidateRoutines. Classic Bug, an out-of-bounds dereference since the code is not checking the size of the table before dereferencing the function pointer. This is the reason why this vulnerability is a Remote Code Execution and not only a DoS. And this is the reason why the exploit provided may or may not crash a machine. If the page pointed by the index is invalid the system will BSOD otherwise it might crash on another point or simply not to crash.

How to exploit it?

We see that ESI points to our packet, in addition this function table is located at .data which is located before .PAGE addresses so we can dereference a pointer in that area as well. We "only" need to find a suitable pointer to control the execution.

Vulnerable systems:
Vista, 7 RC and < 2008 Server R2 according to Microsoft.

Keep tuned, I'll post any further development regarding this issue.

More info on the blog (castilian) where I collaborate: http://blog.48bits.com

Hi!
Time to VPN Clients...Reversemode proudly presents "Safenet SoftRemote IKE ireIke.exe service Remote Stack Overflow (Pre-Auth) "

ZDI Advisory

Safenet SoftRemote Overview
http://www.safenet-inc.com/softremote/

SoftRemote is an award-winning VPN client platform for desktop and mobile devices that delivers robust security, ease of use, and powerful policy management features. With an installed base of millions of users, SoftRemote has become the de-facto standard for VPN client software worldwide. Leading VPN vendors use the SoftRemote's OEM version within their custom solutions. Some of these products are:
● Juniper NetScreen Remote
● NetGear Prosafe VPN client
● WatchGuard Mobile User VPN Client

Thus, the vulnerability affects every “SoftRemote powered” product.



Preface

In this document we use Juniper NetScreen Remote as “scapegoat” to demonstrate the vulnerability since it is bundled with the vulnerable version of Safenet's SoftRemote OEM version. This fact does not mean that Juniper NetScreen Remote is the only product affected. As it was explained before, every product powered by Safenet's SoftRemote is vulnerable.

Technical Details
ireIke.exe service is prone to a remote stack overflow. Malicious attackers can anonymously exploit this flaw by sending a specially crafted UDP packet to the port 62514. Successful exploitation grants SYSTEM privileges to the attacker.
ireIke.exe service binds several ports for internal usage, this process can be traced by debugging the following function:
Module: ireIke.exe

.text:0043C8E0 sub_43C8E0 proc near ; CODE XREF: sub_41A8B0+295#p
.text:0043C8E0 ; sub_437F00+442#p ...
.text:0043C8E0
.text:0043C8E0 WSAData = WSAData ptr -190h
.text:0043C8E0 arg_0 = dword ptr 4
[...]
.text:0043CAF4 loc_43CAF4: ; CODE XREF:
sub_43C8E0+1ED#j
.text:0043CAF4 ; sub_43C8E0+208#j
.text:0043CAF4 mov eax, dword_46F2BC
.text:0043CAF9 push eax ; int
.text:0043CAFA push 0F432h ; 62514 – IPC socket
.text:0043CAFF push 11h ; int
.text:0043CB01 push 2 ; af
.text:0043CB03 call sub_43B850 ; binds
.text:0043CB08 add esp, 10h
.text:0043CB0B cmp eax, edi
.text:0043CB0D mov dword_46F280, eax
.text:0043CB12 jnz short loc_43CB34
.text:0043CB14 test byte_45ED58, bl
.text:0043CB1A jz short loc_43CB34
.text:0043CB1C push offset SourceName ; "IreIKE"
.text:0043CB21 push offset aSUnableToBin_1 ; "%s: Unable to
bind IPC socket!"
.text:0043CB26 mov dword_479FF8, ebx
.text:0043CB2C call sub_437020
.text:0043CB31 add esp, 8
ireIKE.exe after receiving the packet, uses the fifith byte as a “command”.
.text:00449E19 movsx eax, byte ptr [ebx+4] ; fifth byte
.text:00449E1D add eax, 0FFFFFFD8h ; command - 0x28
.text:00449E20 mov [esp+3F4h+var_3DC], ebp
.text:00449E24 cmp eax, 19h ; switch 26 cases 'commands'
.text:00449E27 ja loc_44AB78 ; default
.text:00449E27 ; jumptable 00449E35
cases 7,9,10,14,16-18,20-24
.text:00449E2D xor edx, edx
.text:00449E2F mov dl, ds:byte_44ABE4[eax]
.text:00449E35 jmp ds:off_44ABA8[edx*4] ; switch jump