admin – Tencent's Xuanwu Lab http://xlab.tencent.com/en Wed, 21 Dec 2016 08:35:57 +0000 en-US hourly 1 https://wordpress.org/?v=4.6 Return Flow Guard http://xlab.tencent.com/en/2016/11/02/return-flow-guard/ Wed, 02 Nov 2016 06:29:27 +0000 http://xlab.tencent.com/en/?p=137 Continue reading "Return Flow Guard"]]> [DannyWei, lywang, FlowerCode] of Tencent Xuanwu Lab

Here is a preliminary documentation of the RFG implementation. We will update it once we have new findings and corrections.

We analyzed the Return Flow Guard introduced in Windows 10 Redstone 2 14942, released on October 7, 2016.

1 PROTECTION METHODS

Microsoft introduced Control Flow Guard in Windows 8.1 to protect against malicious modification of indirect call function pointers. CFG checks the target function pointer before each indirect call. However, CFG cannot detect modification of the return address on stack, or Return Oriented Programming.
The newly added RFG effectively stops these kind of attacks by saving the return address to fs:[rsp] at the entry of each function, and compare it with the return address on stack before returning.
Enabling RFG require both compiler and operating system support. During compilation, the compiler instruments the file by reserving a certain number of instruction spaces in the form of nop instructions.
When the target executable runs on a supported operating system, the reserved spaces are dynamically replaced with RFG instructions to check function return addresses. Otherwise, these nop instructions will not interfere with normal execution flow of the program.
The difference between RFG and GS (Buffer Security Check) is that the stack cookie can be obtained by using information leak or brute forcing, the RFG return address is written to the Thread Control Stack out of reach of attackers. This significantly increased the difficulty of the attack.

2 CONTROL SWITCHES

2.1 MMENABLERFG GLOBAL VARIABLE

This variable is controlled by a registry value located at:

\Registry\Machine\SYSTEM\CurrentControlSet\Control\Session Manager\kernel
EnableRfg : REG_DWORD

2.1.1 Initialization

KiSystemStartup -> KiInitializeKernel -> InitBootProcessor -> CmGetSystemControlValues

2.2 IMAGE FILE CONTROL FLAG

Control flags are stored in the IMAGE_LOAD_CONFIG_DIRECTORY64 structure in PE file.
Flags in GuardFlag field indicate RFG support status.

#define IMAGE_GUARD_RF_INSTRUMENTED                    0x00020000 // Module contains return flow instrumentation and metadata
#define IMAGE_GUARD_RF_ENABLE                          0x00040000 // Module requests that the OS enable return flow protection
#define IMAGE_GUARD_RF_STRICT                          0x00080000 // Module requests that the OS enable return flow protection in strict mode

2.3 PROCESS CONTROL FLAG

2.3.1 Querying

The RFG status can be queried through Win32 API GetProcessMitigationPolicy.

typedef enum _PROCESS_MITIGATION_POLICY {
// ...
    ProcessReturnFlowGuardPolicy = 11
// ...
} PROCESS_MITIGATION_POLICY, *PPROCESS_MITIGATION_POLICY;

2.3.2 Structure Definition

typedef struct _PROCESS_MITIGATION_RETURN_FLOW_GUARD_POLICY {
    union {
        DWORD Flags;
        struct {
            DWORD EnableReturnFlowGuard : 1;
            DWORD StrictMode : 1;
            DWORD ReservedFlags : 30;
        } DUMMYSTRUCTNAME;
    } DUMMYUNIONNAME;
} PROCESS_MITIGATION_RETURN_FLOW_GUARD_POLICY, *PPROCESS_MITIGATION_RETURN_FLOW_GUARD_POLICY;

3 NEW MEMBERS IN PORTABLE EXECUTABLE FORMAT

3.1 IMAGE_LOAD_CONFIG_DIRECTORY64

RFG instrumented portable executables have added several new fields, 24 bytes in total.

