>From: Russ >To: "NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM" >Subject: Re: How to recover private keys for various Microsoft >Date: Thu, 22 Jan 1998 02:19:21 +0200 >[...] >The MS Enhanced CSP ***CANNOT MAKE RC2/40-BIT KEYS!!!***, and domestic and >international versions of NT ***ARE DIFFERENT IN WHAT CSP THEY CAN USE***, so >the claims are outdated and incorrect. Microsoft implement S/MIME in their products. S/MIME has a "must implement" requirement for RC2/40 support (that is, any conformant implementation must be able to generate and process RC2/40-encrypted data). This means one of two things: 1. Russ' claim is correct, and Microsoft have a non-standards-conformant S/MIME implementation. 2. Russ' claim is incorrect. I'll leave it up to readers to sort out which of these two is the more likely. Incidentally, about 30 seconds with the security config dialog will also allow anyone to determine whether the US version does RC2/40 or not. Another way to check is to search the registry for a registry key for RC2/40 (it can be found in, among other places, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ SecurityProviders\SCHANNEL\Ciphers\). In any case this statement by Russ is completely irrelevant. Any of the default Microsoft CSP's (US, non-US, whatever) have the CryptExportKey() security hole and use weak password processing. Arguing over semantics doesn't fix this problem (although it does provide a means to distract readers from the real flaws). >Further, the entire treatise covers Windows '95 only, nothing covered >discusses the differences with Windows NT implementation of the key blob >storage or the CSP. I have no idea where this claim comes from. Not only did I develop and test the entire thing under NT, I don't even have access to a Win95 development system. After I'd implemented and checked everything, I sent it off to someone else running Win95 to make sure the same weaknesses applied there. They do. Windows NT is no more secure than Win'95, and the problems certainly do apply to both NT and '95. >Talking generically about being able to steal keys means people will believe >that every key is equally at risk. Saying that the use of IE with RC2 cipher >means you're exploitable doesn't account for the differences, so is inaccurate >in my opinion. Actually I *specifically* pointed out that the use of RC2 isn't what causes the problem. If you check my original post you'll see that I say that even if people switch to RC2/128 or triple DES, it doesn't provide any more protection. This is what makes the weakness so devastating, it doens't rely on weakened, US-exportable crypto so that even if you use the strongest crypto available you don't get any more protection. >They talk about IE 3.0 as the exploitable platform. Well, IE 3.0 was mostly >deployed by people who downloaded it from the 'net, meaning its likely that >these same people downloaded IE 4.0. Actually I covered both MSIE 3.x and MSIE 4.x. The breakms.c program works with exported key files from both programs (it automatically determines which version it is and attacks the appropriate version). This is specifically mentioned in my posting - I'm beginning to wonder if Russ actually read it before he wrote this stuff. Again, this weakness in both systems is what makes the implications of the attack so scary: MS completely rewrote the key file code between 3.x and 4.x, but both formats are equally weak. >[Lots of mostly irrelevant waffle about trust zones which I don't feel like > picking apart line by line] >The claims should therefor be limited in their scope by these factors, and >that's an important distinction in my opinion. Are they trying to report the >facts, ma'am, or are they trying to make a big splash? Just reporting the facts. >Bottom line is that their claiming that Windows '95 users who use IE 3.0 and >have a cert are at risk of having that cert stolen if someone makes the >whiz-bang ActiveX object in the fashion they describe or gets them to run >arbitrary code on their machine. Wow. This conclusion contains three separate claims (Win95, IE 3 only, requires ActiveX for the attack), of which all are flat wrong. You could get a better average by flipping a coin :-). >From: Russ >To: "NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM" >Subject: Re: How to recover private keys for various Microsoft >Date: Thu, 22 Jan 1998 00:19:39 +0200 >[More stuff about key blobs] >3. This stuff about CryptExportKey() is FUD. You can only call >CryptExportKey() from a Microsoft signed/Commerce ECC approved application. >You can't call any CryptoAPI function (ergo, call into CryptoSPI) directly >without this Microsoft signature (and no, its not the one generated by >SIGN.EXE). Again, this is 100% wrong. I have called CryptExportKey() in test code I wrote under NT, and I'm fairly certain I'm not a Microsoft signed application. Since (as I mentioned above) I don't have easy access to a Win95 system, I checked with someone who does (who is also not a Microsoft signed application) and he had no problems stealing the private key either. As with the strange Win95 claim, I have no idea where Russ is getting this stuff from. Conclusions: A few years ago, the New Zealand Herald (a large daily paper) carried a cartoon which lampooned our defence policy. This pictured a long, empty beach with two flags stuck in the middle, a soldier with a rifle standing between them, and a sign saying "Please invade between the flags". By wishing away 99% of the problem and declaring the remaining 1% to be solved, Russ has also persuaded the bad guys to invade between the flags. If only it were that simple in real life. After all this negativity, I should add one positive note. When I first saw Russ' messages, I had just arrived at a security conference in the US after 36 hours without sleep on various aircraft. I was so steamed up about the fact that I couldn't reply to any of this nonsense for nearly a week that it kept me (reasonably) awake all evening, where otherwise I would have fallen asleep in a corner somewhere. Therefore although Russ' comments provide very little in the way of either accurate or relevant information, they do make a fine substitute for caffeine. Peter.