SoylentNews is people
SoylentNews
Windows 10: NSA reveals major flaw in Microsoft's code:
The US National Security Agency (NSA) has revealed a major flaw in Windows 10 that could have been used by hackers to create malicious software that looked legitimate.
Microsoft is expected to issue a patch later and to say that the bug has not been exploited by hackers.
The issue was revealed during an NSA press conference.
It was not clear how long it had known about it before revealing it to Microsoft.
Brian Krebs, the security expert who first reported the revelation[*], said the software giant had already sent the patch to branches of the US military and other high-level users. It was, he wrote, "extraordinarily scary".
The problem exists in a core component of Windows known as crypt32.dll, a program that allows software developers to access various functions, such as digital certificates which are used to sign software.
It could, in theory, have allowed a hacker to pass off a piece of malicious software as being entirely legitimate.
[*] Cryptic Rumblings Ahead of First 2020 Patch Tuesday.
https://kb.cert.org/vuls/id/849224/
The Microsoft Windows CryptoAPI, which is provided by Crypt32.dll, fails to validate ECC [Elliptic Curve Cryptography] certificates in a way that properly leverages the protections that ECC cryptography should provide. As a result, an attacker may be able to craft a certificate that appears to have the ability to be traced to a trusted root certificate authority.
Any software, including third-party non-Microsoft software, that relies on the Windows CertGetCertificateChain() function to determine if an X.509 certificate can be traced to a trusted root CA may incorrectly determine the trustworthiness of a certificate chain.
(Score: 4, Interesting) by canopic jug on Wednesday January 15 2020, @08:30AM (6 children)
What are the actual dates between original discovery and now? The date on which the exploit becomes known is not necessarily the same as the date the vendor is notified. Furthermore, the date on which the vendor issues a patch is not necessarily the same date it is notified.
I bet it was known to and used by the NSA a long time and that they gave up this exploit only because other countries were starting to abuse it too. For all we know the exploit could have been known to and in use by the NSA since the beginning. Neither the Kreb's post nor the BBC article shine light on this. Each year the mitigation of M$ security holes becomes more opaque despite them being large enough to drive a semi through.
Money is not free speech. Elections should not be auctions.
(Score: 3, Informative) by maxwell demon on Wednesday January 15 2020, @08:39AM (4 children)
Of course not. Unless either the fix is trivial or the vendor had known it before and decided to sit on it, it will definitely take time to develop the patch.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by canopic jug on Wednesday January 15 2020, @08:54AM (3 children)
M$ usually takes months to years to develop a patch, as its past record shows. Using the same record it is shown that they usually need two or three tries to get the patch to work and to make patches for the bugs that the patch itself introduces. I notice that mitigations are no longer announced either. Without either mitigations or actual working patches, the window of opportunity for those exploiting Windows users must have been quite long.
There are very few details even in the CVE so this one must have been quite good.
Money is not free speech. Elections should not be auctions.
(Score: 0) by Anonymous Coward on Wednesday January 15 2020, @09:21AM
CVEs like this are usually kept mostly secret until a majority of the user base is patched in an attempt to slow reverse engineering. I'd expect to see more details in a week or two. If not, someone (or twenty) will beat them to the punch by doing a binary analysis of the patch and comparing it to the previous version of the library on their blog.
(Score: 3, Insightful) by DannyB on Wednesday January 15 2020, @04:00PM (1 child)
<no-sarcasm>
Theory:
NSA had already weaponized this. AND understood exactly how to fix it. Time passes . . .
Suddenly, NSA discovers this is out in the open and about to be used against us, so it pretends to be the good guy and hands this to Microsoft along with information on how to immediately fix it.
</no-sarcasm>
The lower I set my standards the more accomplishments I have.
(Score: 0) by Anonymous Coward on Wednesday January 15 2020, @07:43PM
i assume this is standard operating procedure.
(Score: 0) by Anonymous Coward on Friday January 17 2020, @09:53AM
Once a disclosure is given go and look for the first version of crypt32.dll to include ECC support. Try the proof of concept on it, see if it works and follow the codepaths to see if the correct function call order is done. If it is not or looks suspect, disassemble or use ghidra/IDA Pro to decompile and look at the logic and code flow.
Rinse and repeat for each major release RTM to check if certain versions are found (in)secure.
In all likelyhood I assume this has been around since the beginning which is why I simply disabled the certficiate manager and only turned it on when i had to install software. That killed most software installs for 'trusted' software until I checked the certs and in some cases manually installed them.