ULONGLONG  GuardRFFailureRoutine; 
ULONGLONG  GuardRFFailureRoutineFunctionPointer; 
DWORD      DynamicValueRelocTableOffset;
WORD       DynamicValueRelocTableSection;

2 pointers (16 bytes):
Virtual Address of the _guard_ss_verify_failure function
Virtual address of the _guard_ss_verify_failure_fptr function pointer, which points to the _guard_ss_verify_failure_default function by default.

Information about the address table (6 bytes):
DynamicValueRelocTableOffset recording the offset of dynamic relocation table relative to the relocation table, and
DynamicValueRelocTableSection recorded the section index of the dynamic value relocation table.
The remaining bytes are reserved.

3.2 IMAGE_DYNAMIC_RELOCATION_TABLE

RFG instrumented portable executables have a new dynamic relocation table after the normal relocation table.

typedef struct _IMAGE_DYNAMIC_RELOCATION_TABLE {
    DWORD Version;
    DWORD Size;
//  IMAGE_DYNAMIC_RELOCATION DynamicRelocations[0];
} IMAGE_DYNAMIC_RELOCATION_TABLE, *PIMAGE_DYNAMIC_RELOCATION_TABLE;

typedef struct _IMAGE_DYNAMIC_RELOCATION {
    PVOID Symbol;
    DWORD BaseRelocSize;
//  IMAGE_BASE_RELOCATION BaseRelocations[0];
} IMAGE_DYNAMIC_RELOCATION, *PIMAGE_DYNAMIC_RELOCATION;

typedef struct _IMAGE_BASE_RELOCATION {
    DWORD   VirtualAddress;
    DWORD   SizeOfBlock;
//  WORD    TypeOffset[1];
} IMAGE_BASE_RELOCATION;
Symbol in IMAGE_DYNAMIC_RELOCATION indicates the stored entries are for function prologues or function epilogues, defined as follows:
#define IMAGE_DYNAMIC_RELOCATION_GUARD_RF_PROLOGUE 0x00000001
#define IMAGE_DYNAMIC_RELOCATION_GUARD_RF_EPILOGUE 0x00000002

The absolute address of an entry can be calculated from ImageBase + VirtualAddress + TypeOffset.

4 INSTRUCTION INSERTION

4.1 COMPILE TIME

4.1.1 Inserted Prologue Bytes (9 Bytes)

MiRfgNopPrologueBytes
xchg    ax, ax
nop     dword ptr [rax+00000000h]
4.1.2   Inserted Epilogue Bytes (Example, 15 Bytes)
retn
db 0Eh dup(90h)
retn

4.1.2 Inserted Epilogue Bytes (Example, 15 Bytes)

retn
db 0Eh dup(90h)
retn

To reduce overhead, the compiler also inserts a _guard_ss_common_verify_stub function. Instead of inserting nop bytes at the end of every function, the compiler simply ends most function with a jmp to this stub function. This stub function has nop bytes to be replaced with epilogue bytes by the kernel at runtime, and a retn instruction at the end.

__guard_ss_common_verify_stub proc near
retn
db 0Eh dup(90h)
retn
__guard_ss_common_verify_stub endp

4.2 RUNTIME

MiPerformRfgFixups performs the instruction replacement according to function information stored in IMAGE_DYNAMIC_RELOCATION_TABLE when new executable section is being created.

4.2.1 Replaced Prologue Bytes (9 Bytes)

The kernel uses MiRfgInstrumentedPrologueBytes to replace compiler inserted prologue bytes.

MiRfgInstrumentedPrologueBytes
mov     rax, [rsp]
mov     fs:[rsp], rax

4.2.2 Replaced Epilogue Bytes (15 Bytes)

The kernel uses MiRfgInstrumentedEpilogueBytes and _guard_ss_verify_failure function address recorded in to replace the compiler inserted epilogue bytes.

MiRfgInstrumentedEpilogueBytes
mov     r11, fs:[rsp]
cmp     r11, [rsp] 
jnz    

