[opensuse] Heartbleed Bug - for all internet users - get your head out of the sand
Just changing the subject line and re-sending. The old subject implied it was openSUSE 12.1 specific. This is likely the biggest security event in the Internet's history. 99% or more of all Internet users will have to develop their own PERSONAL remediation plan and follow it. That is true of Google/Amazon/etc., but it also includes every user that conducts secure transactions across the Internet. Think about and banks, stores, ISPs, SAAS providers, etc. you interact with. Most problematic will be the 70+ year old that manages their financial holdings via the Internet. They need to follow steps to ensure everything they thought was secure last week is still believed secure this week. I don't even know enough yet to implement my own remediation plan, but here's a 3-line example out of it: 1 - change bank online password immediately 2 - verify bank was either never susceptible to the heartbleed bug, or that they have remediated it. 3 - once 2) is done, change the password again since it may have been breached between steps 1 & 2. I have no idea how to implement step 2. Now magnify that issue for every internet based account I have that I login into. So that very undefined plan addresses internet passwords. Next, every credit card transaction conducted over the internet during the last 2 years should be considered potentially breached, so all credit cards / ATM cards need to be re-issued with new cards. What about PINs? Do they need to be changed? I don't know. I'm not saying you need to run around like chicken little, but if you think you just have to get the latest security patches and go on with your life, you're wrong. If you use SSL to serve secure data, keep reading: ---------- Forwarded message ---------- From: Greg Freemyer <greg.freemyer@gmail.com> Date: Thu, Apr 10, 2014 at 9:40 AM Subject: Re: [opensuse] SuSE 12.1 and Heartbleed Bug To: opensuse@opensuse.org On April 10, 2014 4:45:16 AM EDT, Dsant <forum@votreservice.com> wrote:
Le 10/04/2014 01:22, Cristian Rodríguez a écrit :
El 09/04/14 19:53, Matt Darnell escribió:
Fixes has been released already for 13.1.. zypper patch is your best friend
Will "zypper up" be enough ? Or within some time ?
This is a critical bug/vulnerability with huge impacts. Maybe the worst to ever effect Linux, but it only affects the server side of a SSL connection as I understand it. For most opensuse users it is not an issue from an admin perspective. As users of the internet, this bug means everything transferred across the internet in the last 2 years that depended solely on SSL for security should be considered potentially breached. That assumes the server end of the connection was running a vulnerable version of openSSL, but as normal users you have to assume that. That means the best practice for all users (including MS users) is to change all passwords used on the internet and watch credit info closely. Then give your internet providers (isps/SAAS providers/banks/stores/auction sites) some time to fix their end and do it all again. I don't know how to test those providers to see if they are secure or not. I'm sure guidance will be forthcoming. Assuming you are running a server serving encrypted data via openSSL: Zypper up should be a superset of zypper patch, so yes it should get it but if this is important to you then don't just assume it will work. Get the openSSL patch, install it and read the description of the installed patch to make sure you have it. Then, if it is important to you, you have a security key you use in conjunction with openSSL to serve secure data. You should consider your key breached. That means that key needs to be replaced with a new one. That is manual work and you may have to go buy a new one if it is a registered key. It should be done after you get the openSSL security patch installed on every machine in your network that uses the same key and openSSL. Normally that is only one machine, but some web farms share a key between machines. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-04-10 16:49, Greg Freemyer wrote:
I don't even know enough yet to implement my own remediation plan, but here's a 3-line example out of it:
1 - change bank online password immediately
Would it not be "not immediately", but after the bank server updates their software? How do we know they updated? Because if we change the password, and they change their software _and_ certificate in, say two weeks time, the bad guys can get our new password during that interval. And we will think we did the right thing and do nothing in months... Further, how do we change our passwords, it the transmission protocol used while you change it, is suspect?
2 - verify bank was either never susceptible to the heartbleed bug, or that they have remediated it. 3 - once 2) is done, change the password again since it may have been breached between steps 1 & 2.
Ugh. :-( -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
"Carlos E. R." 04/10/14 10:21 AM >>> On 2014-04-10 16:49, Greg Freemyer wrote:
I don't even know enough yet to implement my own remediation plan, but here's a 3-line example out of it:
1 - change bank online password immediately
Would it not be "not immediately", but after the bank server updates their software? How do we know they updated? Because if we change the password, and they change their software _and_ certificate in, say two weeks time, the bad guys can get our new password during that interval. And we will think we did the right thing and do nothing in months... Further, how do we change our passwords, it the transmission protocol used while you change it, is suspect?
2 - verify bank was either never susceptible to the heartbleed bug, or that they have remediated it. 3 - once 2) is done, change the password again since it may have been breached between steps 1 & 2.
Ugh. :-( Just FYI in case it helps - http://mashable.com/2014/04/09/heartbleed-bug-websites-affected/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 10/04/14 11:49, Greg Freemyer escribió:
1 - change bank online password immediately Next, every credit card transaction conducted over the internet during the last 2 years should be considered potentially breached, so all credit cards / ATM cards need to be re-issued with new cards.
What about PINs? Do they need to be changed? I don't know.
I do not know how things work were you live, but here all internet bank transactions that involve any sort of cash movement (even between your own products) require two step verification, sometimes even 3 step. (it is quite a pain in the ass, indeed) Single-use credit card numbers are also being promoted, PIN is mandatory with any transaction with the physical card..not to mention new plastic with security chip is slowly getting introduced. Also banks are not known for staying on top of technology, in fact quite the opposite, they are in an state of fossilization..I doubt many run reasonable updated openSSL versions that contain the vulnerability. -- Cristian "I don't know the key to success, but the key to failure is trying to please everybody." -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Apr 10, 2014 at 3:41 PM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
I do not know how things work were you live, but here all internet bank transactions that involve any sort of cash movement (even between your own products) require two step verification, sometimes even 3 step. (it is quite a pain in the ass, indeed)
I have 2 banks in the US I have accounts with. Neither require anything I can't easily type or click. When they see I'm coming from a new IP (or cookie), they just ask a security question. But they do that often enough that someone monitoring the encrypted traffic in/out of the bank would see a session with my login/password/security answer within a few weeks. Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/10/14 21:41, Cristian Rodríguez wrote:
Also banks are not known for staying on top of technology, in fact quite the opposite, they are in an state of fossilization..I doubt many run reasonable updated openSSL versions that contain the vulnerability.
That banks don't run distributions with not-yet-settled technology is one thing. With customer-facing IT, they shall not be on top of technology. They shall be conservative and use proven technology that has settled. To call that fossilization is ridiculous. (Internally, that's completely different thing. I know quite some banks that have their own patched kernels, especially when HFT is involved.) That banks don't patch their systems and don't update critical security infrastructure is far from the truth. Responsible persons in IT wouldn't survive the next internal audit. Patch processes and documentation are regular and mandatory items on audit check lists. BEAST and other vulnerabilities have triggered updates of OpenSSL-based products and have introduced respective versions that are now vulnerable against heartbleed. If one is lucky, F5s were used as load balancers; they are not vulnerable. As somebody who spent the last few days to help several banks to mitigate that problem, I can assure you: banks are not in a state of fossilization, they run reasonable updated openSSL versions, (sadly) most of them were vulnerable, and checking/patching the problem was a high-priority C-level-attention thing for all of them. Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod, Roedermark, Germany Email: jschrod@acm.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer wrote:
Just changing the subject line and re-sending. The old subject implied it was openSUSE 12.1 specific.
This is likely the biggest security event in the Internet's history. 99% or more of all Internet users will have to develop their own PERSONAL remediation plan and follow it.
That is true of Google/Amazon/etc., but it also includes every user that conducts secure transactions across the Internet. Think about and banks, stores, ISPs, SAAS providers, etc. you interact with.
Most problematic will be the 70+ year old that manages their financial holdings via the Internet. They need to follow steps to ensure everything they thought was secure last week is still believed secure this week.
The 70+ year old who is aware is not the biggest problem. Even more problematic will be all the other people who are unaware.
I don't even know enough yet to implement my own remediation plan, but here's a 3-line example out of it:
1 - change bank online password immediately 2 - verify bank was either never susceptible to the heartbleed bug, or that they have remediated it. 3 - once 2) is done, change the password again since it may have been breached between steps 1 & 2.
Fortunately, my e-banking password is never transmitted over the net. Same for my on-line stock trader. Plenty of other places though. On-line postage stamps generation, domain registration, miscellaneous online shops, admin portals etc. etc.
As users of the internet, this bug means everything transferred across the internet in the last 2 years that depended solely on SSL for security should be considered potentially breached. That assumes the server end of the connection was running a vulnerable version of openSSL, but as normal users you have to assume that. That means the best practice for all users (including MS users) is to change all passwords used on the internet and watch credit info closely. Then give your internet providers (isps/SAAS providers/banks/stores/auction sites) some time to fix their end and do it all again. I don't know how to test those providers to see if they are secure or not. I'm sure guidance will be forthcoming.
Maybe: https://github.com/musalbas/heartbleed-masstest
Assuming you are running a server serving encrypted data via openSSL:
meaning e.g. apache, openvpn, sshd, postfix (and exim et al), dovecot etc. -- Per Jessen, Zürich (11.1°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 11/04/2014 10:46, Per Jessen a écrit :
Fortunately, my e-banking password is never transmitted over the net.
how can this be for an "e" account? jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd wrote:
Le 11/04/2014 10:46, Per Jessen a écrit :
Fortunately, my e-banking password is never transmitted over the net.
how can this be for an "e" account?
jdd
It is a challenge-response process - when I log in, it works like this: 1) enter contract-nr (not account-nr) 2) read challenge (6 digits) from website 3) open response-generator (a small calculator like device), insert smartcard for the contract, enter pin-code for smartcard http://files.jessen.ch/bank-card-reader-device.png 4) enter challenge, hit ok. 5) enter generated response on website 6) done. With some other sites, I use a one-time-pad, i.e. a list of pre-generated code-sequences. Unbreakable. -- Per Jessen, Zürich (12.1°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 11/04/2014 11:27, Per Jessen a écrit :
With some other sites, I use a one-time-pad, i.e. a list of pre-generated code-sequences. Unbreakable.
yes, I see this more and more (with number table that changes each time). Seemes good, but I don't know for sure thanks jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd wrote:
Le 11/04/2014 11:27, Per Jessen a écrit :
With some other sites, I use a one-time-pad, i.e. a list of pre-generated code-sequences. Unbreakable.
yes, I see this more and more (with number table that changes each time). Seemes good, but I don't know for sure
I first heard of the challenge-response idea back in the 90s - it was already in use with several German on-line banking systems (maybe it was standard in the HBCI specification). I think my bank has been using their current setup it for 10 years or more. I'm on my third card-reader. -- Per Jessen, Zürich (16.2°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-04-11 14:23, Per Jessen wrote:
jdd wrote:
I first heard of the challenge-response idea back in the 90s - it was already in use with several German on-line banking systems (maybe it was standard in the HBCI specification). I think my bank has been using their current setup it for 10 years or more. I'm on my third card-reader.
I've never seen it here (Spain), at least for "consumers". I have used it inside companies, to access the network by employees. The one I'm thinking of they also had antitempest windows, and WiFi was strictly forbidden (it is dismantled on the warehouse, to the dismay of the operators using the handled gadgetry they typically use on the store room or warehouses. I've seen one important bank using a table of codes for a challenge-response system, which is used only for "operations". However, the table is card that might be used for many years, not a one use thing. For accessing your bank data it uses a simple login/pin code (and not a long pin). Another important bank uses a login/pass to access, then a challenge-response method for operations, but instead of a long table of codes, it is just a an 8 char code of which they ask you, say, to type digits 5 and 7. Again, not a one use thing. I think they also use a verification code sent over SMS to your mobile phone, but I don't recall which one does. It may be a volunteer choice. A thing I have also noticed is that they ask you to enter pin codes not on the keyboard, but by clicking with the mouse on a keyboard on the screen. This might be to foul dongles inserted on the keyboard cable. Last time I noticed that the position of the virtual keys was random on one site. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2014-04-11 14:23, Per Jessen wrote:
jdd wrote:
I first heard of the challenge-response idea back in the 90s - it was already in use with several German on-line banking systems (maybe it was standard in the HBCI specification). I think my bank has been using their current setup it for 10 years or more. I'm on my third card-reader.
I've never seen it here (Spain), at least for "consumers". I have used it inside companies, to access the network by employees. The one I'm thinking of they also had antitempest windows, and WiFi was strictly forbidden (it is dismantled on the warehouse, to the dismay of the operators using the handled gadgetry they typically use on the store room or warehouses.
I've seen one important bank using a table of codes for a challenge-response system, which is used only for "operations".
I think that's the system they've also used in Germany - TAN/PIN. I'm not intimately familiar with it, but ISTR using such a scheme with the German BTX.
Another important bank uses a login/pass to access, then a challenge-response method for operations, but instead of a long table of codes, it is just a an 8 char code of which they ask you, say, to type digits 5 and 7. Again, not a one use thing.
No, but that's still a challenge-response system. The one-time-key is just the origin.
I think they also use a verification code sent over SMS to your mobile phone, but I don't recall which one does. It may be a volunteer choice.
Yes, Credit-Suisse uses such a scheme too. Not optional. -- Per Jessen, Zürich (19.7°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Assuming you are running a server serving encrypted data via openSSL:
meaning e.g. apache, openvpn, sshd, postfix (and exim et al), dovecot etc.
Not sshd from what I understand. And apache, only if you have https setup, right? I've forgotten where security certificates live with ssh. Public key on the server and private on my personal workstation, right? I have a email server running on one box. Can the vulnerability have been used to get the sshd private keys? I'm thinking the private ssh keys would have never been in the memory space of the email server, so they are safe? On the other hand, the pop/imap passwords could have been gotten and for users that have a re-used password they could have been used it to ssh straight into the box for any users not using a security certificate to authenticate. In that case all docs/data available to the user was potentially breached. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer wrote:
Assuming you are running a server serving encrypted data via openSSL:
meaning e.g. apache, openvpn, sshd, postfix (and exim et al), dovecot etc.
Not sshd from what I understand.
Yes, I saw you mentioned that earlier. If sshd is not affected, that's a big load off my shoulders.
And apache, only if you have https setup, right?
Right.
I've forgotten where security certificates live with ssh. Public key on the server and private on my personal workstation, right?
Yup.
I have a email server running on one box. Can the vulnerability have been used to get the sshd private keys? I'm thinking the private ssh keys would have never been in the memory space of the email server, so they are safe?
Wild guessing - if you have TSL enabled in your mail-server, I guess the vulnerability could have been used to extract data from it, but if your private key was never on that system ...
On the other hand, the pop/imap passwords could have been gotten and for users that have a re-used password they could have been used it to ssh straight into the box for any users not using a security certificate to authenticate. In that case all docs/data available to the user was potentially breached.
Yup. -- Per Jessen, Zürich (19.6°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-04-11 16:41, Per Jessen wrote:
Wild guessing - if you have TSL enabled in your mail-server, I guess the vulnerability could have been used to extract data from it, but if your private key was never on that system ...
I know little of how the vulnerability works, but apparently they trick the machine (client? server? both?) to freely send a copy of 64 KB of RAM, which may contain anything. I don't clearly know if they can walk all memory, or just memory from the process that responds, or the memory assigned to the user of that process, or just one 64 KB block, where a particular buffer should have been assigned, but was not really assigned (ie, a non initialized pointer?). Or the block was assigned but not erased previous to been used. That RAM they get might contain data obtained from a different computer, so that the keys are on another computer, that's irrelevant. As long as the keys were retrieved and read on memory at some time, and they can read that memory block... And the vulnerability can be used even without accreditation for that server. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
В Fri, 11 Apr 2014 20:01:53 +0200 "Carlos E. R." <robin.listas@telefonica.net> пишет:
I know little of how the vulnerability works,
http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html
but apparently they trick the machine (client? server? both?)
Machine that is processing packet. It can be both.
to freely send a copy of 64 KB of RAM, which may contain anything. I don't clearly know if they can walk all memory, or just memory from the process that responds, or the memory assigned to the user of that process, or just one 64 KB block, where a particular buffer should have been assigned, but was not really assigned (ie, a non initialized pointer?). Or the block was assigned but not erased previous to been used.
It can read up to 64K starting from the memory location where incoming packet (which is being processed) is allocated. This is local memory belonging to process. There is no way to control *what* is read nor control memory location that is read; one can only make some guesses based on knowledge of a program being attacked and its allocation patterns. Good metaphor from another site: "but it's not [targeted attack]. It's more like panning for gold than robbing a bank.".
That RAM they get might contain data obtained from a different computer, so that the keys are on another computer, that's irrelevant. As long as the keys were retrieved and read on memory at some time, and they can read that memory block...
And the vulnerability can be used even without accreditation for that server.
On 2014-04-11 21:42, Andrey Borzenkov wrote:
В Fri, 11 Apr 2014 20:01:53 +0200 "Carlos E. R." <> пишет:
I know little of how the vulnerability works,
http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html
Thanks. I love this paragraph: +++···················· Lessons What can we learn from this? I'm a fan of C. It was my first programming language and it was the first language I felt comfortable using professionally. But I see its limitations more clearly now than I have ever before. ····················++- My C teacher, about two decades ago, warned us /against/ using C. he spent hours stressing problems with C and how unsafe it was. Apparently, he had been doing some type of audit of C compilers for a government agency, I think. He could not talk about the details, but he was scared, and transmitted some of it to us... I'm not a fan of C. But I have been paid to use it, so I used it.
It can read up to 64K starting from the memory location where incoming packet (which is being processed) is allocated. This is local memory belonging to process. There is no way to control *what* is read nor control memory location that is read; one can only make some guesses based on knowledge of a program being attacked and its allocation patterns. Good metaphor from another site: "but it's not [targeted attack]. It's more like panning for gold than robbing a bank.".
I see. So maybe they get nothing... Impossible for us to know what they got, I guess. So we have to assume the worst, to be safe... -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
El 11/04/14 17:30, Carlos E. R. escribió:
On 2014-04-11 21:42, Andrey Borzenkov wrote:
В Fri, 11 Apr 2014 20:01:53 +0200 "Carlos E. R." <> пишет:
I know little of how the vulnerability works,
http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html
Thanks.
I love this paragraph:
+++···················· Lessons
What can we learn from this?
I'm a fan of C. It was my first programming language and it was the first language I felt comfortable using professionally. But I see its limitations more clearly now than I have ever before.
I'm not a fan of C. But I have been paid to use it, so I used it.
This suggestion frequently comes up.. particulary from people that suggest implementing this stuff in C++ .. what will happen if that were the case ? the library in question will be disfavoured or not considered for widespread use. Only projects with an existing C++ codebases such as KDE or libreoffice will take advantage of it. -- Cristian "I don't know the key to success, but the key to failure is trying to please everybody." -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, Apr 11, 2014 at 5:23 PM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
El 11/04/14 17:30, Carlos E. R. escribió:
On 2014-04-11 21:42, Andrey Borzenkov wrote:
В Fri, 11 Apr 2014 20:01:53 +0200 "Carlos E. R." <> пишет:
I know little of how the vulnerability works,
http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html
Thanks.
I love this paragraph:
+++···················· Lessons
What can we learn from this?
I'm a fan of C. It was my first programming language and it was the first language I felt comfortable using professionally. But I see its limitations more clearly now than I have ever before.
I'm not a fan of C. But I have been paid to use it, so I used it.
This suggestion frequently comes up.. particulary from people that suggest implementing this stuff in C++ .. what will happen if that were the case ? the library in question will be disfavoured or not considered for widespread use. Only projects with an existing C++ codebases such as KDE or libreoffice will take advantage of it.
I'd suggest that this would be the case only if badly done. If I were asked (and paid) to undertake such a task, one of the requirements I'd impose is that while the guts of the thing is implemented in C++, there'd be a suite of C functions that provide the interface for the DLL. While I have worked on projects that used libraries written in C in products mostly written in C++, it can be done the other way around; but it ain't easy. I know, and like, both C and C++, but I am not masochistic enough to undertake such a task if I didn't have to (or unless someone was willing to pay me enough over a few years to let me buy, and retire to, a mansion in Victoria BC ;-) And, it is harder than much more effective options that are available. On the other hand, I'd argue that there is nothing wrong with continuing on with the product being written in C. What I'd recommend, instead, is that, if the manpower can be found, beef up the unit and integration tests, and more aggressively perform security audits on the code. While I would not ask a junior programmer to do so, it is not especially hard for someone with more than a few years experience to write secure C code; as long as proper design documentation is maintained. Cheers Ted -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-04-11 23:23, Cristian Rodríguez wrote:
El 11/04/14 17:30, Carlos E. R. escribió:
On 2014-04-11 21:42, Andrey Borzenkov wrote:
This suggestion frequently comes up.. particulary from people that suggest implementing this stuff in C++ .. what will happen if that were the case ? the library in question will be disfavoured or not considered for widespread use. Only projects with an existing C++ codebases such as KDE or libreoffice will take advantage of it.
No, I don't suggest using C++ either. I read Mr Linus explaining why that would not work with the kernel, for instance. In fact, I don't know which language to propose, but I'm against using C for everything. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNIamsACgkQtTMYHG2NR9UZoQCfWRwBG480PfHWgkKJpm2Y50Ab tfEAniVTTQsGX/3VPH5yqs6d50BrM+No =28aA -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, Apr 11, 2014 at 4:30 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2014-04-11 21:42, Andrey Borzenkov wrote:
В Fri, 11 Apr 2014 20:01:53 +0200 "Carlos E. R." <> пишет:
I know little of how the vulnerability works,
http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html
Thanks.
I love this paragraph:
+++···················· Lessons
What can we learn from this?
I'm a fan of C. It was my first programming language and it was the first language I felt comfortable using professionally. But I see its limitations more clearly now than I have ever before. ····················++-
My C teacher, about two decades ago, warned us /against/ using C. he spent hours stressing problems with C and how unsafe it was. Apparently, he had been doing some type of audit of C compilers for a government agency, I think. He could not talk about the details, but he was scared, and transmitted some of it to us...
I'm not a fan of C. But I have been paid to use it, so I used it.
Having seen, and used, a number of languages in the algol family (FORTRAN,Pascal, BASIC, C/C++/C#, Java, Perl, PHP, &c.), I became aware of the strengths and weaknesses of each early on. It seems to me to be silly to be afraid of any of the languages, but rather of the people who use and abuse them. There are incredibly powerful languages, like C++ and Perl, and then others that begin with the good languages, as it were, and dumb them down (Java, C#, PHP) so more junior and intermediate programmers can be more productive and less dangerous. But, in dumbing dow a language, things one can do in the more powerful languages that some deem too dangerous are simply prohibited (because a language feature it depends on is excluded). Look at what MS did with their 'Managed C++', and their suite of .NET libraries and languages. I have seen some old pros say that you have the dumbed down languages that limit what you can do, and basically protect you from yourself, and then languages like C++ that give you lots of power, along with the ability to shoot yourself in the foot, and then there is Perl, which gives you the power to blow your whole (expletive deleted) leg off. I suppose my favorite languages are C++ (for my number crunching) and perl (for my distributed, secure, programming). One can make business cases for all of the available languages in specific situations. It seems to me that, instead of being afraid of any language, it behooves a pro to be aware of the strengths and weaknesses of all the languages he uses, and select the set thereof that best supports the functional requirements of the project he's working on. In the case of this bug, as in most bugs I have squashed, it is not a problem of a flaw in the language, but rather a mistake in coding, and perhaps an over-sight in the testing regime. His first two recommendations, generally, is the more useful. He also said we ought to: 1) Pay money for security audits of critical security infrastructure like OpenSSL 2) Write lots of unit and integration tests for these libraries 3) Start writing alternatives in safer languages One of the biggest factors in software quality is that those that 'manage' software projects often are unwilling to support sufficient documentation and testing. That costs money (or time in the case of open source products, and there may be a shortage of manpower to get it done right). Software houses generally want the software as inexpensive as possible, and so the usual QA processes get shortchanged, or skipped altogether. His first two recommendations go hand in glove. I have seen too many software houses (and those that hire software development contractors) that provide barely enough resources to do a decent job of prototyping, and fail to fund even basic unit testing. As for his third recommendation, it can be argued that there are no truly safe languages that are useful (although, if someone were to pay me to do so, I might consider ADA, to see if it is both genuinely useful and as safe as I have heard it is), and that one must rely on the expertise of those using whatever language has been selected for the work. My final thought is that nothing is perfect, nor is it reasonable to expect perfection from beings as flawed as are human beings. All we can do is our best, and be diligent in acting appropriately when a flaw is detected. Cheers, Ted -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-04-11 23:27, Ted Byers wrote:
On Fri, Apr 11, 2014 at 4:30 PM, Carlos E. R. <> wrote:
...
It seems to me that, instead of being afraid of any language, it behooves a pro to be aware of the strengths and weaknesses of all the languages he uses, and select the set thereof that best supports the functional requirements of the project he's working on.
I agree.
In the case of this bug, as in most bugs I have squashed, it is not a problem of a flaw in the language, but rather a mistake in coding, and perhaps an over-sight in the testing regime.
IMHO, C should be left to professionals and experienced programmers. :-)
His first two recommendations, generally, is the more useful.
He also said we ought to:
1) Pay money for security audits of critical security infrastructure like OpenSSL 2) Write lots of unit and integration tests for these libraries 3) Start writing alternatives in safer languages
One of the biggest factors in software quality is that those that 'manage' software projects often are unwilling to support sufficient documentation and testing. That costs money (or time in the case of open source products, and there may be a shortage of manpower to get it done right). Software houses generally want the software as inexpensive as possible, and so the usual QA processes get shortchanged, or skipped altogether. His first two recommendations go hand in glove. I have seen too many software houses (and those that hire software development contractors) that provide barely enough resources to do a decent job of prototyping, and fail to fund even basic unit testing.
I agree, too. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNIbToACgkQtTMYHG2NR9VkAACeP0VWfXbT+2bDcE1Ncmqm5UXl uRMAn36vlW/1YysSaxFJTkOV/cgNZWHx =4Xz5 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, Apr 11, 2014 at 6:31 PM, Carlos E. R. <carlos.e.r@opensuse.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014-04-11 23:27, Ted Byers wrote:
On Fri, Apr 11, 2014 at 4:30 PM, Carlos E. R. <> wrote:
...
It seems to me that, instead of being afraid of any language, it behooves a pro to be aware of the strengths and weaknesses of all the languages he uses, and select the set thereof that best supports the functional requirements of the project he's working on.
I agree.
In the case of this bug, as in most bugs I have squashed, it is not a problem of a flaw in the language, but rather a mistake in coding, and perhaps an over-sight in the testing regime.
IMHO, C should be left to professionals and experienced programmers.
:-)
Yes, but there must be a way to develop the kids into seasoned old pros. ;-) Thus, I would teach the kids C and C++, but when it comes to developing production code, they do so only working closely with several intermediate programmers and very closely supervised by senior programmers. And, of course, nothing makes it into the code base without both unit tests and detailed code reviews. But the latter must be done with the intermediate and junior programmers, so that they can better learn what coding practices are risky, and, if needed, how the risks are to be mitigated. Personally, the educator in me, would accompany that exercise with contrived exercises that the junior programmers would have to work on with the intermediate programmers, so that they can see, in sample programs, why some practices are risky. That is, they would have to write several programs, one which includes the risky practice that was identified in the code they just had reviewed, and then write several programs to attack it, so they can see, experimentally, hands on, the nature of the vulnerability they almost created, how to exploit it, and how to write the code in the most secure manner possible. Alas, I doubt there are very many software houses that would support such continuing education of their software development staff. :-(
His first two recommendations, generally, is the more useful.
He also said we ought to:
1) Pay money for security audits of critical security infrastructure like OpenSSL 2) Write lots of unit and integration tests for these libraries 3) Start writing alternatives in safer languages
One of the biggest factors in software quality is that those that 'manage' software projects often are unwilling to support sufficient documentation and testing. That costs money (or time in the case of open source products, and there may be a shortage of manpower to get it done right). Software houses generally want the software as inexpensive as possible, and so the usual QA processes get shortchanged, or skipped altogether. His first two recommendations go hand in glove. I have seen too many software houses (and those that hire software development contractors) that provide barely enough resources to do a decent job of prototyping, and fail to fund even basic unit testing.
I agree, too.
It is good to learn that there is at least one person I agree with. ;-) Cheers Ted -- R.E.(Ted) Byers, Ph.D.,Ed.D. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-04-12 01:02, Ted Byers wrote:
On Fri, Apr 11, 2014 at 6:31 PM, Carlos E. R. <> wrote:
...
had reviewed, and then write several programs to attack it, so they can see, experimentally, hands on, the nature of the vulnerability they almost created, how to exploit it, and how to write the code in the most secure manner possible.
Alas, I doubt there are very many software houses that would support such continuing education of their software development staff. :-(
I would probably fail that testing myself. :-} There was no multitasking when I trained, and it was never a consideration when I was paid for programing. I never had to care about intruders or any kind of attacks. Security, for me, was ensuring that motors would stop when requested, and such... Buffers having the correct size, properly initialized, inside bounds, etc, of course. Accidents, not hackers, were my consideration. So no, I probably could not code current day security stuff. :-} - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNIkyAACgkQtTMYHG2NR9XEkwCfQ2ucE6pP7+WSMy9yaD1+eshc PJsAn24r5mZWLhRv4upycmdjq3VF5hRe =PQNh -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, Apr 11, 2014 at 9:13 PM, Carlos E. R. <carlos.e.r@opensuse.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014-04-12 01:02, Ted Byers wrote:
On Fri, Apr 11, 2014 at 6:31 PM, Carlos E. R. <> wrote:
...
had reviewed, and then write several programs to attack it, so they can see, experimentally, hands on, the nature of the vulnerability they almost created, how to exploit it, and how to write the code in the most secure manner possible.
Alas, I doubt there are very many software houses that would support such continuing education of their software development staff. :-(
I would probably fail that testing myself. :-}
Ah, you misunderstand. This testing isn't so much an evaluation of what the kids know, but rather they'd be testing their own experimental programs, with a view to encouraging them to learn as much as possible about secure programming; as always working closely with intermediate and senior programmers. While early on, security wasn't an issue for the applications I developed, it has been a primary focus for quite a few years now, especially because of the sensitivity of the data and the distributed nature of the programs. At the transport layer, we relied on openssl, and mostly assumed it did what it was supposed to do, and we focussed our security related tasks to the application layer. It actually isn't so hard, especially with the ability to use perl's taint mode, and to use regular expressions to verify that the data is valid (of course, we do that validation both on the client and server, so typos are caught early and the experience is quite user friendly).
There was no multitasking when I trained, and it was never a consideration when I was paid for programing. I never had to care about intruders or any kind of attacks. Security, for me, was ensuring that motors would stop when requested, and such... Buffers having the correct size, properly initialized, inside bounds, etc, of course. Accidents, not hackers, were my consideration.
When I was working on applications that resided only on the usr's workstation, the same was much the same for me, though at that time, I primarily used C++.
So no, I probably could not code current day security stuff. :-}
But you could learn it quickly, as it is not all that hard, unless you're actually contributing source code to the openssl project. ;-) Cheers Ted -- R.E.(Ted) Byers, Ph.D.,Ed.D. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, 2014-04-11 at 17:27 -0400, Ted Byers wrote: <some snipping>
I love this paragraph:
+++···················· Lessons
What can we learn from this?
I'm a fan of C. It was my first programming language and it was the first language I felt comfortable using professionally. But I see its limitations more clearly now than I have ever before. ····················++-
My C teacher, about two decades ago, warned us /against/ using C. he spent hours stressing problems with C and how unsafe it was. Apparently, he had been doing some type of audit of C compilers for a government agency, I think. He could not talk about the details, but he was scared, and transmitted some of it to us...
I'm not a fan of C. But I have been paid to use it, so I used it.
His first two recommendations, generally, is the more useful.
He also said we ought to:
1) Pay money for security audits of critical security infrastructure like OpenSSL 2) Write lots of unit and integration tests for these libraries 3) Start writing alternatives in safer languages
When people do not heed warnings from mistakes is recent history, you are bound to make them again. "Pay money for security audits of critical security infrastructure" two weeks before it became publically known that Diginotar was seriously compromised, the company was audited by PWC. Not an administrative audit, but a technical one..... Auditors themselves must be audited them selves, and _ALL_ audit results should be made public (to avoid ending up in a drawer) One might say, that the biggest contribution of Snowdon is, that we all should have learned, that our blind trust in organisations and gouvernements is unfounded. Regarding openssl: it's been compared with menure and spaggetti, almost impossible to test or understand what pieces of code are supposed to be doing. The whole strength op opensource in general, is when lots of people can and will look at the code, and bad pieces are removed. In this case, the original coder detected its "feature" after some years. Clearly this piece of code wasn't reviewed intensively enough. Isn't that what Poul-Henning Kamp has been saying for some time.... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, 2014-04-11 at 20:01 +0200, Carlos E. R. wrote:
On 2014-04-11 16:41, Per Jessen wrote:
Wild guessing - if you have TSL enabled in your mail-server, I guess the vulnerability could have been used to extract data from it, but if your private key was never on that system ...
I know little of how the vulnerability works, but apparently they trick the machine (client? server? both?) to freely send a copy of 64 KB of RAM, which may contain anything. I don't clearly know if they can walk all memory, or just memory from the process that responds, or the memory assigned to the user of that process, or just one 64 KB block, where a particular buffer should have been assigned, but was not really assigned (ie, a non initialized pointer?). Or the block was assigned but not erased previous to been used.
regarding TLS-secured daemons, it might be a big step get store all of those private keys into a HSM. All crypting/decrypting is done by the crypto-engine: off-line, so the private-key is never in the servers-mem -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer wrote:
I don't even know enough yet to implement my own remediation plan, but here's a 3-line example out of it:
1 - change bank online password immediately 2 - verify bank was either never susceptible to the heartbleed bug, or that they have remediated it. 3 - once 2) is done, change the password again since it may have been breached between steps 1 & 2.
I have no idea how to implement step 2.
Step 2 second half at least: http://filippo.io/Heartbleed/ -- Per Jessen, Zürich (12.0°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dear openSUSE on-line friend, how do You test Your servers to ensure they weren't compromised? I have to say I have no idea at all... :-/ Good luck, Vojtěch Dne Čt 10. dubna 2014 10:49:55, Greg Freemyer napsal(a):
Just changing the subject line and re-sending. The old subject implied it was openSUSE 12.1 specific.
This is likely the biggest security event in the Internet's history. 99% or more of all Internet users will have to develop their own PERSONAL remediation plan and follow it.
That is true of Google/Amazon/etc., but it also includes every user that conducts secure transactions across the Internet. Think about and banks, stores, ISPs, SAAS providers, etc. you interact with.
Most problematic will be the 70+ year old that manages their financial holdings via the Internet. They need to follow steps to ensure everything they thought was secure last week is still believed secure this week.
I don't even know enough yet to implement my own remediation plan, but here's a 3-line example out of it:
1 - change bank online password immediately 2 - verify bank was either never susceptible to the heartbleed bug, or that they have remediated it. 3 - once 2) is done, change the password again since it may have been breached between steps 1 & 2.
I have no idea how to implement step 2.
Now magnify that issue for every internet based account I have that I login into.
So that very undefined plan addresses internet passwords.
Next, every credit card transaction conducted over the internet during the last 2 years should be considered potentially breached, so all credit cards / ATM cards need to be re-issued with new cards.
What about PINs? Do they need to be changed? I don't know.
I'm not saying you need to run around like chicken little, but if you think you just have to get the latest security patches and go on with your life, you're wrong.
If you use SSL to serve secure data, keep reading:
---------- Forwarded message ---------- From: Greg Freemyer <greg.freemyer@gmail.com> Date: Thu, Apr 10, 2014 at 9:40 AM Subject: Re: [opensuse] SuSE 12.1 and Heartbleed Bug To: opensuse@opensuse.org
On April 10, 2014 4:45:16 AM EDT, Dsant <forum@votreservice.com> wrote:
Le 10/04/2014 01:22, Cristian Rodríguez a écrit :
El 09/04/14 19:53, Matt Darnell escribió:
Fixes has been released already for 13.1.. zypper patch is your best friend
Will "zypper up" be enough ? Or within some time ?
This is a critical bug/vulnerability with huge impacts. Maybe the worst to ever effect Linux, but it only affects the server side of a SSL connection as I understand it. For most opensuse users it is not an issue from an admin perspective.
As users of the internet, this bug means everything transferred across the internet in the last 2 years that depended solely on SSL for security should be considered potentially breached. That assumes the server end of the connection was running a vulnerable version of openSSL, but as normal users you have to assume that. That means the best practice for all users (including MS users) is to change all passwords used on the internet and watch credit info closely. Then give your internet providers (isps/SAAS providers/banks/stores/auction sites) some time to fix their end and do it all again. I don't know how to test those providers to see if they are secure or not. I'm sure guidance will be forthcoming.
Assuming you are running a server serving encrypted data via openSSL:
Zypper up should be a superset of zypper patch, so yes it should get it but if this is important to you then don't just assume it will work. Get the openSSL patch, install it and read the description of the installed patch to make sure you have it.
Then, if it is important to you, you have a security key you use in conjunction with openSSL to serve secure data. You should consider your key breached. That means that key needs to be replaced with a new one. That is manual work and you may have to go buy a new one if it is a registered key. It should be done after you get the openSSL security patch installed on every machine in your network that uses the same key and openSSL. Normally that is only one machine, but some web farms share a key between machines.
Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-- Vojtěch Zeisek Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux http://www.opensuse.org/ http://trapa.cz/
On April 11, 2014 6:45:54 AM EDT, "Vojtěch Zeisek" <vojtech.zeisek@opensuse.org> wrote:
Dear openSUSE on-line friend, how do You test Your servers to ensure they weren't compromised? I have to say I have no idea at all... :-/ Good luck, Vojtěch
It's not easy: - check to see if you even had the vulnerable library installed. By default, opensuse 12.1 and before only had an older openSSL, 12.2 and newer had a vulnerable version. Macs by default have an older version. MacPorts had the vulnerable version. - if vulnerable, the best place to look is in a DLP network traffic recorder. Some big companies record all internet traffic and keep it for weeks or months. The packet signature for this seems pretty straight forward now it is known. - 99% of of setups, don't have a separate DLP, but some do have wireshark or tcpdump recordings right off their server. If you happen to have those, search them for the packet signature. Even if you only have a minimal amount of these, I would search them. - the vulnerability allowed failed authentication requests to pull 64KB sections of ram. I'm guessing a bad would issue hundreds of thousands of failed authentication requests from the same IP expecting to get different data to sort through. So look through your authentication logs and if you don't see that pattern and if your logs go back in time to when you started running openSSL v1.0.1, you should be good. Unfortunately the vast majority of servers don't have tcp traffic dumps to review, and the failed login attempts signature is extremely common even without this attack, so seeing it means little. Thus for many opensuse users running a server, there is no way to know. On the other hand, I assume the opensuse evergreen users are safe from this problem. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer wrote:
On April 11, 2014 6:45:54 AM EDT, "Vojtěch Zeisek" <vojtech.zeisek@opensuse.org> wrote:
Dear openSUSE on-line friend, how do You test Your servers to ensure they weren't compromised? I have to say I have no idea at all... :-/ Good luck, Vojtěch
It's not easy:
Try this: http://filippo.io/Heartbleed/ There is also a command-line version. -- Per Jessen, Zürich (16.6°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/11/2014 02:25 PM, Per Jessen wrote:
Try this: http://filippo.io/Heartbleed/
I personally wouldn't trust any of such unknown URLs & domains anymore ... I've even already got the first SPAM mails reminding me to change my "Outlook 2007" password and referring to the CVE entry of this bug. ;-( Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On April 11, 2014 8:25:31 AM EDT, Per Jessen <per@computer.org> wrote:
Greg Freemyer wrote:
On April 11, 2014 6:45:54 AM EDT, "Vojtěch Zeisek" <vojtech.zeisek@opensuse.org> wrote:
Dear openSUSE on-line friend, how do You test Your servers to ensure they weren't compromised? I have to say I have no idea at all... :-/ Good luck, Vojtěch
It's not easy:
Try this: http://filippo.io/Heartbleed/
There is also a command-line version.
You answered a different question. E.g. You answered "how can I tell if I am currently vulnerable?" I think the question was "how can I tell if I was compromised in the 2 years between this bug / vulnerability being introduced and today?" I tried to answer the second question. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dne Pá 11. dubna 2014 09:04:42, Greg Freemyer napsal(a):
On April 11, 2014 8:25:31 AM EDT, Per Jessen <per@computer.org> wrote:
Greg Freemyer wrote:
On April 11, 2014 6:45:54 AM EDT, "Vojtěch Zeisek"
<vojtech.zeisek@opensuse.org> wrote:
Dear openSUSE on-line friend, how do You test Your servers to ensure they weren't compromised? I have to say I have no idea at all... :-/ Good luck, Vojtěch
It's not easy: Try this: http://filippo.io/Heartbleed/
There is also a command-line version.
You answered a different question.
E.g.
You answered "how can I tell if I am currently vulnerable?"
I think the question was "how can I tell if I was compromised in the 2 years between this bug / vulnerability being introduced and today?"
Yes, thank You. As I expected, there is no easy way how to find out if my server was attacked or not... I use denyhosts and fail2ban to block attackers randomly trying random combinations of username and password...
I tried to answer the second question.
Greg
All the best, Vojtěch -- Vojtěch Zeisek Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux http://www.opensuse.org/ http://trapa.cz/
On April 11, 2014 9:12:29 AM EDT, "Vojtěch Zeisek" <vojtech.zeisek@opensuse.org> wrote:
Dne Pá 11. dubna 2014 09:04:42, Greg Freemyer napsal(a):
On April 11, 2014 8:25:31 AM EDT, Per Jessen <per@computer.org> wrote:
Greg Freemyer wrote:
On April 11, 2014 6:45:54 AM EDT, "Vojtěch Zeisek"
<vojtech.zeisek@opensuse.org> wrote:
Dear openSUSE on-line friend, how do You test Your servers to ensure they weren't compromised? I have to say I have no idea at all... :-/ Good luck, Vojtěch
It's not easy: Try this: http://filippo.io/Heartbleed/
There is also a command-line version.
You answered a different question.
E.g.
You answered "how can I tell if I am currently vulnerable?"
I think the question was "how can I tell if I was compromised in the 2 years between this bug / vulnerability being introduced and today?"
Yes, thank You. As I expected, there is no easy way how to find out if my server was attacked or not... I use denyhosts and fail2ban to block attackers randomly trying random combinations of username and password...
Since each bite at the able only got a small amount of random ram, that may have been the best secondary defense for this. To get around that a bad guy would have had to of used a botnet to hit you from 1000's of unique IPs. That is hard to coordinate, but certainly not impossible. Hopefully there weren't a huge number of botnets up and running the last couple of years attacking computers via this vulnerability. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dne Pá 11. dubna 2014 09:30:10, Greg Freemyer napsal(a):
On April 11, 2014 9:12:29 AM EDT, "Vojtěch Zeisek" <vojtech.zeisek@opensuse.org> wrote:
Dne Pá 11. dubna 2014 09:04:42, Greg Freemyer napsal(a):
On April 11, 2014 8:25:31 AM EDT, Per Jessen <per@computer.org>
Greg Freemyer wrote:
On April 11, 2014 6:45:54 AM EDT, "Vojtěch Zeisek" <vojtech.zeisek@opensuse.org> wrote: server was attacked or not... I use denyhosts and fail2ban to block attackers randomly trying random combinations of username and password...
Since each bite at the able only got a small amount of random ram, that may have been the best secondary defense for this. To get around that a bad guy would have had to of used a botnet to hit you from 1000's of unique IPs.
That is hard to coordinate, but certainly not impossible. Hopefully there weren't a huge number of botnets up and running the last couple of years attacking computers via this vulnerability.
Still I haven't heard about any real misuse of this bug. Are there any examples of compromised servers etc.?
Greg
V. -- Vojtěch Zeisek Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux http://www.opensuse.org/ http://trapa.cz/
On Fri, Apr 11, 2014 at 9:38 AM, Vojtěch Zeisek <vojtech.zeisek@opensuse.org> wrote:
Still I haven't heard about any real misuse of this bug. Are there any examples of compromised servers etc.?
Between the announcement of the vulnerability and the roll-out of the patches, absolutely. Security teams immediately put up traffic sniffers and watched their clients passwords, credit card numbers etc. flying out the door. They also saw the SSL private security keys flying out. To assume you weren't hit in the 2 or 3 days between the announcement of the problem and the roll-out of the patch is a leap of faith for sure. Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, Apr 11, 2014 at 09:52:57AM -0400, Greg Freemyer wrote:
On Fri, Apr 11, 2014 at 9:38 AM, Vojtěch Zeisek <vojtech.zeisek@opensuse.org> wrote:
Still I haven't heard about any real misuse of this bug. Are there any examples of compromised servers etc.?
Between the announcement of the vulnerability and the roll-out of the patches, absolutely.
Security teams immediately put up traffic sniffers and watched their clients passwords, credit card numbers etc. flying out the door. They also saw the SSL private security keys flying out.
To assume you weren't hit in the 2 or 3 days between the announcement of the problem and the roll-out of the patch is a leap of faith for sure.
There is also the problem that the issue was present in the codebase for 2 years and there are people with network capture dumps that saw exploitation or probing in November 2013. Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/11/2014 06:52 AM, Greg Freemyer wrote:
Still I haven't heard about any real misuse of this bug. Are there any examples of compromised servers etc.? Between the announcement of the vulnerability and the roll-out of the
On Fri, Apr 11, 2014 at 9:38 AM, Vojtěch Zeisek <vojtech.zeisek@opensuse.org> wrote: patches, absolutely.
Security teams immediately put up traffic sniffers and watched their clients passwords, credit card numbers etc. flying out the door. They also saw the SSL private security keys flying out.
Did you find references for actual in-the-wild exploitation, Greg? I found some references to testing scenarios, but not actual data exfiltrations. This link from EFF thinks the only confirmed exploit kind of smells like an intelligence agency: https://www.eff.org/deeplinks/2014/04/wild-heart-were-intelligence-agencies-... http://tinyurl.com/lzez3sm Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On April 11, 2014 10:37:26 AM EDT, Lew Wolfgang <wolfgang@sweet-haven.com> wrote:
On 04/11/2014 06:52 AM, Greg Freemyer wrote:
Still I haven't heard about any real misuse of this bug. Are there any examples of compromised servers etc.? Between the announcement of the vulnerability and the roll-out of the
On Fri, Apr 11, 2014 at 9:38 AM, Vojtěch Zeisek <vojtech.zeisek@opensuse.org> wrote: patches, absolutely.
Security teams immediately put up traffic sniffers and watched their clients passwords, credit card numbers etc. flying out the door. They also saw the SSL private security keys flying out.
Did you find references for actual in-the-wild exploitation, Greg? I found some references to testing scenarios, but not actual data exfiltrations.
This link from EFF thinks the only confirmed exploit kind of smells like an intelligence agency:
https://www.eff.org/deeplinks/2014/04/wild-heart-were-intelligence-agencies-...
Regards, Lew
From: http://arstechnica.com/security/2014/04/heartbleed-vulnerability-may-have-be... "Terrence Koeman of MediaMonks told Ars he found signs of attempts to use the exploit dating back to November 2013. He used the packet content of a successful exploit of the Heartbleed vulnerability to check inbound packets logged by his servers and found a number of incoming packets from a network suspected of harboring a number of “bot” servers that were apparently scans for the vulnerability—sending Heartbleed-style requests to two different development servers in requests that were about five minutes apart." So this was either cyber criminals or the NSA. I'll assume it was cyber criminals, but who knows. Regardless, someone was scanning for the vulnerability 5 months ago. And this is not a complex vulnerability to leverage, once you find a vulnerable server, just keep sending authentication requests with invalid credentials. Using a spread out botnet defeats fail2ban style defenses. My personal opinion is the world's governments should treat this as a global catastrophe and pay to have every credit card on the planet reissued at a minimum. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 4/11/2014 7:15 PM, Greg Freemyer wrote:
On April 11, 2014 10:37:26 AM EDT, Lew Wolfgang <wolfgang@sweet-haven.com> wrote:
On 04/11/2014 06:52 AM, Greg Freemyer wrote:
Still I haven't heard about any real misuse of this bug. Are there any examples of compromised servers etc.? Between the announcement of the vulnerability and the roll-out of the
On Fri, Apr 11, 2014 at 9:38 AM, Vojtěch Zeisek <vojtech.zeisek@opensuse.org> wrote: patches, absolutely.
Security teams immediately put up traffic sniffers and watched their clients passwords, credit card numbers etc. flying out the door. They also saw the SSL private security keys flying out. Did you find references for actual in-the-wild exploitation, Greg? I found some references to testing scenarios, but not actual data exfiltrations.
This link from EFF thinks the only confirmed exploit kind of smells like an intelligence agency:
https://www.eff.org/deeplinks/2014/04/wild-heart-were-intelligence-agencies-...
Regards, Lew From: http://arstechnica.com/security/2014/04/heartbleed-vulnerability-may-have-be...
"Terrence Koeman of MediaMonks told Ars he found signs of attempts to use the exploit dating back to November 2013. He used the packet content of a successful exploit of the Heartbleed vulnerability to check inbound packets logged by his servers and found a number of incoming packets from a network suspected of harboring a number of “bot” servers that were apparently scans for the vulnerability—sending Heartbleed-style requests to two different development servers in requests that were about five minutes apart."
So this was either cyber criminals or the NSA. I'll assume it was cyber criminals, but who knows.
Regardless, someone was scanning for the vulnerability 5 months ago. And this is not a complex vulnerability to leverage, once you find a vulnerable server, just keep sending authentication requests with invalid credentials. Using a spread out botnet defeats fail2ban style defenses.
My personal opinion is the world's governments should treat this as a global catastrophe and pay to have every credit card on the planet reissued at a minimum.
Greg
Your assertion that this is not a complex vulnerability to leverage may need some proof. People who have tried to leverage it have not been very successful. See http://blog.cloudflare.com/answering-the-critical-question-can-you-get-priva... You might get something, but deliberate attempts to do so are harder than you seem to think. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Fri, 11 Apr 2014 22:00:37 -0700 John M Andersen <jsamyth@gmail.com> пишет:
Your assertion that this is not a complex vulnerability to leverage may need some proof. People who have tried to leverage it have not been very successful. See http://blog.cloudflare.com/answering-the-critical-question-can-you-get-priva...
Thanks, interesting link.
You might get something, but deliberate attempts to do so are harder than you seem to think.
Better safe than sorry ... :) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On April 12, 2014 1:00:37 AM EDT, John M Andersen <jsamyth@gmail.com> wrote:
On 4/11/2014 7:15 PM, Greg Freemyer wrote:
Lew From: http://arstechnica.com/security/2014/04/heartbleed-vulnerability-may-have-be...
"Terrence Koeman of MediaMonks told Ars he found signs of attempts to use the exploit dating back to November 2013. He used the packet content of a successful exploit of the Heartbleed vulnerability to check inbound packets logged by his servers and found a number of incoming packets from a network suspected of harboring a number of “bot” servers that were apparently scans for the vulnerability—sending Heartbleed-style requests to two different development servers in requests that were about five minutes apart."
So this was either cyber criminals or the NSA. I'll assume it was cyber criminals, but who knows.
Regardless, someone was scanning for the vulnerability 5 months ago. And this is not a complex vulnerability to leverage, once you find a vulnerable server, just keep sending authentication requests with invalid credentials. Using a spread out botnet defeats fail2ban style defenses.
My personal opinion is the world's governments should treat this as a global catastrophe and pay to have every credit card on the planet reissued at a minimum.
Greg
Your assertion that this is not a complex vulnerability to leverage may
need some proof. People who have tried to leverage it have not been very successful. See http://blog.cloudflare.com/answering-the-critical-question-can-you-get-priva...
You might get something, but deliberate attempts to do so are harder than you seem to think.
Did you see the note at the top of the article. They retract the whole thing because 2 independent testers got the ssl private key from their test site within 9 hours of the test starting. They now recommend everyone (on the planet?) revoke their private keys and get new ones re-issued. They say the heartbleed attack is like panning for gold. Most times you reach down a get some dirt, you get dirt, other times there is a nugget in there. In this case the logins/passwords/credit cards would be little bits of gold nugget, and a ssl private key would be decent size diamond. In the above test, one guy found the diamond (the ssl private key) after only 100,000 pans of dirt. The other took 2.5 million. With a 1,000 node botnet, that is only 2,500 pans of dirt each. For a cyber criminal, that is an almost trivial amount of work. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 12/04/2014 14:24, Greg Freemyer a écrit :
For a cyber criminal, that is an almost trivial amount of work.
but on how many targets? if somebody get my server's private key, he wont be rich... jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, Apr 12, 2014 at 9:29 AM, jdd <jdd@dodin.org> wrote:
Le 12/04/2014 14:24, Greg Freemyer a écrit :
For a cyber criminal, that is an almost trivial amount of work.
but on how many targets?
if somebody get my server's private key, he wont be rich...
jdd
If it's a self-generated key, you can re-create it in 10 or 15 minutes including doing the research of how to do it. If what you're protecting isn't worth a 15 minute investment, then I wouldn't bother with re-creating it. If it's one you paid for, then if it was worth buying, I assume it is worth revoking / re-issuing. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 12/04/2014 17:52, Greg Freemyer a écrit :
If it's a self-generated key, you can re-create it in 10 or 15 minutes including doing the research of how to do it. If what you're protecting isn't worth a 15 minute investment, then I wouldn't bother with re-creating it.
yes, but I have to propagate it to the clients and verify it works,, that is reread the doc and understand it :-( jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, Apr 12, 2014 at 12:01 PM, jdd <jdd@dodin.org> wrote:
Le 12/04/2014 17:52, Greg Freemyer a écrit :
If it's a self-generated key, you can re-create it in 10 or 15 minutes including doing the research of how to do it. If what you're protecting isn't worth a 15 minute investment, then I wouldn't bother with re-creating it.
yes, but I have to propagate it to the clients and verify it works,, that is reread the doc and understand it :-(
Am I missing something? Only SSL keys are in question to my understanding. SSL private keys are not propagated at all (unless you have a web farm / high availability cluster). SSL public keys are pushed by the protocol automatically. Nothing for you to do. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 12/04/2014 18:20, Greg Freemyer a écrit :
SSL public keys are pushed by the protocol automatically. Nothing for you to do.
not for rsync backups jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/12/2014 09:30 AM, jdd wrote:
Le 12/04/2014 18:20, Greg Freemyer a écrit :
SSL public keys are pushed by the protocol automatically. Nothing for you to do.
not for rsync backups
Doesn't rsync ride on the SSH protocol? SSH keys aren't affected by Heartbleed AFAIK. I guess you could use stunnel with rsync, but I think there might be other issues there. Regrds, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 12/04/14 13:51, Lew Wolfgang escribió:
On 04/12/2014 09:30 AM, jdd wrote:
Le 12/04/2014 18:20, Greg Freemyer a écrit :
SSL public keys are pushed by the protocol automatically. Nothing for you to do.
not for rsync backups
Doesn't rsync ride on the SSH protocol? SSH keys aren't affected by Heartbleed AFAIK. I guess you could use stunnel with rsync, but I think there might be other issues there.
Regrds, Lew
SSH does not use TLS. -- Cristian "I don't know the key to success, but the key to failure is trying to please everybody." -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 12/04/2014 18:51, Lew Wolfgang a écrit :
Doesn't rsync ride on the SSH protocol?
yes SSH keys aren't
affected by Heartbleed AFAIK.
oh... it's ok then thanks jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, Apr 12, 2014 at 12:30 PM, jdd <jdd@dodin.org> wrote:
Le 12/04/2014 18:20, Greg Freemyer a écrit :
SSL public keys are pushed by the protocol automatically. Nothing for you to do.
not for rsync backups
jdd
hmm... I've only used rsync via ssh, so I have no insight as to how the openssl vulnerability impacts rsync. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer wrote:
On Sat, Apr 12, 2014 at 12:30 PM, jdd <jdd@dodin.org> wrote:
Le 12/04/2014 18:20, Greg Freemyer a écrit :
SSL public keys are pushed by the protocol automatically. Nothing for you to do.
not for rsync backups
jdd
hmm...
I've only used rsync via ssh, so I have no insight as to how the openssl vulnerability impacts rsync.
I don't see any impact on rsync. With ssh, no impact, and rsyncd? does not use libssl. -- Per Jessen, Zürich (15.1°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer wrote:
On April 11, 2014 8:25:31 AM EDT, Per Jessen <per@computer.org> wrote:
Greg Freemyer wrote:
On April 11, 2014 6:45:54 AM EDT, "Vojtěch Zeisek" <vojtech.zeisek@opensuse.org> wrote:
Dear openSUSE on-line friend, how do You test Your servers to ensure they weren't compromised? I have to say I have no idea at all... :-/ Good luck, Vojtěch
It's not easy:
Try this: http://filippo.io/Heartbleed/
There is also a command-line version.
You answered a different question.
E.g.
You answered "how can I tell if I am currently vulnerable?"
I think the question was "how can I tell if I was compromised in the 2 years between this bug / vulnerability being introduced and today?"
I tried to answer the second question.
You're right, I misread the question. -- Per Jessen, Zürich (19.4°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (16)
-
Andrey Borzenkov -
Bernhard Voelker -
Carlos E. R. -
Carlos E. R. -
Christopher Myers -
Cristian Rodríguez -
Greg Freemyer -
Hans Witvliet -
jdd -
Joachim Schrod -
John M Andersen -
Lew Wolfgang -
Marcus Meissner -
Per Jessen -
Ted Byers -
Vojtěch Zeisek