I gotta say....I'm so impressed with the way this issue has been handled by the developers here @ Fedora....I've updated all three of my Fedora boxes....and will sleep soundly knowing the vulnerability has been addressed by the best and brightest! So a heart felt "Thank You" to the Guys and Gals who have dedicated their time to creating the BEST operating system to ever grace my Dell computers!!!
----- Reply message ----- From: "Dan Thurman" dant@cdkkt.com To: "Community support for Fedora users" users@lists.fedoraproject.org Subject: Serious OpenSSL vulnerability Date: Wed, Apr 9, 2014 2:52 pm
On 04/08/2014 02:55 AM, Patrick O'Callaghan wrote:
https://www.openssl.org/news/secadv_20140407.txt
See also http://heartbleed.com/ and http://arstechnica.com/security/2014/04/critical-crypto-bug-in-openssl-opens...
This is potentially very serious and can cause leakage of private keys and other information.
The current version of OpenSSL on Fedora (standard repos and Koji) is 1.0.1e, which has this vulnerability. An upgrade to 1.0.1g should be provided urgently.
poc
I know that F18 is EOL & vulnerable, so can I backport OpenSSL with a fix? I am' not ready to upgrade at this time...
Dan
On Wed, 2014-04-09 at 18:30 -0400, eoconnor25@gmail.com wrote:
I gotta say....I'm so impressed with the way this issue has been handled by the developers here @ Fedora....I've updated all three of my Fedora boxes....and will sleep soundly knowing the vulnerability has been addressed by the best and brightest!
Did you also change your passwords on every vulnerable site which has since been fixed?
[Also: no top-posting on this list etc. etc.]
poc
On 4/9/2014 3:30 PM, eoconnor25@gmail.com wrote:
I gotta say....I'm so impressed with the way this issue has been handled by the developers here @ Fedora....I've updated all three of my Fedora boxes....and will sleep soundly knowing the vulnerability has been addressed by the best and brightest! So a heart felt "Thank You" to the Guys and Gals who have dedicated their time to creating the BEST operating system to ever grace my Dell computers!!!
You may also want to create new private key, buy a new cert from CA and install the new key. for each website supporting OpenSSL and change the passwords. since this problem existed for two years and there is not really way to detect, if it was exploited by someone.
On 04/09/2014 08:14 PM, Patrick O'Callaghan wrote:
On Wed, 2014-04-09 at 18:30 -0400, eoconnor25@gmail.com wrote:
I gotta say....I'm so impressed with the way this issue has been handled by the developers here @ Fedora....I've updated all three of my Fedora boxes....and will sleep soundly knowing the vulnerability has been addressed by the best and brightest!
Did you also change your passwords on every vulnerable site which has since been fixed?
[Also: no top-posting on this list etc. etc.]
poc
My apologies for the top post, but when that was sent it was from my Android phone and there's no real way to tell when I'm replying to a message as to whether it's top posting or not. As for changing passwords?...done. Thanks for the recommendations and advice!
EGO II
On Thu, 2014-04-10 at 04:48 -0400, EGO.II-1 wrote:
My apologies for the top post, but when that was sent it was from my Android phone and there's no real way to tell when I'm replying to a message as to whether it's top posting or not.
If you use the Gmail app on the phone, after hitting Reply there's a button labeled Respond Inline. That will put your reply below the quoted material.
poc
Btw, NPR reports that https://lastpass.com/heartbleed/ will inform you whether the site uses OpenSSL and whether it has been updated with the patched version.
Not all the sites that I use appear to have been patched:-(
HTH, Ranjan
____________________________________________________________ FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop! Check it out at http://www.inbox.com/earth
On Thu, Apr 10, 2014 at 13:33:29 +0100, Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Thu, 2014-04-10 at 04:48 -0400, EGO.II-1 wrote:
My apologies for the top post, but when that was sent it was from my Android phone and there's no real way to tell when I'm replying to a message as to whether it's top posting or not.
If you use the Gmail app on the phone, after hitting Reply there's a button labeled Respond Inline. That will put your reply below the quoted material.
If you do that, please trim the quoted material. Bottom posting without trimming can be worse than top posting in some cases.
On Thu, 10 Apr 2014 08:16:19 -0500 Bruno Wolff III bruno@wolff.to wrote:
On Thu, Apr 10, 2014 at 13:33:29 +0100, Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Thu, 2014-04-10 at 04:48 -0400, EGO.II-1 wrote:
My apologies for the top post, but when that was sent it was from my Android phone and there's no real way to tell when I'm replying to a message as to whether it's top posting or not.
If you use the Gmail app on the phone, after hitting Reply there's a button labeled Respond Inline. That will put your reply below the quoted material.
If you do that, please trim the quoted material. Bottom posting without trimming can be worse than top posting in some cases. --
I completely agree!
Ranjan
____________________________________________________________ Protect your computer files with professional cloud backup. Get PCRx Backup and upload unlimited files automatically. Learn more at http://backup.pcrx.com/mail
Allegedly, on or about 10 April 2014, Patrick O'Callaghan sent:
Did you also change your passwords on every vulnerable site which has since been fixed?
That will be a major pain. The one address offered to check whether a service was patched was overloaded when I tried it, and probably always will be. So you go around changing all passwords, to be safe. And will have to continue doing that until you're sure that it's safe (which is never, really).
I wonder what the outcome will be if your bank account gets ripped off due to this, for example. Can you hold the bank liable, or are they going to say it's your problem? My simple look at the information provided looks like it's a server and client problem.
On Thu, 2014-04-10 at 08:16 -0500, Bruno Wolff III wrote:
On Thu, Apr 10, 2014 at 13:33:29 +0100, Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Thu, 2014-04-10 at 04:48 -0400, EGO.II-1 wrote:
My apologies for the top post, but when that was sent it was from my Android phone and there's no real way to tell when I'm replying to a message as to whether it's top posting or not.
If you use the Gmail app on the phone, after hitting Reply there's a button labeled Respond Inline. That will put your reply below the quoted material.
If you do that, please trim the quoted material. Bottom posting without trimming can be worse than top posting in some cases.
Agreed. Unfortunately the app doesn't support the "quote only the selected text" trick.
poc
On Thu, 2014-04-10 at 23:27 +0930, Tim wrote:
Allegedly, on or about 10 April 2014, Patrick O'Callaghan sent:
Did you also change your passwords on every vulnerable site which has since been fixed?
That will be a major pain. The one address offered to check whether a service was patched was overloaded when I tried it, and probably always will be. So you go around changing all passwords, to be safe. And will have to continue doing that until you're sure that it's safe (which is never, really).
I wonder what the outcome will be if your bank account gets ripped off due to this, for example. Can you hold the bank liable, or are they going to say it's your problem? My simple look at the information provided looks like it's a server and client problem.
It's going to be difficult to demonstrate either way as the attack normally leaves no traces.
poc
On 10 April 2014 15:13, Patrick O'Callaghan pocallaghan@gmail.com wrote:
Agreed. Unfortunately the app doesn't support the "quote only the selected text" trick.
True, it doesn't. You can block-select stuff to delete, though.
On 10 April 2014 14:57, Tim ignored_mailbox@yahoo.com.au wrote:
Allegedly, on or about 10 April 2014, Patrick O'Callaghan sent:
Did you also change your passwords on every vulnerable site which has since been fixed?
That will be a major pain. The one address offered to check whether a service was patched was overloaded when I tried it, and probably always will be. So you go around changing all passwords, to be safe. And will have to continue doing that until you're sure that it's safe (which is never, really).
See http://www.theatlantic.com/technology/archive/2014/04/how-to-check-if-a-site... for a couple of sites that can be used to test, there are probably others.
I wonder what the outcome will be if your bank account gets ripped off due to this, for example. Can you hold the bank liable, or are they going to say it's your problem? My simple look at the information provided looks like it's a server and client problem.
Interestingly as the result of one of those test suites I know know that although one of the banks I use doesn't currently have the heartbleed bug they do have a different problematic vulnerability, and will shortly be getting an email about it.
On 04/10/14 20:54, Ian Malone wrote:
On 10 April 2014 14:57, Tim ignored_mailbox@yahoo.com.au wrote:
Allegedly, on or about 10 April 2014, Patrick O'Callaghan sent:
Did you also change your passwords on every vulnerable site which has since been fixed?
That will be a major pain. The one address offered to check whether a service was patched was overloaded when I tried it, and probably always will be. So you go around changing all passwords, to be safe. And will have to continue doing that until you're sure that it's safe (which is never, really).
See http://www.theatlantic.com/technology/archive/2014/04/how-to-check-if-a-site...
for a couple of sites that can be used to test, there are probably others.
I wonder what the outcome will be if your bank account gets ripped off due to this, for example. Can you hold the bank liable, or are they going to say it's your problem? My simple look at the information provided looks like it's a server and client problem.
Interestingly as the result of one of those test suites I know know that although one of the banks I use doesn't currently have the heartbleed bug they do have a different problematic vulnerability, and will shortly be getting an email about it.
above link gave 2 test sites. 1st gave no response, 2nd gave a grade of 'B' and said site i was checking was not not vulnerable to heartbleed attack.
all of which brings to question, if one does not store passwords for critical sites, does it matter?
On 4/10/2014 3:07 PM, g wrote:
On 04/10/14 20:54, Ian Malone wrote:
On 10 April 2014 14:57, Tim ignored_mailbox@yahoo.com.au wrote:
Allegedly, on or about 10 April 2014, Patrick O'Callaghan sent:
Did you also change your passwords on every vulnerable site which has since been fixed?
That will be a major pain. The one address offered to check whether a service was patched was overloaded when I tried it, and probably always will be. So you go around changing all passwords, to be safe. And will have to continue doing that until you're sure that it's safe (which is never, really).
See http://www.theatlantic.com/technology/archive/2014/04/how-to-check-if-a-site...
for a couple of sites that can be used to test, there are probably others.
I wonder what the outcome will be if your bank account gets ripped off due to this, for example. Can you hold the bank liable, or are they going to say it's your problem? My simple look at the information provided looks like it's a server and client problem.
Interestingly as the result of one of those test suites I know know that although one of the banks I use doesn't currently have the heartbleed bug they do have a different problematic vulnerability, and will shortly be getting an email about it.
above link gave 2 test sites. 1st gave no response, 2nd gave a grade of 'B' and said site i was checking was not not vulnerable to heartbleed attack.
all of which brings to question, if one does not store passwords for critical sites, does it matter?
Does not *the site* store your password?
On 04/11/14 01:22, David wrote:
On 4/10/2014 3:07 PM, g wrote:
<<>>
above link gave 2 test sites. 1st gave no response, 2nd gave a grade of 'B' and said site i was checking was not not vulnerable to heartbleed attack.
all of which brings to question, if one does not store passwords for critical sites, does it matter?
Does not *the site* store your password?
well, yes. unless site stores a cookie with my browser and decrypts cookie to determine if i am who i say i am.
also, i guess there is something i have not read or missed in reading too fast about this heartbleed bug.
would you have a suggestion of a link that give a good detailed description of what bug is all about and how some sites are effected while others are not?
On 4/10/2014 3:49 PM, g wrote:
On 04/11/14 01:22, David wrote:
On 4/10/2014 3:07 PM, g wrote:
<<>>
above link gave 2 test sites. 1st gave no response, 2nd gave a grade of 'B' and said site i was checking was not not vulnerable to heartbleed attack.
all of which brings to question, if one does not store passwords for critical sites, does it matter?
Does not *the site* store your password?
well, yes. unless site stores a cookie with my browser and decrypts cookie to determine if i am who i say i am.
also, i guess there is something i have not read or missed in reading too fast about this heartbleed bug.
would you have a suggestion of a link that give a good detailed description of what bug is all about and how some sites are effected while others are not?
Sure. Explained as simply (non geeky) as i have seen.
"The Heartbleed Bug"
On 04/11/14 02:14, David wrote: <<>> On 4/10/2014 3:49 PM, g wrote:
would you have a suggestion of a link that give a good detailed description of what bug is all about and how some sites are effected while others are not?
Sure. Explained as simply (non geeky) as i have seen.
"The Heartbleed Bug"
ok. been there. read it.
in following the links in the "theatlantic.com/technology/" article, mainly;
https://lastpass.com/heartbleed/ http://possible.lv/tools/hb/ https://www.ssllabs.com/ssltest/
my main concern for security is with my bank, and norton/symantec, which at all 3 of above links;
bank = 'not vulnerable', and ssllabs gives a "B"
us.norton = 'not vulnerable', and ssllabs gives a "F"
symantec.com = "Warning: Inconsistent server configuration" and grades of "F", "B", "B"
grc.com = "A+", "A+"
with above, i do not believe i will worry about my passwords for tech support groups that i subscribe.
like, what would some crazy do with such anyway?
layout for passwords for above 4 sites is totally different from what i use for support groups and non tech list.
to quote a childhood idle, Alfred E Newman, "What? Me worry?"
thanks. have a great one.
On 10/04/14 14:59, Edward M wrote:
On 4/9/2014 3:30 PM, eoconnor25@gmail.com wrote:
I gotta say....I'm so impressed with the way this issue has been handled by the developers here @ Fedora....I've updated all three of my Fedora boxes....and will sleep soundly knowing the vulnerability has been addressed by the best and brightest! So a heart felt "Thank You" to the Guys and Gals who have dedicated their time to creating the BEST operating system to ever grace my Dell computers!!!
You may also want to create new private key, buy a new cert
from CA and install the new key. for each website supporting OpenSSL and change the passwords. since this problem existed for two years and there is not really way to detect, if it was exploited by someone.
I too heartily agree with the above. Added to this, my isp sent an email to advise that they too had addressed the issue. We are fortunate in Open source and Linux to have such talented developers to pounce on and fix such issues. Thank you Roger
On 4/10/2014 5:32 PM, g wrote:
On 04/11/14 02:14, David wrote: <<>> On 4/10/2014 3:49 PM, g wrote:
would you have a suggestion of a link that give a good detailed description of what bug is all about and how some sites are effected while others are not?
Sure. Explained as simply (non geeky) as i have seen.
"The Heartbleed Bug"
ok. been there. read it.
in following the links in the "theatlantic.com/technology/" article, mainly;
https://lastpass.com/heartbleed/ http://possible.lv/tools/hb/ https://www.ssllabs.com/ssltest/
my main concern for security is with my bank, and norton/symantec, which at all 3 of above links;
bank = 'not vulnerable', and ssllabs gives a "B"
us.norton = 'not vulnerable', and ssllabs gives a "F"
symantec.com = "Warning: Inconsistent server configuration" and grades of "F", "B", "B"
grc.com = "A+", "A+"
with above, i do not believe i will worry about my passwords for tech support groups that i subscribe.
like, what would some crazy do with such anyway?
layout for passwords for above 4 sites is totally different from what i use for support groups and non tech list.
to quote a childhood idle, Alfred E Newman, "What? Me worry?"
thanks. have a great one.
Sure. I would not really *greatly* care about tech sites password. I would be (was) concerned about my 'money' sites. The sites had to used openssl. Which would be any Apache and another one that I can not recall at the moment.
But? This time the 'ten feet tall and bullet proof because I use Linux' Bull$$hit failed. This one is Linux centered. Period. A programer created this and added it to the code. And 'free and a no money' supported program mistake not caught for about two years.
IMHO? The problem with 'free is that you get what you pay for in the end. A group of nice people working part time for nothing. No real resources. People with real jobs that pay. Families. And 'part time support'. I tip my hat but? Sad.
On 11 April 2014 00:55, David dgboles@gmail.com wrote:
Sure. I would not really *greatly* care about tech sites password. I would be (was) concerned about my 'money' sites. The sites had to used openssl. Which would be any Apache and another one that I can not recall at the moment.
But? This time the 'ten feet tall and bullet proof because I use Linux' Bull$$hit failed. This one is Linux centered. Period. A programer created this and added it to the code. And 'free and a no money' supported program mistake not caught for about two years.
You know OpenSSL is not Linux? And that IIS could equally have had this bug? http://en.wikipedia.org/wiki/Code_Red_%28computer_worm%29 (also a good reminder for anyone who thinks vulnerabilities in the news is news)
It's also not true:
A group of nice people working part time for nothing. No real resources. People with real jobs that pay. Families. And 'part time support'. I tip my hat but? Sad.
OpenSSL do support contracts and many of the developers offer consultancy services. Painting it as something done as a part-time hobby is a bit misleading. (And why 'sad' exactly? Also N.B. it's often an insult in British English)
On 4/10/2014 8:28 PM, Ian Malone wrote:
On 11 April 2014 00:55, David dgboles@gmail.com wrote:
Sure. I would not really *greatly* care about tech sites password. I would be (was) concerned about my 'money' sites. The sites had to used openssl. Which would be any Apache and another one that I can not recall at the moment.
But? This time the 'ten feet tall and bullet proof because I use Linux' Bull$$hit failed. This one is Linux centered. Period. A programer created this and added it to the code. And 'free and a no money' supported program mistake not caught for about two years.
You know OpenSSL is not Linux? And that IIS could equally have had this bug? http://en.wikipedia.org/wiki/Code_Red_%28computer_worm%29 (also a good reminder for anyone who thinks vulnerabilities in the news is news)
It's also not true:
A group of nice people working part time for nothing. No real resources. People with real jobs that pay. Families. And 'part time support'. I tip my hat but? Sad.
OpenSSL do support contracts and many of the developers offer consultancy services. Painting it as something done as a part-time hobby is a bit misleading. (And why 'sad' exactly? Also N.B. it's often an insult in British English)
Wow! Really?? Then you really need to talk to everyone that is saying that. Now!!
On 11 April 2014 01:45, David dgboles@gmail.com wrote:
On 4/10/2014 8:28 PM, Ian Malone wrote:
On 11 April 2014 00:55, David dgboles@gmail.com wrote:
Sure. I would not really *greatly* care about tech sites password. I would be (was) concerned about my 'money' sites. The sites had to used openssl. Which would be any Apache and another one that I can not recall at the moment.
But? This time the 'ten feet tall and bullet proof because I use Linux' Bull$$hit failed. This one is Linux centered. Period. A programer created this and added it to the code. And 'free and a no money' supported program mistake not caught for about two years.
You know OpenSSL is not Linux? And that IIS could equally have had this bug? http://en.wikipedia.org/wiki/Code_Red_%28computer_worm%29 (also a good reminder for anyone who thinks vulnerabilities in the news is news)
It's also not true:
A group of nice people working part time for nothing. No real resources. People with real jobs that pay. Families. And 'part time support'. I tip my hat but? Sad.
OpenSSL do support contracts and many of the developers offer consultancy services. Painting it as something done as a part-time hobby is a bit misleading. (And why 'sad' exactly? Also N.B. it's often an insult in British English)
Wow! Really?? Then you really need to talk to everyone that is saying that. Now!!
Thought I'd provide the information. Do with it what you will.
On 11 April 2014 10:11, Ian Malone ibmalone@gmail.com wrote:
On 11 April 2014 01:45, David dgboles@gmail.com wrote:
On 4/10/2014 8:28 PM, Ian Malone wrote:
On 11 April 2014 00:55, David dgboles@gmail.com wrote:
Sure. I would not really *greatly* care about tech sites password. I would be (was) concerned about my 'money' sites. The sites had to used openssl. Which would be any Apache and another one that I can not recall at the moment.
But? This time the 'ten feet tall and bullet proof because I use Linux' Bull$$hit failed. This one is Linux centered. Period. A programer created this and added it to the code. And 'free and a no money' supported program mistake not caught for about two years.
You know OpenSSL is not Linux? And that IIS could equally have had this bug? http://en.wikipedia.org/wiki/Code_Red_%28computer_worm%29 (also a good reminder for anyone who thinks vulnerabilities in the news is news)
It's also not true:
A group of nice people working part time for nothing. No real resources. People with real jobs that pay. Families. And 'part time support'. I tip my hat but? Sad.
OpenSSL do support contracts and many of the developers offer consultancy services. Painting it as something done as a part-time hobby is a bit misleading. (And why 'sad' exactly? Also N.B. it's often an insult in British English)
Wow! Really?? Then you really need to talk to everyone that is saying that. Now!!
Thought I'd provide the information. Do with it what you will.
PS: I have no idea where you are from and try to assume people are decent human beings until proven otherwise.
On 11/04/14 17:11, Ian Malone wrote:
On 11 April 2014 01:45, David dgboles@gmail.com wrote:
On 4/10/2014 8:28 PM, Ian Malone wrote:
On 11 April 2014 00:55, David dgboles@gmail.com wrote:
Sure. I would not really *greatly* care about tech sites password. I would be (was) concerned about my 'money' sites. The sites had to used openssl. Which would be any Apache and another one that I can not recall at the moment.
But? This time the 'ten feet tall and bullet proof because I use Linux' Bull$$hit failed. This one is Linux centered. Period. A programer created this and added it to the code. And 'free and a no money' supported program mistake not caught for about two years.
You know OpenSSL is not Linux? And that IIS could equally have had this bug? http://en.wikipedia.org/wiki/Code_Red_%28computer_worm%29 (also a good reminder for anyone who thinks vulnerabilities in the news is news)
It's also not true:
A group of nice people working part time for nothing. No real resources. People with real jobs that pay. Families. And 'part time support'. I tip my hat but? Sad.
OpenSSL do support contracts and many of the developers offer consultancy services. Painting it as something done as a part-time hobby is a bit misleading. (And why 'sad' exactly? Also N.B. it's often an insult in British English)
Wow! Really?? Then you really need to talk to everyone that is saying that. Now!!
Thought I'd provide the information. Do with it what you will.
Although I am not British, I thought I was reasonably well-informed about British colloquialisms, and I am unaware of "sad" being used as an insult. I guess that to call someone a "sad case" is an insult, but "sad" on its own is different.
Are you sure you didn't mean "sod"? :-)
cheers,
Rolf Turner
Around 12:36pm on Friday, April 11, 2014 (UK time), Rolf Turner wrote:
Although I am not British, I thought I was reasonably well-informed about British colloquialisms, and I am unaware of "sad" being used as an insult. I guess that to call someone a "sad case" is an insult, but "sad" on its own is different.
Are you sure you didn't mean "sod"? :-)
I am British (English) and calling someone sad is a minor insult. Usually implying they are unpopular or have no social skills - "The sad bastard is staying in on Friday night".
It still retains its official meaning too.
Steve
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/11/14 08:37, Steve Searle wrote:
Are you sure you didn't mean "sod"? :-)
I am British (English) and calling someone sad is a minor insult. Usually implying they are unpopular or have no social skills - "The sad bastard is staying in on Friday night".
It still retains its official meaning too.
Steve
This reminds me of the Black Adder episode where Baldrick is applying to be an MP and Black Adder asks him his first name. He says 'Sod Off' because that everyone was always telling him to 'sod off Baldrick'.
Being American, I'm not sure if that makes me 'sad' or not.
- -- Mark Haney Network/Systems Administrator Practichem W: (919) 714-8428 Fedora release 20 (Heisenbug) 3.13.6-200.fc20.x86_64
On Fri, 11 Apr 2014, Steve Searle wrote:
Around 12:36pm on Friday, April 11, 2014 (UK time), Rolf Turner wrote:
Although I am not British, I thought I was reasonably well-informed about British colloquialisms, and I am unaware of "sad" being used as an insult. I guess that to call someone a "sad case" is an insult, but "sad" on its own is different.
Are you sure you didn't mean "sod"? :-)
I am British (English) and calling someone sad is a minor insult. Usually implying they are unpopular or have no social skills - "The sad bastard is staying in on Friday night".
It still retains its official meaning too.
Steve
Just goes to show that no matter how hard you try not to offend, if someone wants to be offended badly enough, he or she can manage it.
billo
Allegedly, on or about 11 April 2014, Bill Oliver sent:
Just goes to show that no matter how hard you try not to offend, if someone wants to be offended badly enough, he or she can manage it.
I think the mailing list is missing a sound track. Right now, it'd be alternating between laugh track, and wah waaah waa-a-a--a-aahhhh...
On Sat, 12 Apr 2014, Tim wrote:
Allegedly, on or about 11 April 2014, Bill Oliver sent:
Just goes to show that no matter how hard you try not to offend, if someone wants to be offended badly enough, he or she can manage it.
I think the mailing list is missing a sound track. Right now, it'd be alternating between laugh track, and wah waaah waa-a-a--a-aahhhh...
Now, that's just sad.
billo
On 4/11/2014 2:37 PM, Tim wrote:
Allegedly, on or about 11 April 2014, Bill Oliver sent:
Just goes to show that no matter how hard you try not to offend, if someone wants to be offended badly enough, he or she can manage it.
I think the mailing list is missing a sound track. Right now, it'd be alternating between laugh track, and wah waaah waa-a-a--a-aahhhh...
And a this prominent organization is now missing something;-)
http://www.businessweek.com/news/2014-04-11/nsa-said-to-have-used-heartbleed...
Just goes to show that no matter how hard you try not to offend, if someone wants to be offended badly enough, he or she can manage it.
To quote Buzz Lightyear in Toy Story, he is looking at Woody and says "You are a sad little man" Funny how that "sad" needed no explanation and elicited no response from a global audience. Can it be that the eye and feelings of the beholder is too prevalent in this discussion and analysing to this extent is "going overboard" ,a total waste of time and somewhat away from core discussion about Linux/Fedora.
Maybe analysis of sad can be moved to another forum. Thanks Roger
It happened. It was known for years. It is fixed. Job done
Roger wrote:
It happened. It was known for years.
Everything I have seen says it has been known for about 1 week.
Incidentally, I am no programmer but I would have thought it would be relatively simple to set up a test to see if a "malloc"-ed space could be transgressed.
Hi
On Sun, Apr 13, 2014 at 6:23 AM, Timothy Murphy wrote:
Roger wrote:
It happened. It was known for years.
Everything I have seen says it has been known for about 1 week.
Incidentally, I am no programmer but I would have thought it would be relatively simple to set up a test to see if a "malloc"-ed space could be transgressed.
Not in this case. openssl uses a custom malloc
Rahul
On Sun, 13 Apr 2014 09:15:04 -0400 Rahul Sundaram metherid@gmail.com wrote:
Hi
On Sun, Apr 13, 2014 at 6:23 AM, Timothy Murphy wrote:
Roger wrote:
It happened. It was known for years.
Everything I have seen says it has been known for about 1 week.
Incidentally, I am no programmer but I would have thought it would be relatively simple to set up a test to see if a "malloc"-ed space could be transgressed.
Not in this case. openssl uses a custom malloc
So, a valgrind -tool=memcheck --leak-check=yes --show-reachable=yes --track-fds=yes --track-origins=yes would not have helped?
Ranjan
____________________________________________________________ FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your desktop! Check it out at http://www.inbox.com/marineaquarium
On Sun, Apr 13, 2014 at 08:38:11AM -0500, Ranjan Maitra wrote:
On Sun, 13 Apr 2014 09:15:04 -0400 Rahul Sundaram metherid@gmail.com wrote:
Hi
On Sun, Apr 13, 2014 at 6:23 AM, Timothy Murphy wrote:
Roger wrote:
It happened. It was known for years.
Everything I have seen says it has been known for about 1 week.
Incidentally, I am no programmer but I would have thought it would be relatively simple to set up a test to see if a "malloc"-ed space could be transgressed.
Not in this case. openssl uses a custom malloc
So, a valgrind -tool=memcheck --leak-check=yes --show-reachable=yes --track-fds=yes --track-origins=yes would not have helped?
AFAIU this is not a memory leak; it is a buffer overflow: lack of bounds checking. I do not think valgrind (or any other tool) can help with that. Feel free to correct me if I am wrong.
Cheers,
Hi
On Sun, Apr 13, 2014 at 9:38 AM, Ranjan Maitra wrote:
So, a valgrind -tool=memcheck --leak-check=yes --show-reachable=yes --track-fds=yes --track-origins=yes would not have helped?
Correct. GCC -fstack-protecter-all might help. Also valgrind runs are costly so a lot of people don't use it despite being a very useful tool. GCC 4.9 (Rawhide) has a couple of options which can help
https://lists.fedoraproject.org/pipermail/devel/2014-April/197754.html
Rahul
Suvayu Ali writes:
On Sun, Apr 13, 2014 at 08:38:11AM -0500, Ranjan Maitra wrote:
On Sun, 13 Apr 2014 09:15:04 -0400 Rahul Sundaram metherid@gmail.com wrote:
Hi
On Sun, Apr 13, 2014 at 6:23 AM, Timothy Murphy wrote:
Roger wrote:
It happened. It was known for years.
Everything I have seen says it has been known for about 1 week.
Incidentally, I am no programmer but I would have thought it would be relatively simple to set up a test to see if a "malloc"-ed space could be transgressed.
Not in this case. openssl uses a custom malloc
So, a valgrind -tool=memcheck --leak-check=yes --show-reachable=yes --track-fds=yes --track-origins=yes would not have helped?
AFAIU this is not a memory leak; it is a buffer overflow: lack of bounds checking. I do not think valgrind (or any other tool) can help with that. Feel free to correct me if I am wrong.
For this particular vulnerability, it is not technically a buffer overflow. The vulnerable code merely reads past the end of an allocated buffer. A buffer overflow gets exploited by writing past the allocated buffer.
If you want to classify this, the best classification here would be an information leak, and not a buffer overflow.
The chances of valgrind catching this exploit are quite small. The only possible way I see valgrind could've complained would be if the original buffer that was allocated for the TLS ping message got padded by malloc() by a non-significant amount, and valgrind would've complained about reading uninitialized memory.
And ven in that case, valgrind() tends to complain about uninitialized memory only if its value is used to branch on. There's lots of code that ends up reading uninitialized memory without resulting in undefined behavior, for one reason or another. valgrind() doesn't typically complain reading a few uninitialized bytes after a range that's been legally malloc()ed, unless its value is used for branching, or something.
On Sun, 13 Apr 2014 15:48:23 +0200 Suvayu Ali <fatkasuvayu +linux@gmail.com> wrote:
On Sun, Apr 13, 2014 at 08:38:11AM -0500, Ranjan Maitra wrote:
On Sun, 13 Apr 2014 09:15:04 -0400 Rahul Sundaram metherid@gmail.com wrote:
Hi
On Sun, Apr 13, 2014 at 6:23 AM, Timothy Murphy wrote:
Roger wrote:
It happened. It was known for years.
Everything I have seen says it has been known for about 1 week.
Incidentally, I am no programmer but I would have thought it would be relatively simple to set up a test to see if a "malloc"-ed space could be transgressed.
Not in this case. openssl uses a custom malloc
So, a valgrind -tool=memcheck --leak-check=yes --show-reachable=yes --track-fds=yes --track-origins=yes would not have helped?
AFAIU this is not a memory leak; it is a buffer overflow: lack of bounds checking. I do not think valgrind (or any other tool) can help with that. Feel free to correct me if I am wrong.
Actually, in my experience, valgrind has picked up everything pretty much, including (amazingly!) logically incorrect statements (even when there was no memory leak). In other words, it reports no leaks possible but some errors. And if you go look with the -v option (on a -g compiled executable) one gets the line number and finds errors from there.
Of course, I understand that this is no guarantee.
Here is an example (on F20):
/* file: testrealloc.c (note the access in the last element) */
#include <stdio.h> #include <stdlib.h>
int main(void) { int n = 50; double *a, *p;
a = malloc(n * sizeof( *a)); for (int i = 0; i < n; i++) a[i] = i;
p = realloc(a, (n - 2) * sizeof( *p));
for (int i = (n - 4); i < (n - 1); i++) printf("%f ", p[i]); free(p);
return EXIT_SUCCESS;
}
/* compile with:
gcc -o testrealloc testrealloc.c -std=c99 -Wall -pedantic
run valgrind:
valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --track-fds=yes --track-origins=yes -v ./testrealloc
Here are the results:
......snipped.... --12324-- REDIR: 0x35bd018380 (index) redirected to 0x4a08f60 (index) --12324-- REDIR: 0x35bd018400 (strcmp) redirected to 0x4a0a040 (strcmp) --12324-- Reading syms from /usr/lib64/libc-2.18.so --12324-- REDIR: 0x35bd489b90 (strcasecmp) redirected to 0x4801716 (_vgnU_ifunc_wrapper) --12324-- REDIR: 0x35bd48be80 (strncasecmp) redirected to 0x4801716 (_vgnU_ifunc_wrapper) --12324-- REDIR: 0x35bd489360 (memcpy@GLIBC_2.2.5) redirected to 0x4801716 (_vgnU_ifunc_wrapper) --12324-- REDIR: 0x35bd488340 (__GI_strrchr) redirected to 0x4a08d80 (__GI_strrchr) --12324-- REDIR: 0x35bd47ff10 (malloc) redirected to 0x4a063d6 (malloc) --12324-- REDIR: 0x35bd480410 (realloc) redirected to 0x4a082e0 (realloc) --12324-- REDIR: 0x35bd48fe40 (strchrnul) redirected to 0x4a0bd30 (strchrnul) --12324-- REDIR: 0x35bd4865f0 (strlen) redirected to 0x4a092f0 (strlen) ==12324== Invalid read of size 8 ==12324== at 0x4006A8: main (in /tmp/testrealloc) ==12324== Address 0x4c2a390 is 0 bytes after a block of size 384 alloc'd ==12324== at 0x4A083AA: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==12324== by 0x400684: main (in /tmp/testrealloc) ==12324== --12324-- REDIR: 0x35bd480330 (free) redirected to 0x4a074f0 (free) 46.000000 47.000000 0.000000 ==12324== ==12324== FILE DESCRIPTORS: 3 open at exit. ==12324== Open file descriptor 2: /dev/pts/8 ==12324== <inherited from parent> ==12324== ==12324== Open file descriptor 1: /dev/pts/8 ==12324== <inherited from parent> ==12324== ==12324== Open file descriptor 0: /dev/pts/8 ==12324== <inherited from parent> ==12324== ==12324== ==12324== HEAP SUMMARY: ==12324== in use at exit: 0 bytes in 0 blocks ==12324== total heap usage: 2 allocs, 2 frees, 784 bytes allocated ==12324== ==12324== All heap blocks were freed -- no leaks are possible ==12324== ==12324== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2) ==12324== ==12324== 1 errors in context 1 of 1: ==12324== Invalid read of size 8 ==12324== at 0x4006A8: main (in /tmp/testrealloc) ==12324== Address 0x4c2a390 is 0 bytes after a block of size 384 alloc'd ==12324== at 0x4A083AA: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==12324== by 0x400684: main (in /tmp/testrealloc) ==12324== --12324-- --12324-- used_suppression: 2 glibc-2.5.x-on-SUSE-10.2-(PPC)-2a /usr/lib64/valgrind/default.supp:1286 ==12324== ==12324== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
*/
Btw, there are always 2 suppressed errors (from the compiled standard library, I guess). I wish that someone could look into these).
I have become a great fan of valgrind. Of course, that in itself may be a problem if it lulls one to a false sense of complacency.
Best wishes, Ranjan
____________________________________________________________ FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your desktop! Check it out at http://www.inbox.com/marineaquarium
Date: Sun, 13 Apr 2014 15:48:23 +0200 From: fatkasuvayu+linux@gmail.com To: users@lists.fedoraproject.org Subject: Re: Serious OpenSSL vulnerability
On Sun, Apr 13, 2014 at 08:38:11AM -0500, Ranjan Maitra wrote:
On Sun, 13 Apr 2014 09:15:04 -0400 Rahul Sundaram metherid@gmail.com wrote:
Hi
On Sun, Apr 13, 2014 at 6:23 AM, Timothy Murphy wrote:
Roger wrote:
It happened. It was known for years.
Everything I have seen says it has been known for about 1 week.
Incidentally, I am no programmer but I would have thought it would be relatively simple to set up a test to see if a "malloc"-ed space could be transgressed.
Not in this case. openssl uses a custom malloc
So, a valgrind -tool=memcheck --leak-check=yes --show-reachable=yes --track-fds=yes --track-origins=yes would not have helped?
AFAIU this is not a memory leak; it is a buffer overflow: lack of bounds checking. I do not think valgrind (or any other tool) can help with that. Feel free to correct me if I am wrong.
Cheers,
-- Suvayu
Open source is the future. It sets us free.
users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Yes it's possible to compile C programs (with certain tradeoffs) to do bounds-checking with some compiler environments. I don't know if it would have protected against the heartbleed vulnerability but MemGuard possibly could have caught a simple bounds overrun. See AppArmor now maintained by Novell. Nice summary of options at http://www.seas.gwu.edu/~simhaweb/security/summer2005/Stuart2.ppt%E2%80%8E Ubuntu's chart of security features includes it but again it's unclear if OpenSSL would have been protected by it in this case: https://wiki.ubuntu.com/Security/Features There is a performance hit for enabling bounds-checking during compile time, but that seems worthwhile for infrastructure services. An early publication at: https://www.usenix.org/legacy/publications/library/proceedings/sec98/full_pa... QUOTE: Array Bounds Checking for C Richard Jones and Paul Kelly have developed a gcc patch [12] that does full array bounds checking for C programs. Programs compiled with this patch are compatible with ordinary gcc modules, because they have not changed the representation of pointers. Rather, they derive a ``base'' pointer from each pointer expression, and check the attributes of that pointer to determine whether the expression is within bounds. The performance costs are substantial: a pointer-intensive program (ijk matrix multiply) experienced tex2html_wrap_inline879 slowdown. Since the slowdown is proportionate to pointer usage, which is quite common in privileged programs, this performance penalty is particularly unfortunate. However, this method is strictly more secure than StackGuard, because it will prevent all buffer overflow attacks, not just those that attempt to alter return addresses, or other data structures that are perceived to be sensitive (see Section 5.4). Thus we propose that programs compiled with the bounds-checking compiler be treated as the ``backing store'' for MemGuard-protected programs, just as MemGuard-protected programs are the back-up plan for Canary-protected programs (see Section 3.3).
Quoting Suvayu Ali fatkasuvayu+linux@gmail.com:
On Sun, Apr 13, 2014 at 08:38:11AM -0500, Ranjan Maitra wrote:
On Sun, 13 Apr 2014 09:15:04 -0400 Rahul Sundaram metherid@gmail.com wrote:
Hi
On Sun, Apr 13, 2014 at 6:23 AM, Timothy Murphy wrote:
Roger wrote:
It happened. It was known for years.
Everything I have seen says it has been known for about 1 week.
Incidentally, I am no programmer but I would have thought it would be relatively simple to set up a test to see if a "malloc"-ed space could be transgressed.
Not in this case. openssl uses a custom malloc
So, a valgrind -tool=memcheck --leak-check=yes --show-reachable=yes --track-fds=yes --track-origins=yes would not have helped?
AFAIU this is not a memory leak; it is a buffer overflow: lack of bounds checking. I do not think valgrind (or any other tool) can help with that. Feel free to correct me if I am wrong.
Cheers,
-- Suvayu
see here: https://www.xkcd.com/
Dave
Open source is the future. It sets us free.
users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
<snip> It happened. It was known for years. </snip>
RE: request for citation.
http://www.zdnet.com/institutional-failure-led-to-nsa-missing-the-heartbleed...
<snip> It's not outside the bounds of reason to suggest that the NSA, arguably, should have found the bug within days, weeks, or even months after it was reportedly accidentally introduced into the OpenSSL cryptographic library, more than two years ago. </snip>
Roger
On Mon, 2014-04-14 at 09:36 +1000, Roger wrote:
<snip> It happened. It was known for years. </snip>
RE: request for citation.
http://www.zdnet.com/institutional-failure-led-to-nsa-missing-the-heartbleed...
<snip> It's not outside the bounds of reason to suggest that the NSA, arguably, should have found the bug within days, weeks, or even months after it was reportedly accidentally introduced into the OpenSSL cryptographic library, more than two years ago. </snip>
Obviously. That's one of the first things anyone thought of when they heard of the bug. But "not outside the bounds of reason" does not justify the bald assertion that it *was* known, even if you discount the fact that they deny having known about it.
poc
Edward M wrote, On 04/10/2014 07:59 AM (EEST):
On 4/9/2014 3:30 PM, eoconnor25@gmail.com wrote:
I gotta say....I'm so impressed with the way this issue has been handled by the developers here @ Fedora....I've updated all three of my Fedora boxes....and will sleep soundly knowing the vulnerability has been addressed by the best and brightest! So a heart felt "Thank You" to the Guys and Gals who have dedicated their time to creating the BEST operating system to ever grace my Dell computers!!!
You may also want to create new private key, buy a new cert
from CA and install the new key. for each website supporting OpenSSL and change the passwords. since this problem existed for two years and there is not really way to detect, if it was exploited by someone.
Add to that - revoke old certificate and hope the mechanism works with your user's browsers and/or other software.
Allegedly, on or about 09 April 2014, Edward M sent:
You may also want to create new private key, buy a new cert from CA and install the new key for each website supporting OpenSSL and change the passwords.
Hmm, certificate issues must be loving that - people spending money, early, replacing a certificate before it expires.
Once upon a time, Tim ignored_mailbox@yahoo.com.au said:
Allegedly, on or about 09 April 2014, Edward M sent:
You may also want to create new private key, buy a new cert from CA and install the new key for each website supporting OpenSSL and change the passwords.
Hmm, certificate issues must be loving that - people spending money, early, replacing a certificate before it expires.
Many of the CAs are not charging for reissues (keeping the same expiration I assume).
On 04/13/2014 06:23 AM, Timothy Murphy wrote:
Roger wrote:
It happened. It was known for years.
Everything I have seen says it has been known for about 1 week.
Incidentally, I am no programmer but I would have thought it would be relatively simple to set up a test to see if a "malloc"-ed space could be transgressed.
There have been tools for this for many years. Rational Purify is one tool that used to test for that. The problem here is that the tools that test for buffer overflow also are time consuming. A "Purified" program was several times larger and slower than the bare code. You use tools like Purify to test your code, but not for production code.
On Sun, Apr 13, 2014 at 10:05:08AM -0400, Sam Varshavchik wrote:
Suvayu Ali writes:
On Sun, Apr 13, 2014 at 08:38:11AM -0500, Ranjan Maitra wrote:
On Sun, 13 Apr 2014 09:15:04 -0400 Rahul Sundaram metherid@gmail.com wrote:
On Sun, Apr 13, 2014 at 6:23 AM, Timothy Murphy wrote:
Roger wrote:
It happened. It was known for years.
Everything I have seen says it has been known for about 1 week.
Incidentally, I am no programmer but I would have thought it would be relatively simple to set up a test to see if a "malloc"-ed space could be transgressed.
Not in this case. openssl uses a custom malloc
So, a valgrind -tool=memcheck --leak-check=yes --show-reachable=yes --track-fds=yes --track-origins=yes would not have helped?
AFAIU this is not a memory leak; it is a buffer overflow: lack of bounds checking. I do not think valgrind (or any other tool) can help with that. Feel free to correct me if I am wrong.
For this particular vulnerability, it is not technically a buffer overflow. The vulnerable code merely reads past the end of an allocated buffer. A buffer overflow gets exploited by writing past the allocated buffer.
If you want to classify this, the best classification here would be an information leak, and not a buffer overflow.
Indeed! I wasn't accurate there. Thanks for pointing it out.
The chances of valgrind catching this exploit are quite small. The only possible way I see valgrind could've complained would be if the original buffer that was allocated for the TLS ping message got padded by malloc() by a non-significant amount, and valgrind would've complained about reading uninitialized memory.
And ven in that case, valgrind() tends to complain about uninitialized memory only if its value is used to branch on. There's lots of code that ends up reading uninitialized memory without resulting in undefined behavior, for one reason or another. valgrind() doesn't typically complain reading a few uninitialized bytes after a range that's been legally malloc()ed, unless its value is used for branching, or something.
There is a nice analysis by a cloudflare engineer here:
Although the conclusion of that article about the likelihood of such an information leak was proven wrong by the results of their challenge, I think the analysis still seems very valid.
Thanks to the other posters for their responses. Quite a nice read.
Cheers,