Null-Prefix SSL Certificate For PayPal Released
An anonymous reader writes "Nine weeks after Moxie Marlinspike presented at Defcon 17, null-prefix certificates that exploit the SSL certificate vulnerability are beginning to appear. Yesterday, someone posted a null-prefix certificate for www.paypal.com on the full-disclosure mailing list. In conjunction with sslsniff, this certificate can be used to intercept communication to PayPal from all clients using the Windows Crypto API, for which a patch is still not available. This includes IE, Chrome, and Safari on Windows. What's worse, because of the OCSP attack that Moxie also presented at Defcon, this certificate cannot be revoked." Update: 10/06 23:19 GMT by KD: Now it seems that PayPal has suspended Marlinspike's account.
a bug or a feature?
With CNs like www.paypal.com\0ssl.secureconnection.cc
Shouldn't the CA who issued the certificate bear *some* of the blame here?
It just seems logical....
But it's pretty clear who's responsibility it is. Microsoft needs to update the Windows Crypto API. Mozilla products are already patched.
Don't be silly. Windows 7 will be out on Oct 22nd. Just as with the TCP/IP vulnerability, the fix from Microsoft will only be to recommend upgrading to Vista or Windows 7. This couldn't have been timed better if they had planned it.
For more information about null-prefix attacks, the video is here.
The people who need to make sure to get everything secure in order to for the web to function have waited longer than -9 weeks- to get something fixed? When the thing was presented at... Defcon? What else do these people have to do other than fix these -major- flaws. When something is shown at Defcon, BlackHat, HOPE or any other major security conference, the first thing for these people to do would be to fix the flaw. 9 weeks is inexcusable.
The problem is that this is not just some buffer overflow where you can replace single function call with an equivalent function call that does a safety length check. Security holes that depend on '\0' characters in strings exploit a systematic flaw in the Windows API design: the mix of two entirely different and incompatible types of strings all over the place. The 'native NT' API uses Unicode strings with an explicit length, but the Win32 API and C/C++ libraries usually use null-terminated strings. The dirty compromise is to use null-terminated strings together with an explicit length. Naively, one would think that this is now compatible with both, but it isn't - the NT API strings are a superset of the C-style API strings, because they can contain \0 characters, which the latter cannot handle.
This is a glaring flaw, has been known for many years, and will probably never get completely fixed. The SysInternals guys wrote a nice article about it once, I think, but I can't find it any more. It's lost in the mists of time. It's been exploited repeatedly too. You can create files and registry entries with \0 in them, and then none of the user-mode tools will be able to modify or delete those, including Explorer and the command-line tools. Viruses and other malware make use of this 'feature' often.
What really shits me is that Microsoft hasn't learned a thing. They talk big about security, but it's just talk. For example, the entire ASP.NET API suffers from a similar mismatch of encodings flaw: All of the data binding controls fail to properly HTML encode strings coming from a database. This makes virtually all ASP.NET applications ripe for exploits via XSS or other script injection attacks. The one time I wrote an ASP.NET app, I had to spend weeks going through and replacing all of the simple-looking bind statements with explicit calls to a method that would both bind and encode. Even in the upcoming 4.0 release, the flaw is still there. I suspect that it won't ever get fixed.
If Microsoft can sit on a related security holes for years, don't hold your breath for a patch for this one. Even if they do fix it, I suspect they'll do something half-assed, like create a patch for IE only, instead of the cryptographic subsystem as a whole.
NO! Don't roll your own crypto. This is madness!
I'd never do that.
OpenSSL is available for windows; use that.
->
go for a third party library. (perhaps open source)
The rewrite it bit was actually referring to automatic updates and XML parsing. Those are pretty easy to implement properly in an app, without depending on Microsoft-coded services.
Apparently I'm 80% overrated, but that's also why a single exploit can affect so much software. Rather than using a third party lib, most devs just use whatever you stick in front of them. :/
But is it really 2012 in 3 years? I mean, the romans and the catholics messed up the calendar so many times... maybe we're really in the year 1809 for all we know.
I have never understood that for years, you have been able to create a folder with a space at the end of its name in a script. Try, just try, to delete that folder.. You can't create it in explorer, you can't delete it in explorer.. in fact, the only way to fix that I have found, is hope to god its a long file name, drop to a command prompt, and delete it with "Del folder~1"
Years and years...
Speaking of which, I got to try that in server 2008, and Windows 7.. Its a fun way to use 3 lines of script to really piss off your IT co-workers...
What are we going to do tonight Brain?
paypal.com uses EV cert. Original site shows green location bar.
Did anyone else read the stuff this kid has on his site? Moxie is a Sailor/Hacker/Anarchist/Squatter/Hitchhiker enigma. Holy shit this kid has sailed the CA coast in the worst conditions alone. I am duly impressed and green with envy and depressed that I am not living a life like his.
I had a sig, but
Wow.
"not technically feasible" to patch at least XP 64 bit which was release after 2003 32-bit server and before 2003 server 64-bit. I thought the code base was really similar. Especially since it uses the same Service Pack (WindowsServer2003.WindowsXP-KB914961-SP2-x64-ENU.exe)
General Availability Dates from Microsoft
Windows Server 2003, Standard Edition (32-bit x86) 5/28/2003
Windows XP Professional x64 Edition 4/24/2005
Windows Server 2003, Standard x64 Edition 5/28/2005
This cannot be anything less than a ploy to kill XP (and 2000 server) and bring on the new era of Windows Play Skool Edition (Windows Visa 2009 aka Windows 7)
Who will guard the guards?
Ubuntu aside, how could you know? Do you maintain a whitelist of everything running on your PC? Do you scan for rootkits *outside your OS*? Do you maintain a list of MD5 hashes for every binary?
Surely what you mean is that you've *never known* you had an infection.