5 THREAD CONTROL STACK

To implement RFG, Microsoft introduced Thread Control Stack, and reused the fs segment register on x64 architecture. When RFG enabled process executes the mov fs:[rsp], rax instructions, fs segment register points to the current thread’s ControlStackLimit on the control stack, and write rax into rsp offset.
All user mode threads in one process are using different memory blocks within same Thread Control Stack. We can enumerate the virtual address descriptor tree of the process to obtain the _MMVAD structure that describes the process’s Thread Control Stack.

    typedef struct _MMVAD {
      /* 0x0000 */ struct _MMVAD_SHORT Core;
      union {
        union {
          /* 0x0040 */ unsigned long LongFlags2;
          /* 0x0040 */ struct _MMVAD_FLAGS2 VadFlags2;
        }; /* size: 0x0004 */
      } /* size: 0x0004 */ u2;
      /* 0x0044 */ long Padding_;
      /* 0x0048 */ struct _SUBSECTION* Subsection;
      /* 0x0050 */ struct _MMPTE* FirstPrototypePte;
      /* 0x0058 */ struct _MMPTE* LastContiguousPte;
      /* 0x0060 */ struct _LIST_ENTRY ViewLinks;
      /* 0x0070 */ struct _EPROCESS* VadsProcess;
      union {
        union {
          /* 0x0078 */ struct _MI_VAD_SEQUENTIAL_INFO SequentialVa;
          /* 0x0078 */ struct _MMEXTEND_INFO* ExtendedInfo;
        }; /* size: 0x0008 */
      } /* size: 0x0008 */ u4;
      /* 0x0080 */ struct _FILE_OBJECT* FileObject;
    } MMVAD, *PMMVAD; /* size: 0x0088 */

    typedef struct _MMVAD_SHORT {
      union {
        /* 0x0000 */ struct _RTL_BALANCED_NODE VadNode;
        /* 0x0000 */ struct _MMVAD_SHORT* NextVad;
      }; /* size: 0x0018 */
      /* 0x0018 */ unsigned long StartingVpn;
      /* 0x001c */ unsigned long EndingVpn;
      /* 0x0020 */ unsigned char StartingVpnHigh;
      /* 0x0021 */ unsigned char EndingVpnHigh;
      /* 0x0022 */ unsigned char CommitChargeHigh;
      /* 0x0023 */ unsigned char SpareNT64VadUChar;
      /* 0x0024 */ long ReferenceCount;
      /* 0x0028 */ struct _EX_PUSH_LOCK PushLock;
      union {
        union {
          /* 0x0030 */ unsigned long LongFlags;
          /* 0x0030 */ struct _MMVAD_FLAGS VadFlags;
        }; /* size: 0x0004 */
      } /* size: 0x0004 */ u;
      union {
        union {
          /* 0x0034 */ unsigned long LongFlags1;
          /* 0x0034 */ struct _MMVAD_FLAGS1 VadFlags1;
        }; /* size: 0x0004 */
      } /* size: 0x0004 */ u1;
      /* 0x0038 */ struct _MI_VAD_EVENT_BLOCK* EventList;
    } MMVAD_SHORT, *PMMVAD_SHORT; /* size: 0x0040 */

    typedef struct _RTL_BALANCED_NODE {
      union {
        /* 0x0000 */ struct _RTL_BALANCED_NODE* Children[2];
        struct {
          /* 0x0000 */ struct _RTL_BALANCED_NODE* Left;
          /* 0x0008 */ struct _RTL_BALANCED_NODE* Right;
        }; /* size: 0x0010 */
      }; /* size: 0x0010 */
      union {
        /* 0x0010 */ unsigned char Red : 1; /* bit position: 0 */
        /* 0x0010 */ unsigned char Balance : 2; /* bit position: 0 */
        /* 0x0010 */ unsigned __int64 ParentValue;
      }; /* size: 0x0008 */
    } RTL_BALANCED_NODE, *PRTL_BALANCED_NODE; /* size: 0x0018 */

    typedef struct _RTL_AVL_TREE {
      /* 0x0000 */ struct _RTL_BALANCED_NODE* Root;
    } RTL_AVL_TREE, *PRTL_AVL_TREE; /* size: 0x0008 */

    typedef struct _EPROCESS {
        …
        struct _RTL_AVL_TREE VadRoot;
        …
    }

