Two-factor authentication would help. It works pretty well for Google accounts. iCloud has had it too as of last year.
Well it protects you as in, knowing only your password isn't sufficient to get in. But it doesn't guarantee that your password can be stolen if the web service is vulnerable to heartbleed.
But yeah it definitely made sure that even if your password was leaked it didn't jeopardize your personal information. I use it on all services that offer it.
Windows is not affected by this bug either, as it does not use OpenSSL.
I think this whole thing is a great example of how the assertions made by open source advocates are based on little more than blind faith.
Specifically, there are two blind faith assumptions here:
1. people who contribute to open source projects are altruistic
2. bugs and security flaws are more likely to be spotted if there are thousands of eyes reviewing the code
What we find in practice, however, is:
1. there are many people who are not altruistic -- in fact some that are downright sneaky and malevolent. Giving those people unfettered access to vitally important code might not be a good idea.
2. the MEGO phenomenon is not ameliorated by the magic of open source.
I think this whole thing is a great example of how the assertions made by open source advocates are based on little more than blind faith.
Specifically, there are two blind faith assumptions here:
1. people who contribute to open source projects are altruistic
2. bugs and security flaws are more likely to be spotted if there are thousands of eyes reviewing the code
What we find in practice, however, is:
1. there are many people who are not altruistic -- in fact some that are downright sneaky and malevolent. Giving those people unfettered access to vitally important code might not be a good idea.
2. the MEGO phenomenon is not ameliorated by the magic of open source.
Maybe proprietary code isn't so bad after all...
1. I think it's fair to say that most people who contribute to open source projects do so either out of pure love of coding or are paid to do so by a company, such as Redhat or Intel, which has a direct interest in the project. Even though anyone can play with the source code, it's only a few trusted developers that actually have commit access.
2. The assumption here is that making the code public will let larger numbers of qualified individuals review and debug the code. Whether that's true in practice depends on the project. It's probably true for large projects like Linux which are backed by major companies. This OpenSSL bug was discovered by Codenomicon and Google Security, neither of which are the primary developers of OpenSSL. Although they probably used various tools to detect that something was amiss in the first place, having the source code available to debug with likely made it easier to pinpoint the flaw in the code and expedite the patching process.
Apple says iOS, OS X and certain Web services protected against 'Heartbleed'
Why is the headline making a claim that Apple's operating systems are "protected against" Heartbleed? They have no protections against it whatsoever, and a quick glace at the headline and article would create a false sense of security. Apple's software did not incorporate the affected OpenSSL implementation, but some third-party software on those platforms are affected such as BlackBerry Mobile for iOS.
It seems like they didn't sanitize a value that came from the network. If there was a naming convention for untrusted/unsanitized variables the compiler could warn upon their use in memcpy, etc. Naming conventions was how Apple was able to implement largely automated memory management.
I'm certainly not a security expert but I have spent the better part of two days learning and checking all of our servers against https://www.ssllabs.com/ssltest/index.html to help our lame IT department, You'll need to go into considerable detail to refute my original comments. I don't think you have researched this as much as I have, I can be corrected, but you'll need to cite authoritative sites.
I provided a link to code that shows that some clients are vulnerable that you ignored. Exactly what more do you need as proof?
Just google heartbleed and wget. Which someone helping their lame IT department should be sufficiently skilled to do.
And playing the "I'm an expert" card (or the even lamer passive aggressive "I'm not an expert" card) gets you butkus on the internet.
And here Mr. "I'm not an expert but I researched this more than you" another link:
The thread has a bunch of links to client vulnerabilities.
So IF you have downloaded OpenSSL via MacPorts (or other source) you ARE vulnerable to a heartbleed attack if your unpatched client hits a malicious server. And the likelihood that you are using such a client is much higher IF you are using MacPorts at all.
Same deal for windows users that use Cygwin.
Quote:
Clients are vulnerable but only if they are connecting to a compromised server.
Right. And there has never been a compromised server on the internet. The whole point is that if you have a client using openSSL there is a vulnerability to steal memory if there is a malicious server using this exploit against you.
Therefore your statement: "So in that sense, the other poster is correct because unless you are serving connections to SSL suites then there is no attack possible." is categorically wrong.
IF YOU HAVE OPENSSL VIA MACPORTS YOU SHOULD UPDATE IT.
The client side vulnerability needs you to initiate the contact to a malicious server but that's the normal use case for many of these vulnerable clients (i.e. if you use them at all, it's to talk to servers).
Why is the headline making a claim that Apple's operating systems are "protected against" Heartbleed? They have no protections against it whatsoever,and a quick glace at the headline and article would create a false sense of security. Apple's software did not incorporate the affected OpenSSL implementation, but some third-party software on those platforms are affected such as BlackBerry Mobile for iOS.
Certain apps on iOS are infected but that would mean they took the strange step of not using Apple's crypto code/p>
So if "key" web services were not affected does that mean that some non-key services were? If so I'd love to know which ones!
As always with Apple you have to read between the lines because all their public messaging is scripted to within an inch of its life. Apple realises that it's worked hard to gain the trust it has and it'd be hard to win back if lost so they don't want to say anything that could come back and bite them later.
So if "key" web services were not affected does that mean that some non-key services were? If so I'd love to know which ones!
As always with Apple you have to read between the lines because all their public messaging is scripted to within an inch of its life. Apple realises that it's worked hard to gain the trust it has and it'd be hard to win back if lost so they don't want to say anything that could come back and bite them later.
Apple's own API are not affected. That's what they mean. But OpenSSL is available and can be used by certain apps.
" src="http://forums-files.appleinsider.com/images/smilies//lol.gif" />" src="http://forums-files.appleinsider.com/images/smilies//lol.gif" />" src="http://forums-files.appleinsider.com/images/smilies//lol.gif" /> considering that Apple doesn't even use their own "server" hardware or OS in their data centers.
So? The claim was that they don't have a server product. They do. That it isn't particularly popular is besides the point. They have one and it doesn't use OpenSSL.
It is but pretty much no one uses it anymore, most who still are on 4.1 are on 4.1.2 which isn't affected. It's really only 4.1.1
Google send out a fix to the OEM's for the few devices affected.
It is but pretty much no one uses it anymore, most who still are on 4.1 are on 4.1.2 which isn't affected. It's really only 4.1.1
Google send out a fix to the OEM's for the few devices affected.
It's unfortunate that some of those OEM's won't be motivated to offer it.
It's unfortunate that some of those OEM's won't be motivated to offer it.
Let's hope that with a security update like this, this will not be the case . Because even if the amount of devices is very small it still means some people are vulnerable.
Comments
Is there any protection we can use for this problem?
Two-factor authentication would help. It works pretty well for Google accounts. iCloud has had it too as of last year.
Two-factor authentication would help. It works pretty well for Google accounts. iCloud has had it too as of last year.
Well it protects you as in, knowing only your password isn't sufficient to get in. But it doesn't guarantee that your password can be stolen if the web service is vulnerable to heartbleed.
But yeah it definitely made sure that even if your password was leaked it didn't jeopardize your personal information. I use it on all services that offer it.
Windows is not affected by this bug either, as it does not use OpenSSL.
I think this whole thing is a great example of how the assertions made by open source advocates are based on little more than blind faith.
Specifically, there are two blind faith assumptions here:
1. people who contribute to open source projects are altruistic
2. bugs and security flaws are more likely to be spotted if there are thousands of eyes reviewing the code
What we find in practice, however, is:
1. there are many people who are not altruistic -- in fact some that are downright sneaky and malevolent. Giving those people unfettered access to vitally important code might not be a good idea.
2. the MEGO phenomenon is not ameliorated by the magic of open source.
Maybe proprietary code isn't so bad after all...
I think this whole thing is a great example of how the assertions made by open source advocates are based on little more than blind faith.
Specifically, there are two blind faith assumptions here:
1. people who contribute to open source projects are altruistic
2. bugs and security flaws are more likely to be spotted if there are thousands of eyes reviewing the code
What we find in practice, however, is:
1. there are many people who are not altruistic -- in fact some that are downright sneaky and malevolent. Giving those people unfettered access to vitally important code might not be a good idea.
2. the MEGO phenomenon is not ameliorated by the magic of open source.
Maybe proprietary code isn't so bad after all...
1. I think it's fair to say that most people who contribute to open source projects do so either out of pure love of coding or are paid to do so by a company, such as Redhat or Intel, which has a direct interest in the project. Even though anyone can play with the source code, it's only a few trusted developers that actually have commit access.
2. The assumption here is that making the code public will let larger numbers of qualified individuals review and debug the code. Whether that's true in practice depends on the project. It's probably true for large projects like Linux which are backed by major companies. This OpenSSL bug was discovered by Codenomicon and Google Security, neither of which are the primary developers of OpenSSL. Although they probably used various tools to detect that something was amiss in the first place, having the source code available to debug with likely made it easier to pinpoint the flaw in the code and expedite the patching process.
Why is the headline making a claim that Apple's operating systems are "protected against" Heartbleed? They have no protections against it whatsoever, and a quick glace at the headline and article would create a false sense of security. Apple's software did not incorporate the affected OpenSSL implementation, but some third-party software on those platforms are affected such as BlackBerry Mobile for iOS.
It seems like they didn't sanitize a value that came from the network. If there was a naming convention for untrusted/unsanitized variables the compiler could warn upon their use in memcpy, etc. Naming conventions was how Apple was able to implement largely automated memory management.
As long as PC guy doesn't mention that other one-line of code SSL bug that Apple had a short while ago.
There are advantages to both closed and open routes but open sourcing everything won't always come out with the best result:
http://www.ibtimes.co.uk/heartbleed-bug-millions-android-smartphones-tablets-risk-1444175
I'm certainly not a security expert but I have spent the better part of two days learning and checking all of our servers against https://www.ssllabs.com/ssltest/index.html to help our lame IT department, You'll need to go into considerable detail to refute my original comments. I don't think you have researched this as much as I have, I can be corrected, but you'll need to cite authoritative sites.
I provided a link to code that shows that some clients are vulnerable that you ignored. Exactly what more do you need as proof?
Just google heartbleed and wget. Which someone helping their lame IT department should be sufficiently skilled to do.
And playing the "I'm an expert" card (or the even lamer passive aggressive "I'm not an expert" card) gets you butkus on the internet.
And here Mr. "I'm not an expert but I researched this more than you" another link:
http://security.stackexchange.com/questions/55119/does-the-heartbleed-vulnerability-affect-clients-as-severely
The thread has a bunch of links to client vulnerabilities.
So IF you have downloaded OpenSSL via MacPorts (or other source) you ARE vulnerable to a heartbleed attack if your unpatched client hits a malicious server. And the likelihood that you are using such a client is much higher IF you are using MacPorts at all.
Same deal for windows users that use Cygwin.
Right. And there has never been a compromised server on the internet. The whole point is that if you have a client using openSSL there is a vulnerability to steal memory if there is a malicious server using this exploit against you.
Therefore your statement: "So in that sense, the other poster is correct because unless you are serving connections to SSL suites then there is no attack possible." is categorically wrong.
IF YOU HAVE OPENSSL VIA MACPORTS YOU SHOULD UPDATE IT.
The client side vulnerability needs you to initiate the contact to a malicious server but that's the normal use case for many of these vulnerable clients (i.e. if you use them at all, it's to talk to servers).
Why is the headline making a claim that Apple's operating systems are "protected against" Heartbleed? They have no protections against it whatsoever,and a quick glace at the headline and article would create a false sense of security. Apple's software did not incorporate the affected OpenSSL implementation, but some third-party software on those platforms are affected such as BlackBerry Mobile for iOS.
Certain apps on iOS are infected but that would mean they took the strange step of not using Apple's crypto code/p>
As always with Apple you have to read between the lines because all their public messaging is scripted to within an inch of its life. Apple realises that it's worked hard to gain the trust it has and it'd be hard to win back if lost so they don't want to say anything that could come back and bite them later.
Apple's own API are not affected. That's what they mean. But OpenSSL is available and can be used by certain apps.
http://www.apple.com/mac-mini/server/
http://arstechnica.com/security/2014/04/vicious-heartbleed-bug-bites-millions-of-android-phones-other-devices/
It is but pretty much no one uses it anymore, most who still are on 4.1 are on 4.1.2 which isn't affected. It's really only 4.1.1
Google send out a fix to the OEM's for the few devices affected.
It's unfortunate that some of those OEM's won't be motivated to offer it.
Let's hope that with a security update like this, this will not be the case