A privilege escalation flaw in McAfee 's True Key software remains open to exploitation despite multiple attempts to patch Vulnerability-related.PatchVulnerability it . This according to researchers with security shop Exodus Intel , who claim Vulnerability-related.DiscoverVulnerability that CVE-2018-6661 was not fully addressed Vulnerability-related.PatchVulnerability with either of the two patches McAfee released Vulnerability-related.PatchVulnerability for it . The flaw is an elevation of privilege issue in McAfee 's TrueKey password manager . An exploit can be carried out on a guest account by side-loading a specially-crafted DLL into True Key that would then allow for commands and code to be executed with system-level privileges . McAfee 's summary of the flaw , published Vulnerability-related.DiscoverVulnerability on March 30 , lists it as a 'high ' severity issue that was patched Vulnerability-related.PatchVulnerability in version 4.20.110 - which was released Vulnerability-related.PatchVulnerability in April . Exodus says that the April release did n't fully fix Vulnerability-related.PatchVulnerability the bug , however . The researchers explain that McAfee 's patch only addresses Vulnerability-related.PatchVulnerability one of the libraries ( SDKLibAdapter ) that would allow the attack to take place , with another DLL ( NLog logging library ) being left vulnerable Vulnerability-related.DiscoverVulnerability to the same side-loading tactic . `` The patch is incomplete because it overlooks this and hence the nlog.dll can be utilized to allow arbitrary code execution just as the McAfee.TrueKey.SDKLibAdapter.dll could be used in versions prior to the patch , '' Exodus researchers Omar El-Domeiri and Gaurav Baruah said . `` Furthermore , any other McAfee signed binary can be used to exploit the vulnerability as long as the binary depends on a DLL outside the list of known DLLs . '' Exodus said Vulnerability-related.DiscoverVulnerability that it notified Vulnerability-related.DiscoverVulnerability McAfee of the issue back in August , prompting Vulnerability-related.PatchVulnerability a second patch that , unfortunately , also failed to fully remedy Vulnerability-related.PatchVulnerability the issue . `` However , we tested the latest version available ( 5.1.173.1 as of September 7th , 2018 ) and found Vulnerability-related.DiscoverVulnerability that it remains vulnerable Vulnerability-related.DiscoverVulnerability requiring no changes to our exploit . '' To its credit , McAfee acknowledged Vulnerability-related.DiscoverVulnerability the issue and said it is still working to fully resolve Vulnerability-related.PatchVulnerability the flaw . `` McAfee has been working with the researchers to confirm Vulnerability-related.DiscoverVulnerability their findings , and has provided customers mitigation guidance to allow them to protect themselves until the company can address Vulnerability-related.PatchVulnerability the reported issues via automatic product updates , '' McAfee told The Register . In the meantime , McAfee says customers can use the True Key browser extension ( which is not subject to the DLL vulnerability ) rather than the Windows application .

In November 8 , 2016 Microsoft released Vulnerability-related.PatchVulnerability a security update for Windows Authentication Methods ( MS16-137 ) which included 3 CVEs : Talking specifically about CVE-2016-7237 , this fix was applied Vulnerability-related.PatchVulnerability to `` lsasrv.dll '' , which affected the LSASS service . The vulnerability affected Vulnerability-related.DiscoverVulnerability all Windows versions , either 32 or 64 bits , and was reported Vulnerability-related.DiscoverVulnerability and later described Vulnerability-related.DiscoverVulnerability in more detail by Laurent Gaffié ( @ PythonResponder ) the same day that the fix was published Vulnerability-related.PatchVulnerability . He also published proof-of-concept ( PoC ) code triggering the vulnerability . When the LSASS service crashes , the target is automatically restarted after 60 seconds , which is not very nice when it 's a production server . As this allocation is close to 4GB , this will probably fail.If the allocation fails , one of the necessary conditions to reproduce the NULL-Pointer dereference will be reached . There was a misunderstanding here about the vulnerability , because according to the PoC released by Laurent Gaffié , the problem WAS N'T in the structure pointer , but rather in one field of the CRITICAL_SECTION object pointed by this structure , which is NULL when the huge allocation fails ! To be clear , the check of the NULL pointer should probably have been here : Although the public PoC does n't trigger the vulnerability in Windows 8.1 or Windows 10 , the researcher and Microsoft declared these Windows versions as vulnerable . As I said before , the `` NegGetExpectedBufferLength '' function reads the evil size from the SMB packet . Now , this function has to return the 0x90312 value ( SEC_I_CONTINUE_NEEDED ) to produce the fail in the huge allocation . Unfortunately , in the latest Windows versions , an extra check was added in this function which compares the evil size against 0xffff ( 64KB ) . If the evil size is greater , this function wo n't return the 0x90312 value , but rather this will return the 0xC00000BB value ( STATUS_NOT_SUPPORTED ) , which wo n't produce any allocation fail resulting in the vulnerability not being triggered . On the other hand , if we use the evil size with a value less or equal than 0xffff ( 64KB ) , the allocation wo n't fail and again , the vulnerability wo n't be triggered . So , why are Windows 8.1 and Windows 10 vulnerable ? Although the bug is triggered when a memory allocation fails , that does n't mean that the allocation has to be giant , but rather that the LSASS service does n't have enough available memory to allocate . I had been able to confirm Vulnerability-related.DiscoverVulnerability that this vulnerability can be triggered in Windows 7 and 2008 R2 by establishing several SMB connections and sending evil sizes with values like 0x1000000 ( 16 MB ) . The problem is that in the case of the latest Windows versions , it 's not possible to use this kind of sizes , because as I said before , the limit is 64KB . So , the only way to trigger this vulnerability should be by producing a memory exhaustion in the LSASS service . It may be possible to do so by finding a controllable malloc in the LSASS authentication process , creating multiple connections and producing a memory exhaustion until the `` LsapAllocateLsaHeap '' function fails . Maybe , this memory exhaustion condition could be easily reached in local scenarios . I realized that the fix was n't working when I tried to understand why the public PoC was n't working against Windows 10 . It 's surprising to see that nobody else noticed that –that we know of- , and that a considerable amount of Windows users have been unprotected for more than 2 months since the public exploit was released . As of January 10th , Microsoft decided to release Vulnerability-related.PatchVulnerability a new security bulletin including a patch for the affected systems ( MS17-004 ) . If we diff against the latest `` lsasrv.dll '' version ( v6.1.7601.23642 ) , we can see that the vulnerability was fixed Vulnerability-related.PatchVulnerability by changing the '' NegGetExpectedBufferLength '' function . Basically , the same 64KB packet size check used by Windows 8.1 and Windows 10 was now added to the rest of the Windows versions