We can use _EPROCESS.VadRoot to walk through the VAD tree. If _MMVAD.Core.VadFlags.RfgControlStack flag is set, the current _MMVAD describes the virtual memory address range of the thread control stack (StartingVpn, EndingVpn, StartingVpnHigh, EndingVpnHigh in _MMVAD.Core), defined as follows:

    typedef struct _MMVAD_FLAGS {
      struct /* bitfield */ {
        /* 0x0000 */ unsigned long VadType : 3; /* bit position: 0 */
        /* 0x0000 */ unsigned long Protection : 5; /* bit position: 3 */
        /* 0x0000 */ unsigned long PreferredNode : 6; /* bit position: 8 */
        /* 0x0000 */ unsigned long NoChange : 1; /* bit position: 14 */
        /* 0x0000 */ unsigned long PrivateMemory : 1; /* bit position: 15 */
        /* 0x0000 */ unsigned long PrivateFixup : 1; /* bit position: 16 */
        /* 0x0000 */ unsigned long ManySubsections : 1; /* bit position: 17 */
        /* 0x0000 */ unsigned long Enclave : 1; /* bit position: 18 */
        /* 0x0000 */ unsigned long DeleteInProgress : 1; /* bit position: 19 */
        /* 0x0000 */ unsigned long PageSize64K : 1; /* bit position: 20 */
        /* 0x0000 */ unsigned long RfgControlStack : 1; /* bit position: 21 */ 
        /* 0x0000 */ unsigned long Spare : 10; /* bit position: 22 */
      }; /* bitfield */
    } MMVAD_FLAGS, *PMMVAD_FLAGS; /* size: 0x0004 */

    typedef struct _MI_VAD_EVENT_BLOCK {
      /* 0x0000 */ struct _MI_VAD_EVENT_BLOCK* Next;
      union {
        /* 0x0008 */ struct _KGATE Gate;
        /* 0x0008 */ struct _MMADDRESS_LIST SecureInfo;
        /* 0x0008 */ struct _RTL_BITMAP_EX BitMap;
        /* 0x0008 */ struct _MMINPAGE_SUPPORT* InPageSupport;
        /* 0x0008 */ struct _MI_LARGEPAGE_IMAGE_INFO LargePage;
        /* 0x0008 */ struct _ETHREAD* CreatingThread;
        /* 0x0008 */ struct _MI_SUB64K_FREE_RANGES PebTebRfg;
        /* 0x0008 */ struct _MI_RFG_PROTECTED_STACK RfgProtectedStack;
      }; /* size: 0x0038 */
      /* 0x0040 */ unsigned long WaitReason;
      /* 0x0044 */ long __PADDING__[1];
    } MI_VAD_EVENT_BLOCK, *PMI_VAD_EVENT_BLOCK; /* size: 0x0048 */

    typedef struct _MI_RFG_PROTECTED_STACK {
      /* 0x0000 */ void* ControlStackBase;
      /* 0x0008 */ struct _MMVAD_SHORT* ControlStackVad;
} MI_RFG_PROTECTED_STACK, *PMI_RFG_PROTECTED_STACK; /* size: 0x0010 */

When a RFG protected thread is created, nt!MmSwapThreadControlStack sets the thread’s ETHREAD.UserFsBase. It uses MiLocateVadEvent to search for MMVAD to be set as UserFsBase.
It uses the following formula to calculate the ETHREAD.UserFsBase:

