We have recently disclosed a list of vulnerabilities to Sophos that allow local attackers to elevate their privileges and execute code in the security context of the SYSTEM user account.

Affected Products

  • SafeGuard Enterprise 8.00.4 and earlier (Fix: install 8.00.5)
  • SafeGuard Easy 7.00.2.35 and earlier (Fix: install 7.00.3)
  • SafeGuard LAN Crypt 3.95.1.13 and earlier (Fix: install 3.95.2)

Sophos has also provided patches for earlier versions in case there are issues upgrading to one of the aforementioned latest versions.
For further details regarding the affected products and the respective fixed versions please visit:

Proof of Concept

Technical details

In this section we provide a few technical details about the reported issues.

Module: lcencvm.sys

1. Local Privilege Escalation via IOCTL 0x802022E0 [CVE-2018-6857]

By crafting an input buffer we can control the execution path to the point where the constant 0x12 will be written to a user-controlled address (0xF8F8F8F8).

eax=00000000 ebx=0028ef18 ecx=00000000 edx=0028ef1a esi=f8f8f8f8 edi=87d34a80
eip=8906e0c5 esp=a59c5100 ebp=a59c5994 iopl=0 nv up ei ng nz ac po cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010293
lcencvm+0x580c5:
8906e0c5 c70612000000 mov dword ptr [esi],12h ds:0023:f8f8f8f8=????????

We can take advantage of this condition to modify the SEP_TOKEN_PRIVILEGES structure of the Token object belonging to the exploit process and grant the SE_DEBUG_NAME privilege. This allows the exploit process to interact with higher privileged processes running as SYSTEM and execute code in their security context.

2. Local Privilege Escalation via IOCTL 0x80202014 [CVE-2018-6855]

By crafting an input buffer we can control the execution path to the point where the constant 0xFFFFFFF will be written to a user-controlled address (0xF8F8F8F8).

eax=0022e400 ebx=0022e400 ecx=f8f8f8f8 edx=0022e400 esi=00000000 edi=00000000
eip=890645b7 esp=a5984698 ebp=00000000 iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
lcencvm+0x4e5b7:
890645b7 c701ffffffff mov dword ptr [ecx],0FFFFFFFFh ds:0023:f8f8f8f8=????????

The same method as used previously can be used to successfully exploit this issue.

3. Local Privilege Escalation via IOCTL 0x80202298 [CVE-2018-6852]

By crafting an input buffer we can control the execution path to the point where nt!memset is called to zero out contents of a user-controlled address (0xF8F8F8F8).

eax=00000000 ebx=0021fb90 ecx=00000001 edx=00000000 esi=f8f8f8f8 edi=f8f8f8f8
eip=82a7da45 esp=a59bd4dc ebp=00000000 iopl=0 nv up ei pl nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202
nt!memset+0x45:
82a7da45 f3ab rep stos dword ptr es:[edi]

We can take advantage of this condition to zero-out the pointer to the security descriptor in the object header of a privileged process and run code in the context of a process running as SYSTEM.
This method can be used up to Windows 10 prior to v1607 as discussed here: https://labs.nettitude.com/blog/analysing-the-null-securitydescriptor-kernel-exploitation-mitigation-in-the-latest-windows-10-v1607-build-14393/

4. Local Privilege Escalation via IOCTL 0x80206040 [CVE-2018-6851]

By crafting an input buffer we can control the execution path to the point where the constant DWORD 0 will be written to a user-controlled address (0xF8F8F8F8).

eax=00000000 ebx=00000000 ecx=002cf9e8 edx=002cf9e8 esi=002cf9e8 edi=f8f8f8f8
eip=89063ffa esp=a5970948 ebp=a5970998 iopl=0 nv up ei pl nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010206
lcencvm+0x4dffa:
89063ffa c70700000000 mov dword ptr [edi],0 ds:0023:f8f8f8f8=????????

The same method as previously used can be used to successfully exploit this issue.

5. Local Privilege Escalation via IOCTL 0x8020601C [CVE-2018-6856]

By crafting an input buffer we can control the execution path to the point where a global variable [lcencvm+0x6725c (8907d25c)] will be written to a user controlled address (0xF8F8F8F8).

eax=f8f8f8f8 ebx=00000000 ecx=00000003 edx=00000000 esi=852a0638 edi=87e3a6e0
eip=89065d7a esp=a91df954 ebp=a91df998 iopl=0 nv up ei ng nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010286
lcencvm+0x4fd7a:
89065d7a 890 mov dword ptr [eax],ecx ds:0023:f8f8f8f8=????????

The same method as previously used can be used to successfully exploit this issue.

6. Local Privilege Escalation via IOCTL 0x80206024 [CVE-2018-6853]

By crafting an input buffer we can control the execution path to the point where a global variable [lcencvm+0x67268 (8907d268)] will be written to a user controlled address (0xF8F8F8F8).

eax=f8f8f8f8 ebx=00000000 ecx=00000002 edx=00000000 esi=852a0638 edi=8512b6f0
eip=89065daa esp=a5970954 ebp=a5970998 iopl=0 nv up ei ng nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010286
lcencvm+0x4fdaa:
89065daa 8908 mov dword ptr [eax],ecx ds:0023:f8f8f8f8=????????

The same method as previously used can be used to successfully exploit this issue.

Module: SGStDrvm.sys

1. Local Privilege Escalation via multiple IOCTLs [CVE-2018-6854]

IOCTL examples: 0x8810200B, 0x8810200F, 0x8810201B, 0x8810201F, 0x8810202B, 0x8810202F, 0x8810203F, 0x8810204B, 0x88102003, 0x88102007, 0x88102013, 0x88102017, 0x88102027, 0x88102033, 0x88102037, 0x88102043, 0x88102047

When some conditions are not met, the driver writes an error code (0x2000001A) to user-controlled address. Also, note that all the aforementioned IOCTLs use transfer type METHOD_NEITHER, which means that the I/O manager does not validate any of the supplied pointers and buffer sizes. So, even though the driver checks for input/output buffer sizes, it doesn’t validate if the pointers to those buffers are actually valid.
So, we can supply a pointer for the output buffer to a kernel address space address, and the error code will be written there. We can take advantage of this condition to modify the SEP_TOKEN_PRIVILEGES structure of the Token object belonging to the exploit process and grant the SE_DEBUG_NAME privilege. This allows the exploit process to interact with higher privileged processes running as SYSTEM and execute code in their security context.

Disclosure Timeline

  1. Date of discovery: December 2017
  2. Vendor informed: 11 January 2018
  3. Vendor fix received: 20 April 2018
  4. Fix tested : 25 April 2018
  5. Agreed to disclose from 30 May onward: 26 April 2018
  6. Public Disclosure: 25 June 2018