IE, Chrome, Safari duped by bogus PayPal SSL cert If you use the Internet Explorer, Google Chrome or Apple Safari browsers to conduct PayPal transactions, now would be a good time to switch over to the decidedly more secure Firefox alternative. That's because a hacker on Monday published a counterfeit secure sockets layer certificate that exploits a gaping hole in a Microsoft …
As it is you that has reverted to the childish name calling in support of your misguided view on this issue I suggest it is you that are getting "wound up".
Those browsers that rely on the Microsoft crypto API are vulnerable to this attack.
Those browser that do not rely on the Microsoft crypto API are not vulnerable to this attack.
Logic dictates that Microsoft's crypto API is at fault. Perhaps when MS get around to fixing this and releasing a patch it will sink in.... Microsoft's crypto API is bugged, flawed, broken.
"'E's a stiff! Bereft of life, 'e rests in peace! If you hadn't nailed 'im to the perch 'e'd be pushing up the daisies!
'Is metabolic processes are now 'istory! 'E's off the twig!
'E's kicked the bucket, 'e's shuffled off 'is mortal coil, run down the curtain and joined the bleedin' choir invisibile!!"
Some people just can't see a dead parrot when presented with one.
btw, I use Linux (OpenBSD and Ubuntu) for the serious stuff. XP is my toy operating system, my gaming OS for which it is almost fit for purpose.
It's not a case of being lazy. It's a case that writing crypto APIs is hideously difficult and very few apps would have the time or resources to do it, especially when operating systems such as Linux & Windows usually provide their own implementation or a shared library. As an example of how difficult they are to implement, consider that OpenSSL (uquitous in the Unix world), NSS (in Mozilla), Crypto API and Opera's impl are all roughly ten years old and bugs still occasionally crop up.
App often inherit one crypto API or another because they're calling libs such as libcurl, wininet etc. and indirectly pick up whatever that lib is using. It simply is not feasible or reasonable to expect an app to hop from one API to another at the drop of a hat.
It's also worth remembering that every SSL / TLS implementation has suffered from bugs in the past. Bugs are an accepted and entirely predictable occurrence. What matters most with security software is the frequency of the bugs, the criticality of the bugs from a vulnerability perspective and the how long it takes to resolve those bugs. If Mozilla, Opera or whomever can release patches in a timely fashion with 1/100th the resources of Microsoft, then there is no excuse for Microsoft not doing the same. Especially considering the extreme severity of the issue.
Windows 7 Pro, on which I will play games and work, but never enter confidential info - $320 CAD. I've entered credit card numbers on a Windows computer only once in 5 yrs.
This MacBook Pro, which I do trust but think is way too expensive - $1999. Sadly, neither Linux nor Windows would let me code iPhone apps and I needed a new laptop.
Chuckling out loud at Neal5's "informed" opinion - priceless.
Dude, get a clue, from somewhere, they're cheap. MS publishes an OS level API meant to provide crypto/authentication services to apps, as part of the platform. It is broken. Sure, browsers could code their own stuff, but usually the first rule of security is to leverage the work of folks who are presumably better suited to write security code. You would expect at least a security submodule to be well-written, wouldn't you? Not with trivial bugs? Failing that, you would expect it to be patched promptly, wouldn't you? This above your head? Should I type more slowly?
Usually, I sit on the fence on the MS hating folks. There's plenty I don't like with MS, but anti-MS feeling is often quasi-hysterical (Nix & Mac fanbois). In this case though, MS is being just plain sloppy. The only good thing is that it seems the vulnerability requires both the MS bug _and_ a sloppily issued cert which can't be created out of thin air by the hackers.
Would have liked the article to be clearer on that point - can somebody write their own spoofed cert here, or do they _have_ to gull some cert authority, which would be a bottleneck? Couldn't tell from the linked article.
I am in search of more information. I have read the Moxie Marlinspike article. I did see some of the other exploits demonstrated by SSL-Sniff first hand, but am yet to see where this exploit exists in the timeline of Windows + CAPI enabled applications, browsers, email, custom, etc.
Has this vulerability been documented in Microsoft's crypto API? Has there been a test matrix of the various versions of windows, current offerings, and those still in the wild, paired with the posibilities of browser+OS pairings which demonstrate the the "C-String" flaw in Capi?
Please someone educate me on documented cases of this exploit in windows CAPI + CAPI reliant applications.
Thank you in advance.
Gordon~
This bug in the CryptoAPI also means:
a) It's not just browsers affected. Anything than connects over SSL/TLS, e.g. chat clients, mail clients, etc. Harder to exploit, though a poisoned DNS cache would do it.
b) Valid certs for international domains (e.g. ümlaut.com ) in the future will probably then be incorrectly identified as invalid - as I imagine the string containing the domain name will be UTF-8 encoded.
As someone earlier mentioned, it's an ASN.1 string. It would be trivial to verify that the length of the string indeed matches what was specified. Slack programming at the best of times, but in a crypto lib, unforgivable.
I code a little and with my admittedly fairly minor knowledge I think some comments are a little unfair, what sounds like a quite simple thing to fix can often have bizare and unexpected consequence and it can take some time to check that the fix is implemented correctly and will not affect anything else or any programs that rely on the current data handling
also surely most people on here are capable of understanding that if it was really that quick and simple MS would fix it as they are no more keen that the users are to see it stay unfixed as it does not exactly do any favoiurs for their reputation .
it also doesn't exactly help when users insist on buy their viagra from those nice friendly people who emailed them out of the blue...
regarding>> I am in search of more information.
This issue is confirmed.
I am not able to generate a request with a null character prefix CN using Microsoft's CAPI (via CertEnroll API),
Unfortunately I am able to reproduce this quite easily by creating a certificate with other widely used crypto API's.
When I view the cert which I generated in a recent supported version of windows I can confirm the issue is still present.
"Crypto Shell Extentions" which uses MS CAPI API's allows me to see the certificate's subject as only the portion before the null.
In my opinion CAPI's handing of directory strings using CString V.S. AS1 DERPrintableString is broken.
While CAPI is smart enought to not let us generate a signing request with broken RDN components, certificate subject validation + display is indeed broken.
This is not good.
~Gordo
Dude, are you just trolling or are you really not understanding the issue?
Have you actually worked with SSL?
FQDN checking is done at the CryptoAPI's level, *not* the browser level. SSL connections are usually initiated with some open_connection("blah.site.com", 443); call, and the Crypto Provider does the rest. It is that API the one wrongly validating the null-prefixed certs. This is basic validation, the kind you learn in basic programming courses!!
Of course, the CAs should also be at fault, as they were stupid enough to sign a cert like this; however, these certs shouldn't be passing through something as sensitive as the SSL FQDN check!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
