IE and Konqueror Bug Makes SSL Insecure

Spad writes "The Register reports that IE and Konqueror both have a bug that allows anyone with a legit Verisign SSL certificate to issue a 'legit' certificate for a 3rd party site. IE and Konqueror don't both to check the issuer of this intermediate cert making SSL in both browsers something of a joke". Update by Hetz: if you're using KDE from CVS, the fix is inside or you can wait to next week for KDE 3.0.3 (which will have more fixes for KDE 3.0). Thanks to Waldo bastian for the blazing fast fix (95 minutes since it was reported).

Re:What about Mozilla

[baldass_newbie]

From the article:
"Mozilla was not vulnerable, but I'm not sure if that's because it handled the situation properly, or is, ironically, somehow too buggy to be exploited."

I don't know if that's exactly a show of support. It goes into more depth if you'd bother to read the article.

Re:What about Mozilla

[CptNoSkill]

No, if (shock) you had read the article, you would have seen that Mozilla (.94) is working fine and does not suffer from this problem. It has yet (IIRC) to be tested on newer versions, but they should still be fine...

Re:Huh?

[sporty]

Let's say I go to verisign and get a certificate for encryption, which also garantees my identity. With in the cert, is my information, encryption information, where the cert came from and who issued the cert. I can use my cert to generate other certs using encryption software.

What this means, for people who have browsers which don't check where the cert came from, will not be warned that a certificate was granted from an untrusted source. Who are trusted sources? AOL, Thawte, Verisign.. etc.. Look in browser prefs for certificate authorities; the trusted circle of people to say you are who you are.

Why is this dangerous? Well, for one, you can claim you are whomever you wish, while looking like you are from this trusted circle. You look like you are from this trusted circle because no one claims otherwise. Your browser would usually bitch at you about certs made from non-authorities. But since your browser won't bitch about where your cert came from, and just looks at the authority..

So what if it isn't from a trusted circle? Using this in combination with dns spooofing, you could get people to give you information over ssl "secure connection" (rolling eyes) without the browser bitching at you that the cert you are looking at was made by verisign but not issued by verisign.

testing Moz 0.9.4 doesn't qualify as a test

[ChrisCampbell47]

Testing Moz 0.9.4 doesn't qualify as a test. Nor does slagging 0.9.4 bugs qualify as slagging Mozilla.

Somebody please turn this guy onto Mozilla 1.0!

Re:Spoof?

[gmack]

Don't be so sure about that. For the longest time windows allowed javascript to edit c:\windows\hosts (has the same affect)

Also the entire *point* of SSL certs is to make this sort of thing impossible. It should have popped up a warning telling the user that it wasn't the real certificate.

Check the SecurityFocus thread about this here

[Otis_INF]

http://online.securityfocus.com/archive/1/286893/2 002-08-05/2002-08-11/1 [securityfocus.com] (opens in new window).

It seems that it isn't TOTALLY browser related. Verisign and Microsoft both know about this error, according to the people in the thread. It's a good read with a lot of detailed info about the flaw and where the flaw exactly is.

Re:Incident response? Let the race begin!

[Chunky-Spinach]

09:08

According to #kde on openproject.net, an uncommitted fix already exists for Konqueror. I'm sure more details will be posted when it has been tested and committed.

Re:What about Mozilla

[Jucius Maximus]

"Has anybody tried this with 1.0 or 1.1?"

I've had Moz 1.1 complain about certificates where the cert company was inconsistent with the issuer.

if you install kde-bindings ...

[dlasley]

if you install kde-bindings for konqueror when you install KDE then it uses the mozilla engine to render HTML/CSS/JavaScript etc. when you surf. however, i don't believe installing kde-bindings exempts konqueror from this problem - Security is handled in a separate module within the Control Center. anyone know otherwise?

Re:Heh

[jlv]

I read the whole article. His writing is atrocious. It doesnt't take much to be a "journalist" these days.

'nother link

[Draoi]

.. to a buried page on the guy's own site [thoughtcrime.org]. This shows a little more detail on how to get a test setup running.

Try it yourself right now ... here is what I saw:

[wherley]

If you hit the discoverer's web site [thoughtcrime.org] using Mozilla 1.1b you get an -8183 error and it
will not display the page. Note this is not a complete spoofed-site demo unless you trick your DNS resolver into reporting his IP for www.amazon.com and pull up his page using SSL with that URL.

I would infer that Mozilla is correctly detecting the mistake in the certificate chain.

Notes on another practical demonstration of this bug are here [ipsec.pl].

Interesting resonance

[wiredog]

With this article [theatlantic.com] from the Atlantic Monthly about Bruce Schneier and bad security.

Re:Huh?

[BlueUnderwear]

Still, with checking in place, I can just go to verisign, get me a cert.

You'll get an "end-entity" certificate earmarked for your own website (you have to prove you're in charge of the URL that you are getting a certificate for). The certificate won't work on other sites (because the browser compares the site's URL with the URL embedded in the certificate),...

Start producing certs

... nor can it be use to produce other certificates. Indeed, a non-buggy browser only accepts certificates with the "CA basic constraint" set to true for creating other certificates. And the CA won't hand out any such certificates, except to other reputable CA's.

Re:Spoof?

[ceswiedler]

