Discussion in 'other security issues & news' started by ronjor, May 16, 2008.
Alarming Open-Source Security Holes
Don't shoot the messenger as I don't really understand the implications here.
That's what I always recommend using /dev/random or /dev/urandom when creating keys.
Re: Alarming Open-Source Security Holes
Pretty serious bug. For servers note, not desktop.
Discussion on Debian forums. Good discussion and good links in there.
I won't shoot the messenger, and the first messenger was the Debian project.
It seems that a developer used an automated tool to look for bugs, and found one that wasn't a bug, it was a feature to generate random numbers.
Justin Troutman around?
Although it was discussed with OpenSSL developers (probably light discussion..), the "patch" wasn't provided.
Clearly something is wrong with this process, since on the patch the developer would catch the problem.
Perhaps something has to change in Debian.
These two updates just in this am. Hopefully they properly address the vulnerability.
I think it blacklists bad keys, and you have to create new ones.
If you don't use a server, but access one, i believe it's wise to change passwords.
Not sure, most of this is beyond me.
This mainly affects server to server communications. Although this can be problematic for clients:
The DNS master servers cannot be sure they allow transfer to valid slaves.
The DNS servers are at risk of being controlled by bogus rndc.
Encrypted VPN sessions might be listened on.
And so forth.
CA certificates could be forged.
And so forth.
But like I said earlier, always, always use the -r /dev/random or -r /dev/unradom when creating the keys. This would force the system to use the random device (rather than ignoring it - this is the bug, a simple comment).
I'll certainly take your word for it, Mrk, as it's also way beyond me anyways. Personally, I was not too concerned about it.
As a relative Linux newbie, does this mean I should forego stuff like
online banking ? I only have client installed.
Well, if you are accessing your website the usual way, no reason not to do banking. It's still your bank.
But here's a scenario for you. Because the bank has a weak encryption, someone could brute force the hash and thus detect ther server certificate used by the bank.
Then, that someone could create a bogus bank site and use the same certificate on his own site. And the anti-phishing whatever wouldn't work here, because you'd seemingly have a digitially signed, reputable certificate vouching the authenticity of the site.
The threats are implicit. Existing sites / servers will have a difficult time establishing the authenticity of their peers. And clients will have a hard time establishing the authenticity of certain servers.
It's NOT that your bank site is hacked or something like that. It's just that someone going there for the first time will not be able to so easily distinguish from a real site.
But this is a problem even without any encryption keys bugs! Social engineering!
Further still, the main problem ARE not HUMAN clients. People can always use brains, check the site, phone the bank etc.
The problem is with the servers. Servers automatically update their peers, exchange info etc. This is a process where there are no men doing the thinking. It's all about shared secret keys. The 256-bit hash ok? Go on! As simple as that.
Hope this clarifies the issue.
Thank you for the explanation Mrk. I'm glad Ocky asked this question. One thing, if a bogus bank site is created, is it easy enough avoiding that bogus site by typing in the exact ip address of the legit bank site, and is it only normally phishing attempts in email, for example, where forged links to the bogus site, hoping the recipient will click on it are the most common ways of tricking people into accessing those bogus sites? In other words, as long as a person uses common sense when accessing their banking sites, it should be relatively safe?
As long as you THINK whenever you do anything, you should be safe.
Thank you for the detailed explanation Mrk. Let's all hope that this flaw
will be repaired soonest.
I don't know about other banks, but mine (one of largest in Canada) juggles their IP's around frequently (within their block of addys) to, hopefully, get around what they see as fixed-IP security problems. And under the circumstances, I doubt if there's any redirect if you're not current. DNS-server headaches, naturally, but they do guarantee reimbursement if you're victimized by phishing or other online fraud.
Thanks Mike and Mrk. Yeah, my bank (RBC) has recent security measures in place, one of which is they won't allow online access from a different pc, unless secret questions are answered correctly. It's also good to know about the reimbursment if DNS issues occur.
For Firefox users an extension called SSL Blacklist is available which alerts you if a site uses a bad certificate. A similar functionality offers the heise SSL Guardian, a tool for Windows 2000/XP/Vista.
I only have openssh-client enabled on Ubuntu 8.04LTS i.e. am not running a
server and hence have not created any keys etc.
Would it nevertheless be advisable for me to enable openssh-blacklist, which
contains a list of bad keys for ssh-vulnkeys to use when checking keys ?
I really have no idea and will be glad of some advice.
You may find an answer here, particularly in chapter 5.
Thanks tlu for pointing me to that site, you are always of great help
"Many weak web server certificates threaten online shopping"
A warning for a site using a bad SSL certificate looks like this:
Great stuff !
I have installed both the heise ssl guardian (Windows XP SP2) and the
SSL Blacklist FF ext. (Ubuntu Hardy - openssl-blacklist is installed).
A 'sudo ssh-vulnkey -a' shows nothing but that's because no certificates
were installed by me I suppose.
Question: I don't know which Linux distro you use, but in the Ubuntu
repositories there is an additional openssl-blacklist package,
viz. openssl-blacklist extra ("a custom list of non-default openssl keys...")
also @ 12.5 MB.
Would you deem it necessary to additionally install this list as well, or will
SSL Blacklist ext. for FF only check against openssl-blacklist ?
Also the site mentions a 31 MB download, which I didn't opt to do as the
openssl-blacklist package was already installed, but why do you think my
installed package is only 12.5 MB ? - is it short some of the blacklisted
certificates that the 31 MB download would provide ?
Thanks for the research you have done.
I use (K)Ubuntu 8.04. The 'extra' package contains the suspect RSA-512 and RSA-4096 keys. Quite frankly, I don't know why it wasn't installed by default - I did it to be on the safe side.
Yes, I also wondered - that's why I contacted the SSL Blacklist author and will inform you about his answer.
BTW: I executed 'sudo openssl-vulnkey /etc/ssl/certs/*.pem' and found one compromised key and several keys with "Unsupported exponent". I have yet to research what that means.
EDIT: Are you aware of http://www.ubuntu.com/usn ? There you can find the Ubuntu security notices.
I followed suit and also installed the openssl-blacklist extra package. With only
the openssl-blacklist everything was 'Not Blacklisted'.
After installing the extra package I have: 1xKey has Unknown validity;
2x Unsupported exponent, and 1xCompromised (snakeoil.pem ??)
I have just reinstalled Gutsy for my wife (8.04 caused power management
problems with her laptop), and with only openssl-blacklist installed, the only
entry that comes up is the aforementioned "snakeoil" certificate -but Not
Blacklisted (and with different fingerprint).
Looks like everyone has this certificate and whether it is compromised seems to depend on a given
public key algorithm and associated fingerprints. The openssl-blacklist
package obviously didn't include the ones 'found' when also using the 'extra'
pkg. All very confusing.
Separate names with a comma.