ControlStackBase = MMVAD.Core.EventList.RfgProtectedStack.ControlStackBase
ControlStackLimitDelta = ControlStackBase - (MMVAD.Core.StartingVpnHigh * 0x100000000 + MMVAD.Core.StartingVpn ) * 0x1000
ETHREAD.UserFsBase = ControlStackLimitDelta

Each thread has its own shadow stack range in Thread Control Stack. If the current thread uses range ControlStackBase ~ ControlStackLimit, then ControlStackLimit = KTHTREAD.StackLimit + ControlStackLimitDelta. So the actual value stored in UserFsBase is the offset of ControlStackLimit from StackLimit. When multiple threads access the shadow stack simultaneously, the actual address accessed is located at ETHREAD.UserFsBase + rsp.

6 RFG IN ACTION

We wrote a simple yara signature to identify RFG instrumented PE file.

rule rfg {
    strings:
        $pe = { 4d 5a }
        $a = { 66 90 0F 1F 80 00 00 00 00 }
        $b = { C3 90 90 90 90 90 90 90 90 90 90 90 90 90 90 C3 }
        $c = { E9 ?? ?? ?? ?? 90 90 90 90 90 90 90 90 90 90 E9 }

    condition:
        $pe at 0 and $a and ($b or $c)
}

Usage:

yara64.exe -r -f rfg.yara %SystemRoot%

We can observe from the output that most system executable files are already RFG instrumented in this version of Windows.
Here we use IDA Pro and WinDbg to examine a RFG instrumented calc.exe.

.text:000000014000176C wWinMain
.text:000000014000176C                 xchg    ax, ax
.text:000000014000176E                 nop     dword ptr [rax+00000000h]

The entry point before runtime replacement

0:000> u calc!wWinMain
calc!wWinMain:
00007ff7`91ca176c 488b0424        mov     rax,qword ptr [rsp]
00007ff7`91ca1770 6448890424      mov     qword ptr fs:[rsp],rax

The entry point after runtime replacement

.text:00000001400025BC __guard_ss_common_verify_stub
.text:00000001400025BC                 retn
.text:00000001400025BD                 db 0Eh dup(90h)
.text:00000001400025CB                 retn

The common verify stub function before runtime replacement

