Heartbleed bug vulnerability
Clay_99058
Posts: 0
This is addressed to the Administrators and the folks who administer your servers. You store credit card information and you use Standard SSL encryption. Unless the SSL encryption is updated to protect against the heartbleed bug, your servers are vulnerable. I posted here because there appears to be no way to address the administrators of your servers.
Have you updated your SSL server protection to counteract the heartbleed bug?
http://www.cnet.com/news/how-to-protect-yourself-from-the-heartbleed-bug/
http://www.cnet.com/how-to/which-sites-have-patched-the-heartbleed-bug/
Post edited by Clay_99058 on
Comments
Who is this query addressed to?
BTW DAZ 3D is perfectly OK. No problems with DAZ 3D.
I just tested the site DAZ3d.com, and it comes up fixed or safe.
As I just said
This is addressed to the Administrators and the folks who administer your servers. You store credit card information and you use Standard SSL encryption. Unless the SSL encryption is updated to protect against the heartbleed bug, your servers are vulnerable. I posted here because there appears to be no way to address the administrators of your servers.
Have you updated your SSL server protection to counteract the heartbleed bug?
DAZ 3D is OK
Thanks. I just checked again and it now checks as safe. Good job.
The nature of the bug means that since, your SSL is updated,we should now change our passwords.
You may actually find this interesting
http://blog.cloudflare.com/staying-ahead-of-openssl-vulnerabilities
My son works in IT and he said I didn't need to change my password, so I'm not going to.
Daz3D was always safe. We use a version of OpenSSL that wasn't affected by the heartbleed bug. The CDN we use, Cloudflare was fixed a week before the vulnerability was made public.
There are some sites that are checking if it is vulnerable or not and still say that daz3d.com isn't safe because they are just checking to see if we are running OpenSSL, not any other checks such as version or attempting to trigger the bug, and are essentially reporting numerous false positives that would show that 65% of the entire internet isn't safe. So, needless to say, the websites that check based off that are safe to ignore. We did update our SSL cert just as a precaution and to give peace of mind to our customers, even though, at no time, was Daz3D vulnerable to the bug.
Does a particular site use OpenSSL 1.0.1 (EDIT: or 1.0.2-beta) and have the heartbeat function enabled? If not, then they're not vulnerable. http://www.openssl.org/news/secadv_20140407.txt
(This would happen a week after I got a promotion in the I.T. department at work. I've been busy... mostly telling upper management "no, we aren't affected, I don't care what the news says, the news is wrong".)
As for changing your password - yeah, you should do that regularly (three to twelve times a year), but not necessarily because of this program bug.
Only password I have bothered to change is my Yahoo one, as they were one site that was highlighted. However I didn't change it till after they had fixed their site.
Greetings,
Credit where it's due, DAZ's SSL ranks better than most, including forward secrecy, something that I'm still having trouble getting set up on my own boxes that have SSL needs.
Personally, I upgraded from an older openssl version that wasn't vulnerable to a newer version that wasn't vulnerable, myself. :)
This has been a fun chance to talk to folks about security, although some have been more...confrontational about it than I think is strictly necessary.
Technically, yes, everybody on any services that WERE vulnerable should change their passwords (and any unfortunately shared passwords), because the bug was in the wild for more than a year, and all kinds of things could have been acquired. On the other hand, it's not clear if The Bad Guys knew about it either, and everybody should gauge their own risk comfort level, along with a real assessment of their exposure.
I presume (mostly from the bugs that have arisen) that DAZ's servers are split between their 'active' servers and their CDN servers. Their active servers, providing customized content, responding to user-specific requests, it sounds like never had the vulnerability in the first place (either OpenSSL too old, or no heartbeat enabled). Their CDN servers were vulnerable until they updated, but would never have contained password (or session?) information.
So I would argue that DAZ probably doesn't need to expire sessions or encourage password changes.
It's a fun bug... Oh, and it also affects some clients, where a disreputable server can send a heartbeat over an SSL link and pull memory information from the connecting client. It's a lot rarer I believe, because not so many people are running OpenSSL in their clients, or using it in a way that can accept heartbeat messages during a link, but it does potentially work both ways.
-- Morgan
p.s. It's been sadly many years since I was full-time in the security field, so I may have misunderstood some parts, but I'm fairly confident I've got it right.
PayPal says that it is not necessary to change the password:
https://www.paypal-community.com/t5/PayPal-Forward/OpenSSL-Heartbleed-Bug-PayPal-Account-Holders-are-Secure/ba-p/797568#
In today's world I never ASSUME anything. I appreciate the OP question that brought about this statement. I had gone to other online stores and the admins had already made statements that their sites were safe. If the OP hadn't brought up the question and recieved an answer, I guess we would have been left to wonder about DAZ3D or ask ourselves.
I feel like admins or at the very least forum administers should have been out in front of this and made a statement about the danger, or lack of danger, before someone had to ask. This is a big deal and should have been addressed by the people running DAZ3D, not as just a response to a query from some concerned customer.
just my two cents
So when setting up the new store you used an outdated version of OpenSSL libraries prior 2012 then ? Please explain.
There are any number of possibilities. Ranking a few of them from "makes most sense" to "makes least sense":
1) Heartbeat was turned off, and thus was not vulnerable.
2) They chose to use a version older that current one, because more of the bugs have already been discovered in it.
3) Something in Magento might need a particular version of OpenSSL.
4) If they purchased a "turnkey" solution, they got whatever code was in it.
5) That's the version the programmer always uses. (I really hope this isn't the accurate possibility.)
what is SSL? Nevermind, I'll look it up in Wikipedia.
edit: finally learned of role the certificates played in SSL.
Secure Socket Layer is an encryption function for the internet - it's what makes the difference between a website and a secure website, amongst other things.
Thanks for that. I get an error message however when I try to change my password at LinkedIn, other functions there gives errors as well.
Thanks for that. I get an error message however when I try to change my password at LinkedIn, other functions there gives errors as well.
Ok, not necessary anyway, it seems:
"LinkedIn Update: Regarding the recent Heartbleed security vulnerability, the OpenSSL version that had this issue was not used on www.linkedin.com or www.slideshare.net. As a result, the Heartbleed bug does not present a risk to these websites."
This is pure guessing that doesn't help. That's why I asked for an explanation (from DAZ_Jon).
Many linux distros which are used for servers use older versions of software with backpatches for security fixes by default. This is to maintain functional compatibility to the highest level. So pretty much all servers out there running Red Hat Enterprise 6 (the latest version which is supported till 2016 when it starts a phased end of life that goes till 2020), Ubuntu LTS 10.04 (end of life in mid 2015), or other distros that offer a long term support / stability option, would have been using a 1.0.0 branch of SSL that updates it when needed for security bug fixes. In the case of OpenSSL, the last update for that was in Jan of 2014.
There is a trade off in running long term stable versions... you don't get the latest, bleeding edge toys to play with. For instance, some of the more commonly used pieces of software used on these types of machines, the latest version by default available for most of these stable releases is a 5.3.x series of PHP (currently the latest stable release is 5.5.x), apache is the 2.2.x series (latest is 2.4), ruby versions are around 1.8.x to 1.9.x series (latest is 2.1.x). The latest versions, end users would never know the difference as it only really matters to the developers and system admins for language or software features that drive the end application, and the trade off is on a system update or bug fix you are pretty much guaranteed that your application will still work the same as opposed to the earlier days of this sort of thing (late 90s, early 00s) where a system update somewhat often did completely bring break the server setup and stop the services running on it from working all together.
In short, its very common and generally preferred by companies to run longer term stable versions of distros that used older and more tested releases of software that get security back patches when needed.