By the way, I've performed full man-in-the-middle with a real bank
involved and myselft as victim. It's easy and works perfectly, so I've put
a brief description and screenshots at http://arch.ipsec.pl/inteligo.html
Details on programs' setup and fake certificate generation are omitted
not to provide script-kiddies with a ready recipe.

Actually, you can use Mike's https://www.thoughtcrime.org/ as demo
site but you first need to DNS spoof your browser into thinking
that www.amazon.com has address of 66.93.78.63, which is easy using
dnsspoof from dsniff for example.

From the SecurityFocus thread referenced in another post.

Re:Opera?

[bmfs]

Just tried it (opera 6.02/Linux) and it complains... asks whether you want to accept this dodgy certificate and gives you lots of info. So no, it's not vulnerable.

Re:Huh?

[Anonymous Coward]

His request for the translation of the last sentence was NOT because he didn't read the article, fucktard. It was due to "bother" being mis-typed as "both":

"and Konqueror don't both to check

His post was simply a less direct method of the time-honored tradition of pointing out the horrendous spelling and editing to be found on a daily basis on Slashdot.

Re:It hardly makes SSL a "joke"

[anthony_dipierro]

About 99.999%+ of the primary uses of SSL/TLS out there are for transport encryption, not for site authentity verification, and this does nothing to reduce the security of the transport encryption.

Umm. No. You are wrong. If you don't authenticate the person you are talking to, then you are vulnerable to a man-in-the-middle attack and the security of the transport encryption is nil.

Re:Try it yourself right now ... here is what I sa

[MikeBenham]

That URL alone isn't a full demonstration. Your browser notified you of a problem because it thought the web site was www.amazon.com, and you typed in www.thoughtcrime.org. You have to edit your hosts file:
66.93.78.63 www.amazon.com

For the full effect.

Re:Take that B of A!

[TeddyR]

One bank security official once told me unofficially wrt that is that the bank does not like the fact that the source is availible. To them, this means that anyone can compile the browser and "take out" some of the features that make the browser secure. Or trojan it to make an SSL connection, get the username/password, and dump it to a text file or send it remotely.

With the older closed browsers there is supposedly a much smaller chance of that happening.

Try Opera... Some of them disallow NS6, but allow opera...

Re:Try it yourself right now ... here is what I sa

[karmawarrior]

Wrong error. The bug here is not that a website is saying it's X when in fact it's Y, it's saying that it's X and saying Z has said it's X and Z hasn't. So I assume what's happened is you typed in "thoughtcrime.org" into your browser, it identified itself as "amazon.com" and you got the error you're describing.

Now, do the spoof as he suggests. Edit your hosts file so that www.amazon.com has www.thoughtcrime.org's IP address, ie put in the line: 66.93.78.63 www.amazon.com into your hosts file. Where that file is depends on your system; in Unix it's in /etc, in Windows 9x it's in C:\WINDOWS (or whatever %WINDIR% is), in Windows NT it's something like C:\WINNT\System32\Drivers\etc. It's a plain text file. To confirm you've set it up right, type "ping www.amazon.com" afterwards, if it's pinging 66.93.78.63 then you're all set.

Now open your browser, and go to https://www.amazon.com/. If you don't get an error, your browser is vulnerable.

Re:Try it yourself right now ... here is what I sa

[Melantha_Bacchae]

I tried the thoughtcrime.org test with the browsers I keep around under OS X. Here are my results:

Mozilla 1.0: passed (the others are right, the error message could be more user friendly, but it worked)

Chimera 0.4.0: failed (no SSL options in Preferences, also an early version without many features)

Omniweb 4.1 (v422): failed (SSL options in Preferences)

iCab Preview 2.8.1: failed (no SSL options in Preferences)

By "failed", I mean displayed the web page with no error messages (which I presume is the test). Some of those that failed don't appear to provide SSL support in the first place.

OmniWeb doesn't have much excuse though, it appears to have SSL support, and it is not a beta.

It's beginning to look like Mozilla is the only one on the ball here.

"What I'm thinking is different from what you are."
Belabera, "Mothra 3" 1998

Re:testing Moz 0.9.4 doesn't qualify as a test

[Fjord]

Not to mention that IE5 and IE5.5 have had several security updates. While they aren't the most recent version of the software, they are still supported products. Not to mention the fact that IE5.5 is the highest browser a Windows 95 user can and will ever be allowed to use (the reason why our web application supports IE5.5, many corporate customers in our domain haven't moved from 95).

Fix is in KDE CVS

[Parys]

According to the recent email to the kde-devel mail list [kde.org], the fix for the SSL vulnerability is in KDE CVS and the stable KDE 3.0.x branch and will be part of the 3.0.3 release next week.

Re:Well I see /. says a "fix" is available now...

[HeUnique]

Well, the issue has been known to Waldo Bastian for the last 2 days and he fixed in on both KDE HEAD and KDE 3.0.x branch, and he's now fixing the KDE 2.2.2 branch (for people who preffer to stay with KDE 2.2.x yet).

The patch HAS been tested in the last 2 days, but it took 95 minutes to post a fix since the story was released..

Thanks,

Issue a fix in 95 minutes

[Anonymous Coward]

And then wonder how long it will take Microsoft?
I hope Microsoft puts it through some sort of testing and Q/A process. 95 minutes to fix a serious security hole is stupid. You point out a problem with open source, lack of Q/A & testing, and hold it up like it is an advantage.
But then again, it took Mozilla how many years to but out the buggiest browser ever?