0:000> u calc!_guard_ss_common_verify_stub
calc!_guard_ss_common_verify_stub:
00007ff7`91ca25bc 644c8b1c24      mov     r11,qword ptr fs:[rsp]
00007ff7`91ca25c1 4c3b1c24        cmp     r11,qword ptr [rsp]
00007ff7`91ca25c5 0f85f5000000    jne     calc!_guard_ss_verify_failure (00007ff7`91ca26c0)
00007ff7`91ca25cb c3              ret

The common verify stub function after runtime replacement

7 REFERENCES

Exploring Control Flow Guard in Windows 10 Jack Tang, Trend Micro Threat Solution Team
http://sjc1-te-ftp.trendmicro.com/assets/wp/exploring-control-flow-guard-in-windows10.pdf

]]>
Pulse Secure Desktop Client (Juniper Junos Pulse) Privilege Escalation http://xlab.tencent.com/en/2016/07/19/xlab-16-001/ Tue, 19 Jul 2016 10:00:11 +0000 http://xlab.tencent.com/en/?p=52 Continue reading "Pulse Secure Desktop Client (Juniper Junos Pulse) Privilege Escalation"]]> XLAB ID: XLAB-16-001     

CVE ID: CVE-2016-2408     

Patch Status: Fixed

Affected Products:
Tested:
– Pulse Secure Desktop Client (Juniper Junos Pulse) All Versions up to v5.2r3

Vendor Provided (see vendor advisory in Solution section for details):
– Pulse Secure Desktop Client 5.2R1 to 5.2R2, 5.1R1 to 5.1R9, 5.0R1 to 5.0R15
– Standalone Pulse Installer Service 8.2R1 to 8.2R2, 8.1R1 to 8.1R9, 8.0R1 to 8.0R15, 7.4R1 to 7.4R13.6
– Pulse Secure Collaboration 8.2R1 to 8.2R2, 8.1R1 to 8.1R9, 8.0R1 to 8.0R15
– Odyssey Access Client all versions before 5.6R16

This vulnerability only affects Windows operating system.

Background:
“The Pulse Secure desktop client provides a secure and authenticated connection from an endpoint device (either Windows or Mac OS X) to a Pulse Secure gateway (either Pulse Connect Secure or Pulse Policy Secure).”

Vulnerability Details:
Juniper Junos Pulse (now known as Pulse Secure Desktop Client) installs a system service dsAccessService.exe, which owns a named pipe NeoterisSetupService.

This named pipe has an Everyone Full Control ACL and is writable by all users.

The pipe server employs a custom encryption function. The key is derived from processor type, processor frequency, operating system product id, operating system version, and hardcoded values.

This pipe is used to install new services, possibly for automatic upgrade purpose. Once new data is received from the pipe, it is decrypted as a file path, and the specified file is copied to C:\Windows\Temp\ and executed.

The service installation logic is implemented in dsInstallService.dll. It reads the path and split file name from the path. But this implementation has a bug which cause it to only split string after the “\” character from the path, but not the “/” character.

Pass in a path such as “C:\Users/Guest/AppData/Local/test.exe” will cause it to use “Users/Guest/AppData/Local/test.exe” as the file name, and CopyFile to path “C:\Windows\Temp\Users/Guest/AppData/Local/test.exe”.

When the CopyFile fails, the program then uses the original path “C:\Users/Guest/AppData/Local/test.exe” to create new process.

Finally, the service will verify the digital signature before executing the file. However, since the path is completely controllable by the attacker, simply placing a signed executable under “C:\Users/Guest/AppData/Local/” and hijack the executable with a malicious DLL can trigger arbitrary code execution and privilege escalation to SYSTEM.

Solution:
Install the latest version of Pulse Secure product, which is available from Pulse Secure official website.
Pulse Secure has also issued an advisory about this vulnerability:
https://kb.pulsesecure.net/articles/Pulse_Security_Advisories/SA40241

Disclosure Timeline:

2016/02/18 Report vulnerability to MITRE
2016/02/18 MITRE assigned CVE-ID CVE-2016-2408
2016/02/18 Provide vulnerability detail and CVE-ID to Pulse Secure via psirt at pulsesecure.net
2016/02/18 Pulse Secure responded that they are developing a fix, but no timeline is available
2016/03/07 Pulse Secure responded that they are still developing a fix, but no timeline is available,
“update soon”
2016/03/25 Pulse Secure responded that they are still developing a fix, but no timeline is available
2016/04/22 Notify Pulse Secure it is now 63 days since original report, asking fix progress
2016/04/26 Pulse Secure responded that they are still developing a fix, but no timeline is available,
asking for grace periods
2016/05/03 Reply that we do give grace periods but need an ETA
2016/05/12 Pulse Secure responded that they are still developing a fix, but no timeline is available
2016/05/19 Pulse Secure responded that they are still developing a fix, ETA is October 2016,
asking for grace periods
2016/05/20 Reply that we do not give grace period this long and another 60 days is the maximum.
2016/05/20 Pulse Secure responded that another 60 days is acceptable
2016/07/18 Pulse Secure responded that an issue has been found in internal testing, and
request another extension to August 1, 2016.
2016/07/18 Reply that we have already requested coordination from multiple organizations and
the process is irreversible. Last day is July 25, 2016.
2016/07/25 Coordinated disclosure

Credit:
This vulnerability was discovered by:   Zhipeng Huo

]]>
Microsoft Internet Explorer And Microsoft Edge Object Use-After-Free Remote Code Execution Vulnerability http://xlab.tencent.com/en/2015/12/29/xlab-15-025/ Tue, 29 Dec 2015 09:59:19 +0000 http://xlab.tencent.com/en/?p=50 Continue reading "Microsoft Internet Explorer And Microsoft Edge Object Use-After-Free Remote Code Execution Vulnerability"]]> XLAB ID: XLAB-15-025     

CVE ID: CVE-2015-1752     

Patch Status: Fixed

Vulnerability Details:
This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of Microsoft Internet Explorer and Microsoft Edge. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. An attacker can leverage this vulnerability to execute code under the context of the current process.

Disclosure Timeline:

2015/03/05 provide vulnerability detail to Microsoft Security Response Center via secure@microsoft.com
2015/04/01 Microsoft Security Response Center automatic reply
2015/06/09 Microsoft Security Response Center assigned CVE-ID CVE-2015-1752

Credit:
This vulnerability was discovered by:   exp-sky

]]>
Flash Player Memory Corruption in Display List Handling http://xlab.tencent.com/en/2015/12/29/xlab-15-024/ Tue, 29 Dec 2015 09:56:34 +0000 http://xlab.tencent.com/en/?p=48 Continue reading "Flash Player Memory Corruption in Display List Handling"]]> XLAB ID: XLAB-15-024     

CVE ID: CVE-2015-8459     

Patch Status: Fixed

Vulnerability Details:
The specific flaw exists within handling of display list. By maniuplating DisplayObject’s properties attacker can force memory corruption occuring in flash player. An attacker can leverage this vulnerability to execute code under the context of the current process.

Disclosure Timeline:

2015/07/13 Provide vulnerability detail to Adobe via psirt@adobe.com
2015/07/16 Adobe responded that they had opened case PSIRT-3929 for the issuse
2015/12/28 Adobe responded that they had assigned CVE-2015-8459 to the issue

Credit:
This vulnerability was discovered by:   kai kang

]]>
Trend Micro Vulnerability http://xlab.tencent.com/en/2015/12/02/xlab-15-023/ Wed, 02 Dec 2015 09:54:44 +0000 http://xlab.tencent.com/en/?p=44 Continue reading "Trend Micro Vulnerability"]]> XLAB ID: XLAB-15-023     

CVE ID: CVE-2015-8302     

Patch Status: Fixed

Vulnerability Details:

Disclosure Timeline:

2015/10/30 Provide vulnerability detail to Trend Micro via security at trendmicro.com
2015/10/31 Trend Micro automatic reply
2015/10/31 Trend Micro responded that they are verifying the proof of concept code
2015/11/20 Report vulnerability to MITRE
2015/11/21 MITRE assigned CVE-ID CVE-2015-8302
2015/11/25 Provide CVE-IDs to Trend Micro, asking fix progress
2015/12/02 Trend Micro responded that they are developing a fix, but no timeline is available
2015/12/09 Trend Micro responded that they have fixed the vulnerabilities, provided a hotfix for verification

Credit:
This vulnerability was discovered by:    wwq

]]>
Apple Safari Dialog Origin Spoofing Vulnerability http://xlab.tencent.com/en/2015/12/02/xlab-15-022/ Wed, 02 Dec 2015 09:54:03 +0000 http://xlab.tencent.com/en/?p=42 Continue reading "Apple Safari Dialog Origin Spoofing Vulnerability"]]> XLAB ID: XLAB-15-022     

CVE ID: CVE-2015-7093     

Patch Status: Fixed

Vulnerability Details:
Apple Safari is prone to a dialog box origin spoofing vulnerability. This issue may allow a remote attacker to carry out phishing style attacks. The vulnerability presents itself as dialog boxes from inactive windows may appear in other active windows. An attacker can exploit this issue by creating a malicious Web site and enticing a user to follow a link to the site. If the user follows the link, the attacker can then trigger this issue by somehow enticing a user to follow another link to a trusted site in a new window. The attacker can then display a spoofed dialog box to the user that seemingly originates from the trusted site. Typically this dialog box would mimic the legitimate site. An attacker may exploit this vulnerability to spoof an interface of a trusted web site. This vulnerability may aid in phishing style attacks.

Disclosure Timeline:

2015/8/25 Provide vulnerability detail to APPLE via product-security@apple.com
2015/8/25 APPLE automatic reply
2015/8/26 APPLE responded that they are verifying the proof of concept code
2015/11/17 APPLE asked how would you like to be acknowledged
2015/12/9 APPLE advisory disclosed,the issue was fiexed in IOS9.2. CVE-2015-7093

Credit:
This vulnerability was discovered by:   xisigr

]]>
BitDenfeder Vulnerability http://xlab.tencent.com/en/2015/12/02/xlab-15-021/ Wed, 02 Dec 2015 09:53:19 +0000 http://xlab.tencent.com/en/?p=40 Continue reading "BitDenfeder Vulnerability"]]> XLAB ID: XLAB-15-021     

CVE ID: CVE-2015-8693     

Patch Status: Unfixed

Vulnerability Details:

Disclosure Timeline:

2015/10/09 Ask for an vulnerability report contact address from BitDefender via bdsupport at bitdefender.com
2015/10/09 BitDefender technical support replied with template emails
2015/10/12 Stressed the seriousness of the vulnerability to BitDenfeder technical support
2015/10/19 BitDefender requests vulnerability detail
2015/10/19 Provide vulnerability detail to BitDefender
2015/10/19 BitDefender replied with apology for delay and a 1-year license key
2015/11/23 Report vulnerability to MITRE
2015/12/28 MITRE assigned CVE-ID CVE-2015-8693

Credit:
This vulnerability was discovered by:    wwq

]]>
Total Defense Vulnerability http://xlab.tencent.com/en/2015/12/02/xlab-15-020/ Wed, 02 Dec 2015 09:52:26 +0000 http://xlab.tencent.com/en/?p=37 Continue reading "Total Defense Vulnerability"]]> XLAB ID: XLAB-15-020     

CVE ID: CVE-2015-8695     

Patch Status: Unfixed

Vulnerability Details:

Disclosure Timeline:

2015/09/28 Ask for an vulnerability report contact address from Total Defense
via tdicustomerservice at totaldefense.com
2015/09/29 Total Defense requests vulnerability detail
2015/09/29 Provide vulnerability detail to Total Defense
2015/10/08 Ask if Total Defense has received the vulnerability detail
2015/10/08 Total Defense responded that they are planning a solution
2015/11/23 Report vulnerability to MITRE
2015/12/28 MITRE assigned CVE-ID CVE-2015-8695

Credit:
This vulnerability was discovered by:    wwq

]]>
Panda Security Vulnerability http://xlab.tencent.com/en/2015/12/02/xlab-15-019/ Wed, 02 Dec 2015 09:51:07 +0000 http://xlab.tencent.com/en/?p=33 XLAB ID: XLAB-15-019     

CVE ID: Pending     

Patch Status: Unfixed

Vulnerability Details:

Disclosure Timeline:

2015/09/28 Provide vulnerability detail to Panda Security via secure at pandasecurity.com (No Response)
2015/11/23 Report vulnerability to MITRE

Credit:
This vulnerability was discovered by:    wwq

]]>
Kaspersky Vulnerability http://xlab.tencent.com/en/2015/12/02/xlab-15-018/ Wed, 02 Dec 2015 09:50:20 +0000 http://xlab.tencent.com/en/?p=31 XLAB ID: XLAB-15-018     

CVE ID: CVE-2015-8691     

Patch Status: Unfixed

Vulnerability Details:

Disclosure Timeline:

2015/11/20 Ask for an vulnerability report contact address via info at kaspersky.com (No Response)
2015/11/23 Provide vulnerability detail to MITRE
2015/12/28 MITRE assigned CVE-ID CVE-2015-8691

Credit:
This vulnerability was discovered by:    wwq

]]>