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
On Tue, 2014-04-08 at 10:55 +0100, 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.
Correction: a patched version of 1.0.1e is available on Koji http://koji.fedoraproject.org/koji/buildinfo?buildID=509741 Presumably it will make its way to the repos.
poc
Patrick O'Callaghan wrote:
On Tue, 2014-04-08 at 10:55 +0100, 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.
Correction: a patched version of 1.0.1e is available on Koji http://koji.fedoraproject.org/koji/buildinfo?buildID=509741 Presumably it will make its way to the repos.
On it's way, see:
https://admin.fedoraproject.org/updates/openssl-1.0.1e-37.fc20.1 https://admin.fedoraproject.org/updates/openssl-1.0.1e-37.fc19.1
-- Rex
2014-04-08 8:00 GMT-03:00 Rex Dieter rdieter@math.unl.edu:
Patrick O'Callaghan wrote:
On Tue, 2014-04-08 at 10:55 +0100, 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.
Correction: a patched version of 1.0.1e is available on Koji http://koji.fedoraproject.org/koji/buildinfo?buildID=509741 Presumably it will make its way to the repos.
On it's way, see:
https://admin.fedoraproject.org/updates/openssl-1.0.1e-37.fc20.1 https://admin.fedoraproject.org/updates/openssl-1.0.1e-37.fc19.1
Why did we get so behind this? I was expecting the upgrade to be available by now (I was able to upgrade some Debian servers already 8 hours ago).
I'm a bit disappointed, and think these issues should be addressed ASAP.
On Tue, 2014-04-08 at 08:28 -0300, Martín Marqués wrote:
2014-04-08 8:00 GMT-03:00 Rex Dieter rdieter@math.unl.edu:
Patrick O'Callaghan wrote:
On Tue, 2014-04-08 at 10:55 +0100, 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.
Correction: a patched version of 1.0.1e is available on Koji http://koji.fedoraproject.org/koji/buildinfo?buildID=509741 Presumably it will make its way to the repos.
On it's way, see:
https://admin.fedoraproject.org/updates/openssl-1.0.1e-37.fc20.1 https://admin.fedoraproject.org/updates/openssl-1.0.1e-37.fc19.1
Why did we get so behind this? I was expecting the upgrade to be available by now (I was able to upgrade some Debian servers already 8 hours ago).
I'm a bit disappointed, and think these issues should be addressed ASAP.
It's been on Koji since yesterday, but I guess it needs karma or something.
poc
2014-04-08 8:34 GMT-03:00 Patrick O'Callaghan pocallaghan@gmail.com:
On Tue, 2014-04-08 at 08:28 -0300, Martín Marqués wrote:
I'm a bit disappointed, and think these issues should be addressed ASAP.
It's been on Koji since yesterday, but I guess it needs karma or something.
Hmmm, normally, the easiest way to give karma is using fedora-easy-karma, but the package isn't in testing yet.
Very annoying.
On 04/08/2014 02:01 PM, Martín Marqués wrote:
2014-04-08 8:34 GMT-03:00 Patrick O'Callaghan pocallaghan@gmail.com:
On Tue, 2014-04-08 at 08:28 -0300, Martín Marqués wrote:
I'm a bit disappointed, and think these issues should be addressed ASAP.
It's been on Koji since yesterday, but I guess it needs karma or something.
Hmmm, normally, the easiest way to give karma is using fedora-easy-karma, but the package isn't in testing yet.
Very annoying.
Karma value is 6 (https://admin.fedoraproject.org/updates/openssl-1.0.1e-37.fc20.1?_csrf_token...,
Tue Apr 8 14:46:18 CEST 2014)
Joachim Backes
Joachim Backes wrote:
On 04/08/2014 02:01 PM, Martín Marqués wrote:
2014-04-08 8:34 GMT-03:00 Patrick O'Callaghan pocallaghan@gmail.com:
On Tue, 2014-04-08 at 08:28 -0300, Martín Marqués wrote:
I'm a bit disappointed, and think these issues should be addressed ASAP.
It's been on Koji since yesterday, but I guess it needs karma or something.
Hmmm, normally, the easiest way to give karma is using fedora-easy-karma, but the package isn't in testing yet.
Very annoying.
Karma value is 6
(https://admin.fedoraproject.org/updates/openssl-1.0.1e-37.fc20.1?_csrf_token...,
Tue Apr 8 14:46:18 CEST 2014)
Joachim Backes
I wonder if systems that have various buffer overrun protections might be resistant to this attack?
On Tue, Apr 08, 2014 at 08:28:00AM -0300, Martín Marqués wrote:
https://admin.fedoraproject.org/updates/openssl-1.0.1e-37.fc20.1 https://admin.fedoraproject.org/updates/openssl-1.0.1e-37.fc19.1
Why did we get so behind this? I was expecting the upgrade to be available by now (I was able to upgrade some Debian servers already 8 hours ago).
Debian was super-fast. Having been up most of the night working on this with a number of other people, I think I have a pretty good handle on saying that we were as fast as possible with our processes and procedures. If you think we should be faster, I encourage you to get involved in making that happen. The Fedora Security SIG is https://fedoraproject.org/wiki/Category:Security
On Tue, 8 Apr 2014 08:59:59 -0400 Matthew Miller wrote:
Debian was super-fast. Having been up most of the night working on this with a number of other people, I think I have a pretty good handle on saying that we were as fast as possible with our processes and procedures.
Need to teach people to stop finding security flaws just before the weekend starts :-).
2014-04-08 9:59 GMT-03:00 Matthew Miller mattdm@fedoraproject.org:
On Tue, Apr 08, 2014 at 08:28:00AM -0300, Martín Marqués wrote:
https://admin.fedoraproject.org/updates/openssl-1.0.1e-37.fc20.1 https://admin.fedoraproject.org/updates/openssl-1.0.1e-37.fc19.1
Why did we get so behind this? I was expecting the upgrade to be available by now (I was able to upgrade some Debian servers already 8 hours ago).
Debian was super-fast. Having been up most of the night working on this with a number of other people, I think I have a pretty good handle on saying that we were as fast as possible with our processes and procedures. If you think we should be faster, I encourage you to get involved in making that happen. The Fedora Security SIG is https://fedoraproject.org/wiki/Category:Security
I have to agree that I'm to blame about that. I updated a Debian server we have last night and just thought "tomorrow I'll update my two Fedora workstation" not checking if the packages were already available.
If I would have checked at that moment, I'd noticed that the F19/F20 packages were not available yet. If I would have checked, I would have gotten involved. I guess I was to confident on the packages being there. My bad, I should have checked.
Good thing it that the koji packages were really easy to install using koji, although I prefer using rpm -Fvh to install after downloading. :D
+1 there!
On 4/8/2014 2: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
If anybody is interested, Heartbleed test: (Enter hostname of server to test for CVE-2014-0160)
On 04/08/2014 05:11 AM, Edward M wrote:
On 4/8/2014 2: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
If anybody is interested, Heartbleed test: (Enter hostname of server to test for CVE-2014-0160) http://filippo.io/Heartbleed/
Just a reminder to start SSL protected services after installation (e.g., httpd, smtp, etc.)
Allegedly, on or about 08 April 2014, Patrick O'Callaghan sent:
See also http://heartbleed.com/ and http://arstechnica.com/security/2014/04/critical-crypto-bug-in-openssl-opens...
Quoting from the arstechnica link (is that name meant to be funny?), I find this:
"recovering from the two-year-long vulnerability may also require revoking any exposed keys, reissuing new keys, and invalidating all session keys and session cookies"
Years ago I noticed a browser option to check for revoked keys, one that was always disabled by default on any system I looked. Switching it on caused many sites to fail, because they were badly set up. e.g. My bank, and many other mainstream sites.
It was an option that I considered ought to be set by default. I would have thought that checking for revoked certificates should be a mandatory step in a secure browsing situation. I wonder what the current state of play is with that?
Hello,
What is Koji? I downloaded the src.rpm, built it and installed the resulting binary rpm, was there an easier way?
Thanks. Dave.
On 4/8/14, Tim ignored_mailbox@yahoo.com.au wrote:
Allegedly, on or about 08 April 2014, Patrick O'Callaghan sent:
See also http://heartbleed.com/ and http://arstechnica.com/security/2014/04/critical-crypto-bug-in-openssl-opens...
Quoting from the arstechnica link (is that name meant to be funny?), I find this:
"recovering from the two-year-long vulnerability may also require revoking any exposed keys, reissuing new keys, and invalidating all session keys and session cookies"
Years ago I noticed a browser option to check for revoked keys, one that was always disabled by default on any system I looked. Switching it on caused many sites to fail, because they were badly set up. e.g. My bank, and many other mainstream sites.
It was an option that I considered ought to be set by default. I would have thought that checking for revoked certificates should be a mandatory step in a secure browsing situation. I wonder what the current state of play is with that?
-- [tim@localhost ~]$ uname -rsvp Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64
All mail to my mailbox is automatically deleted, there is no point trying to privately email me, I will only read messages posted to the public lists.
George Orwell's '1984' was supposed to be a warning against tyranny, not a set of instructions for supposedly democratic governments.
-- 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
On 04/08/2014 05:53 PM, David Mehler wrote:
Hello,
What is Koji? I downloaded the src.rpm, built it and installed the resulting binary rpm, was there an easier way?
http://koji.fedoraproject.org/koji/buildinfo?buildID=509741
Thanks. Dave.
Joachim Backes
On Wed, Apr 09, 2014 at 01:00:10 +0930, Tim ignored_mailbox@yahoo.com.au wrote:
It was an option that I considered ought to be set by default. I would have thought that checking for revoked certificates should be a mandatory step in a secure browsing situation. I wonder what the current state of play is with that?
That depends on your threat model. Checking for revocation leaks information about what sites you are visiting. Some might consider that a bigger risk than active man in the middle attacks.
On Tue, 2014-04-08 at 10:55 +0100, 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.
There's a front page article in the NY Times about this, first time ever seen an article there about a technical subject.
It's an interesting question why Net infrastructure code continues to be written in C, a language that provides no automatic checks for buffer overflow, which (if I understand right) is the opening for this security breach, along with so many others. And why is the code run on hardware that provides no such checks? There have been languages and system that check for overflow available for 40 years. Why doesn't anyone use them?
jon
On 04/09/14 11:35, Jonathan Ryshpan wrote: <<>>
It's an interesting question why Net infrastructure code continues to be written in C, a language that provides no automatic checks for buffer overflow, which (if I understand right) is the opening for this security breach, along with so many others. And why is the code run on hardware that provides no such checks? There have been languages and system that check for overflow available for 40 years.
from early times, c, c++ and the various "enhancements", were used because it was a universal language that code/source, could be written under 1 cpu and transferred to another and still run because code/source was run thru a cpu specific compiler.
something that could be done with basic, fortran, python, and other 'high level' languages. but, with the most efficient language, assembler, such could not be.
c and c++ are not interchangeable in there code. nor is c++ an enhancement or super set of c. they are each in their own world.
because of all the routines that where built up for c/c++, it soon became a sudo standard in programming. yet it falls short in ability of specific uses and will never replace fortran, python and other high levels.
c/c++ is a very inefficient language, yet it has been accepted as 'the language to learn and use'. a very bad misconception.
compactors have been written for c/c++, but even after many hours to days, and longer of running compactors, c/c++ still fail to be reduced to what can be done with high level languages, and will never come any where near the compactness of assembler.
the worst fault of c/c++ is buffer overflow, yet know one seems to really care. mainly an attitude of 'if it overflows, we will worry about it then'. not the best way to think.
if one were to run an analysis of programs that are hacked and of security that has been broken, one would find that what is written with c/c++ is the easiest to hack and break. a nature of the beast.
Why doesn't anyone use them?
because they are easy to understand, learn and use.
On 9 April 2014 06:35, Jonathan Ryshpan jonrysh@pacbell.net wrote:
On Tue, 2014-04-08 at 10:55 +0100, 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.
There's a front page article in the NY Times about this, first time ever seen an article there about a technical subject.
It's an interesting question why Net infrastructure code continues to be written in C, a language that provides no automatic checks for buffer overflow, which (if I understand right) is the opening for this security breach, along with so many others. And why is the code run on hardware that provides no such checks? There have been languages and system that check for overflow available for 40 years. Why doesn't anyone use them?
People use them, but not for everything. Particularly a read buffer overflow is harder to detect anyway (and a program needs to access its own memory space). A few reasons for C to persist in applications like this: * Performance. We can get into long arguments about Java JIT compilers (see next point) but most alternatives don't meet the performance needs. * Availability. C is the best common denominator for coding on many different platforms. (Note Java, Python, Perl, PHP are all used for 'Net infrastructure code', mostly at a higher level.) * Interoperability. Often overlooked, it's easier to provide bindings for other languages to C libraries. - all the above apply in a slightly weaker form for C++.
It is possible to write safe C code, and this has been increasingly done since these programmes have been exposed to increasing attack pressure.
On Tue, Apr 08, 2014 at 10:35:24PM -0700, Jonathan Ryshpan wrote:
On Tue, 2014-04-08 at 10:55 +0100, 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.
There's a front page article in the NY Times about this, first time ever seen an article there about a technical subject.
It's an interesting question why Net infrastructure code continues to be written in C, a language that provides no automatic checks for buffer overflow, which (if I understand right) is the opening for this security breach, along with so many others. And why is the code run on hardware that provides no such checks? There have been languages and system that check for overflow available for 40 years. Why doesn't anyone use them?
jon
NPR is just this moment airing a story about this leak.
Allegedly, on or about 08 April 2014, Jonathan Ryshpan sent:
It's an interesting question why Net infrastructure code continues to be written in C, a language that provides no automatic checks for buffer overflow, which (if I understand right) is the opening for this security breach, along with so many others. And why is the code run on hardware that provides no such checks? There have been languages and system that check for overflow available for 40 years. Why doesn't anyone use them?
Only the other day I was thinking similarly: That almost every exploit that I read about, over the last umpteen years, was a buffer overflow; and why is it so? Are programmers such morons that they accept all data without care, rather than only accept what you actually expect?
On 04/09/2014 06:19 PM, Tim wrote:
Allegedly, on or about 08 April 2014, Jonathan Ryshpan sent:
It's an interesting question why Net infrastructure code continues to be written in C, a language that provides no automatic checks for buffer overflow, which (if I understand right) is the opening for this security breach, along with so many others. And why is the code run on hardware that provides no such checks? There have been languages and system that check for overflow available for 40 years. Why doesn't anyone use them?
Only the other day I was thinking similarly: That almost every exploit that I read about, over the last umpteen years, was a buffer overflow; and why is it so? Are programmers such morons that they accept all data without care, rather than only accept what you actually expect?
IMO, it's just the fact that buffer overflows are the #1 weakness of coding in C and are the #1 use-case for exploits.
Other programming languages have other common weaknesses (Think of java or php), or are simply too little used to have made their weakness public and known to attackers.
Ralf
On 9 April 2014 17:19, Tim ignored_mailbox@yahoo.com.au wrote:
Only the other day I was thinking similarly: That almost every exploit that I read about, over the last umpteen years, was a buffer overflow; and why is it so? Are programmers such morons that they accept all data without care, rather than only accept what you actually expect?
No. It's because the entire world of modern computing is built on C, a programming language that is a sort of portable assembly-language but with pointer arithmetic, a language so brain-dead that it lets you assign element 31 in an array of 30 elements, or write to the 42nd character of a 40-character string. And which encourages programmers to arithmetically manipulate pointers to data in memory directly, which compels programmers to do their own memory-management manually.
All more mature, reliable languages have features that check accesses and disallow direct pointer manipulation. And once, there were programming languages whose basic features were atoms and lists, not bits and bytes, and they ran on chips that natively understood atoms and lists and where things like memory overruns and underruns were therefore unheard-of.
Unfortunately, in the 1980s, when chips and RAM were really expensive, what succeeded commercially were really simple, fast languages (like C) and really simple, fast chips (like x86 and RISC) and all the better, more powerful chips and languages disappeared or were marginalised.
So now, what we have are the cheap'n'nasty machines and software of the 1970s and 1980s, but vastly upgraded in speed and capacity, and the /good/ computers and software, the ones that enabled people to be tens to hundreds of times more productive, are all gone.
I was just ranting about this /right before/ the Heartbleed thing became public:
On 9 April 2014 18:05, Liam Proven lproven@gmail.com wrote:
I was just ranting about this /right before/ the Heartbleed thing became public:
But Gmail didn't want me to paste the link, which is:
http://liam-on-linux.livejournal.com/42285.html
On 9 April 2014 18:05, Liam Proven lproven@gmail.com wrote:
On 9 April 2014 17:19, Tim ignored_mailbox@yahoo.com.au wrote:
Only the other day I was thinking similarly: That almost every exploit that I read about, over the last umpteen years, was a buffer overflow; and why is it so? Are programmers such morons that they accept all data without care, rather than only accept what you actually expect?
No. It's because the entire world of modern computing is built on C, a programming language that is a sort of portable assembly-language but with pointer arithmetic, a language so brain-dead that it lets you assign element 31 in an array of 30 elements, or write to the 42nd character of a 40-character string. And which encourages programmers to arithmetically manipulate pointers to data in memory directly, which compels programmers to do their own memory-management manually.
To be clear on a couple of things. The array access that C provides is what you would get with assembly language (not "but lets you perform pointer arithmetic"), and actually a feature, not some brain-dead mistake, though maybe not a feature most people need. Second, heartbleed is not a buffer writing bug, it's *reading* past the end of an array. The patch check has been added against a length field they already have, so this was a mistake of trusting the supplied request and maybe not realising there could be a problem. This bug was pretty bad, but the kind of mistakes that lead to overflows and over-reads tend to be from not keeping track of the data properly and will cause other problems anyway, memory protection doesn't help with those.
Hi
On Thu, Apr 10, 2014 at 3:19 AM, Ian Malone wrote:
. This bug was pretty bad, but the kind of mistakes that lead to overflows and over-reads tend to be from not keeping track of the data properly and will cause other problems anyway, memory protection doesn't help with those.
In a managed language, it isn't typically possible to read past the end of an array without it resulting in obvious errors. So while it isn't a silver bullet, it could have helped significantly here to notice the problem and correct the relevant related code. Unfortunately C continues to dominate as a popular systems programming language and these types of errors remain a frequent problem largely because language level support for higher level abstractions remain extremely weak. The fact that a major piece of extremely security critical code received almost no support from commercial vendors for a detailed audit for security flaws also remains a problem.
Rahul
On 04/10/2014 04:02 PM, Rahul Sundaram wrote:
Hi
On Thu, Apr 10, 2014 at 3:19 AM, Ian Malone wrote:
. This bug was pretty bad, but the kind of mistakes that lead to overflows and over-reads tend to be from not keeping track of the data properly and will cause other problems anyway, memory protection doesn't help with those.In a managed language, it isn't typically possible to read past the end of an array without it resulting in obvious errors. So while it isn't a silver bullet, it could have helped significantly here to notice the problem and correct the relevant related code. Unfortunately C continues to dominate as a popular systems programming language and these types of errors remain a frequent problem largely because language level support for higher level abstractions remain extremely weak. The fact that a major piece of extremely security critical code received almost no support from commercial vendors for a detailed audit for security flaws also remains a problem.
The cost of a "managed language" is that it affects performance. There are essentially 2 phases in language. The first is static. The language is compiled, and the compiler attempts to prevent buffer overflows or reading past the end of an array. FORTRAN has had this for over 50 years. The second is dynamic or during run time. Some languages have this (mostly interpretive languages). There is code that exists for C that also can prevent this. But, OpenSSL, and libc, and other run-time libraries on Linux and Unix and even DLLs in that other OS need to consider performance, or the lack of. But, I maintain that virtually any language suitable for use in run-time libraries can be subverted. But if we go lower, there are even bugs in the chips. Remember the Intel floating point bug a few years ago.
But, since our underlying libraries are written in C and are going to be that way for a bunch of years, we should start using, or mandating the use of tools such as Valgrind and Rational Purify as a method of testing the code. These help the programmer locate potential latent bugs. Not sure about Valgrind, but Purify takes libraries into account.
Hi
On Sat, Apr 19, 2014 at 11:32 AM, Jerry Feldman wrote:
The cost of a "managed language" is that it affects performance.
Not necessarily but even in that case, it might have better to trade off some speed for better security in such cases. We are talking about millions and millions of affected users who had to go ahead and change passwords for many many things they rely on and I have yet to finish doing it. Firewalls can affect network performance as well yet few would use that as a reason not to use them.
Rahul
On Wed, 2014-04-23 at 23:26 -0400, Rahul Sundaram wrote:
millions and millions of affected users who had to go ahead and change passwords for many many things they rely on
One thing I haven't seen mentioned, here nor elsewhere, was whether the bug could only affect you if they tried to hack the server while you were using it. Or if it was possible to extra useful data well after you had been and gone. Since it's talking about reading data beyond what's expected, I suspect it may be that you were vulnerable even sometime after your session, if the server hadn't re-used the memory for something else, yet.
On 26 April 2014 03:38, Tim ignored_mailbox@yahoo.com.au wrote:
On Wed, 2014-04-23 at 23:26 -0400, Rahul Sundaram wrote:
millions and millions of affected users who had to go ahead and change passwords for many many things they rely on
One thing I haven't seen mentioned, here nor elsewhere, was whether the bug could only affect you if they tried to hack the server while you were using it. Or if it was possible to extra useful data well after you had been and gone. Since it's talking about reading data beyond what's expected, I suspect it may be that you were vulnerable even sometime after your session, if the server hadn't re-used the memory for something else, yet.
The simplest 'backwards' exploit is if the private keys were stolen then other encrypted traffic captured which had used the same keys could then be decoded. Though IIUC 'perfect forward secrecy' should reduce the risk of that. As you say there's also whatever data is still in memory, that's a shorter window. I don't know how Apache memory is structured, but I'd speculate there's the potential to leak hashed passwords there.
Ian Malone wrote:
On 26 April 2014 03:38, Tim ignored_mailbox@yahoo.com.au wrote:
On Wed, 2014-04-23 at 23:26 -0400, Rahul Sundaram wrote:
millions and millions of affected users who had to go ahead and change passwords for many many things they rely on
One thing I haven't seen mentioned, here nor elsewhere, was whether the bug could only affect you if they tried to hack the server while you were using it. Or if it was possible to extra useful data well after you had been and gone. Since it's talking about reading data beyond what's expected, I suspect it may be that you were vulnerable even sometime after your session, if the server hadn't re-used the memory for something else, yet.
The simplest 'backwards' exploit is if the private keys were stolen then other encrypted traffic captured which had used the same keys could then be decoded. Though IIUC 'perfect forward secrecy' should reduce the risk of that. As you say there's also whatever data is still in memory, that's a shorter window. I don't know how Apache memory is structured, but I'd speculate there's the potential to leak hashed passwords there.
I'm not SSL/TLS guru and I'm not in-deep study heartbeat OpenSSL bug (mainly because I consider Fedora 15+ as too problematic and stay at F14 with eventual migration to CentOS 6 on my servers, thus they aren't affected with this bug), but - it is truth, that when private key is stealed, this _always_ implied, that encrypted traffic may be read with private key knowledge? As I know, when e.g. Diffie-Hellman key exchanging is used, then either private key knowledge isn't sufficient to decode network traffic. Of course, TLS RFCs give us some basic set of mandatory ciphersuites which should know every TLS endpoint, and there are also these, where private key knowledge is sufficient for traffic decoding. But when at my side I allow e.g. (contrary to RFCs) only DH ciphersuites, then maybe either I'm not able establish a connection, or my connection is reliable - although connection is tapped by someone, who keep my private key. Or am I wrong? --- Regards, Franta Hanzlik
On Sat, Apr 26, 2014 at 22:19:47 +0200, Frantisek Hanzlik franta@hanzlici.cz wrote:
I'm not SSL/TLS guru and I'm not in-deep study heartbeat OpenSSL bug (mainly because I consider Fedora 15+ as too problematic and stay at F14 with eventual migration to CentOS 6 on my servers, thus they aren't affected with this bug), but - it is truth, that when private key is stealed, this _always_ implied, that encrypted traffic may be read with private key knowledge? As I know, when e.g. Diffie-Hellman key exchanging is used, then either private key knowledge isn't sufficient to decode network traffic. Of course, TLS RFCs give us some basic set of mandatory ciphersuites which should know every TLS endpoint, and there are also these, where private key knowledge is sufficient for traffic decoding. But when at my side I allow e.g. (contrary to RFCs) only DH ciphersuites, then maybe either I'm not able establish a connection, or my connection is reliable - although connection is tapped by someone, who keep my private key. Or am I wrong?
If you have the private key and can redirect network traffic you can do man in the middle attacks. If forward security isn't being provided then just being able to see the traffic can allow you to get session keys.
Depending on what you don't like about current Fedoras, you might try out the XFCE or Mate desktops. They provide an experience similar to Gnome 2. If you have an old graphics card, you will want to use kdm or lxdm instead of gdm.
On 04/26/2014 04:35 PM, Bruno Wolff III wrote:
Depending on what you don't like about current Fedoras, you might try out the XFCE or Mate desktops. They provide an experience similar to Gnome 2. If you have an old graphics card, you will want to use kdm or lxdm instead of gdm.
If you pick Xfce, lightdm is probably your best choice, as it's the one you'd get if you did a clean install with Xfce as your only DM. Using gdm pulls in a considerable amount of Gnome cruft, and kdm probably does the equivalent.
Joe Zeff wrote:
On 04/26/2014 04:35 PM, Bruno Wolff III wrote:
Depending on what you don't like about current Fedoras, you might try out the XFCE or Mate desktops. They provide an experience similar to Gnome 2. If you have an old graphics card, you will want to use kdm or lxdm instead of gdm.
If you pick Xfce, lightdm is probably your best choice, as it's the one you'd get if you did a clean install with Xfce as your only DM. Using gdm pulls in a considerable amount of Gnome cruft, and kdm probably does the equivalent.
I wrote about Fedora use on servers in the context of Heartbleed bug. On desktop, of course, I'm using Xfce now (as I was old Gnome 2 user) and my friends (which not upgrade their own Fedora distras frequently and then skipped the gap between Gnome 2 and Mate) are using Mate now. With lightdm, because it has possibility to choice session language, which option isn't in gdm (despite the gnome 3 ballast, as You type).
Bruno Wolff III wrote:
On Sat, Apr 26, 2014 at 22:19:47 +0200, Frantisek Hanzlik franta@hanzlici.cz wrote:
I'm not SSL/TLS guru and I'm not in-deep study heartbeat OpenSSL bug (mainly because I consider Fedora 15+ as too problematic and stay at F14 with eventual migration to CentOS 6 on my servers, thus they aren't affected with this bug), but - it is truth, that when private key is stealed, this _always_ implied, that encrypted traffic may be read with private key knowledge? As I know, when e.g. Diffie-Hellman key exchanging is used, then either private key knowledge isn't sufficient to decode network traffic. Of course, TLS RFCs give us some basic set of mandatory ciphersuites which should know every TLS endpoint, and there are also these, where private key knowledge is sufficient for traffic decoding. But when at my side I allow e.g. (contrary to RFCs) only DH ciphersuites, then maybe either I'm not able establish a connection, or my connection is reliable - although connection is tapped by someone, who keep my private key. Or am I wrong?
If you have the private key and can redirect network traffic you can do man in the middle attacks. If forward security isn't being provided then just being able to see the traffic can allow you to get session keys.
MITM I can do even without having victims private key, it is another case. But what I want to say, that was that even private key knowledge is not _always_ sufficient to decode TLS traffic (when I able see / capture it).
Quoting Tim ignored_mailbox@yahoo.com.au:
Allegedly, on or about 08 April 2014, Jonathan Ryshpan sent:
It's an interesting question why Net infrastructure code continues to be written in C, a language that provides no automatic checks for buffer overflow, which (if I understand right) is the opening for this security breach, along with so many others. And why is the code run on hardware that provides no such checks? There have been languages and system that check for overflow available for 40 years. Why doesn't anyone use them?
Only the other day I was thinking similarly: That almost every exploit that I read about, over the last umpteen years, was a buffer overflow; and why is it so? Are programmers such morons that they accept all data without care, rather than only accept what you actually expect?
I would say they're badly trained. The cost/benefir ration between hardware and programmer time has changed drastically to the point where hardware is practically free but programmer time, notwithstanding offshoring, is expensive. The institutional inertia is so large that education consists largely of teaching the students to do well what their instructors would like to have been taught. Not a viable way forward.
Dave
-- [tim@localhost ~]$ uname -rsvp Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64
All mail to my mailbox is automatically deleted, there is no point trying to privately email me, I will only read messages posted to the public lists.
George Orwell's '1984' was supposed to be a warning against tyranny, not a set of instructions for supposedly democratic governments.
-- 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
On 04/09/2014 01:43 PM, Dave Stevens wrote:
Quoting Tim ignored_mailbox@yahoo.com.au:
Allegedly, on or about 08 April 2014, Jonathan Ryshpan sent:
It's an interesting question why Net infrastructure code continues to be written in C, a language that provides no automatic checks for buffer overflow, which (if I understand right) is the opening for this security breach, along with so many others. And why is the code run on hardware that provides no such checks? There have been languages and system that check for overflow available for 40 years. Why doesn't anyone use them?
Only the other day I was thinking similarly: That almost every exploit that I read about, over the last umpteen years, was a buffer overflow; and why is it so? Are programmers such morons that they accept all data without care, rather than only accept what you actually expect?
I would say they're badly trained. The cost/benefir ration between hardware and programmer time has changed drastically to the point where hardware is practically free but programmer time, notwithstanding offshoring, is expensive. The institutional inertia is so large that education consists largely of teaching the students to do well what their instructors would like to have been taught. Not a viable way forward.
Dave
All this is understood. But, consider the transition from C to a more modern, safer coding language with respect to developing a new OS, or even re-coding Linux and Unix. But that may be coming. For instance almost all coding in Android is in Java. The Android runs 1 but JVM (Dalvik). But, the underlying OS is still the Linux kernel. Possibly we should design a chipset that is a JVM. But, regardless of the computer language, bugs will be present. I've been moving some of our code from Subversion (stable and written in C) to another source control system written in Java. That source control system crashes frequently and leaves core dumps..
My point is that it is not the computer language that causes the bugs, it is the programmer. There are many tools out there a programmer can use to analyze his/her code to find potential errors such as buffer overflows. So, let's say that we built a chip that is essentially a JVM and code everything in Java, will we have fewer bugs? No because sloppy coding techniques will exist regardless of the computer language. Bounds-checking an array, or generating bounds-checking in the code has been around C a long time. But we generally don't use it because it costs too much in performance.
But, we are stuck with C for a while because that is what Linux and Unix are written. While Java is an excellent language I don't see it replacing C at the OS level, but it is almost there in Android.
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, Apr 09, 2014 at 11:52:49 -0700, Dan Thurman dant@cdkkt.com wrote:
I know that F18 is EOL & vulnerable, so can I backport OpenSSL with a fix? I am' not ready to upgrade at this time...
You could try rebuilding from a src rpm from the fixed version in f19. I would expect that to have a very good chance of building successfully on f18.
On Wed, Apr 09, 2014 at 03:05:28PM -0500, Bruno Wolff III wrote:
You could try rebuilding from a src rpm from the fixed version in f19. I would expect that to have a very good chance of building successfully on f18.
Failing that, modify the f18 RPM to build with -DOPENSSL_NO_HEARTBEATS
On 04/09/2014 01:30 PM, Matthew Miller wrote:
On Wed, Apr 09, 2014 at 03:05:28PM -0500, Bruno Wolff III wrote:
You could try rebuilding from a src rpm from the fixed version in f19. I would expect that to have a very good chance of building successfully on f18.
Failing that, modify the f18 RPM to build with -DOPENSSL_NO_HEARTBEATS
(Sorry Matthew - this is a resend to get the message on Fedora Forum!)
I need a little help.... where in the spec file can I add -DOPENSSL_NO_HEARTBEATS ?
On 04/09/2014 03:57 PM, Dan Thurman wrote:
On 04/09/2014 01:30 PM, Matthew Miller wrote:
On Wed, Apr 09, 2014 at 03:05:28PM -0500, Bruno Wolff III wrote:
You could try rebuilding from a src rpm from the fixed version in f19. I would expect that to have a very good chance of building successfully on f18.
Failing that, modify the f18 RPM to build with -DOPENSSL_NO_HEARTBEATS
(Sorry Matthew - this is a resend to get the message on Fedora Forum!)
I need a little help.... where in the spec file can I add -DOPENSSL_NO_HEARTBEATS ?
I think I found it - Add in the spec file to: RPM_OPT_FLAGS
On 04/09/2014 05:15 PM, Dan Thurman wrote:
On 04/09/2014 03:57 PM, Dan Thurman wrote:
On 04/09/2014 01:30 PM, Matthew Miller wrote:
On Wed, Apr 09, 2014 at 03:05:28PM -0500, Bruno Wolff III wrote:
You could try rebuilding from a src rpm from the fixed version in f19. I would expect that to have a very good chance of building successfully on f18.
Failing that, modify the f18 RPM to build with -DOPENSSL_NO_HEARTBEATS
(Sorry Matthew - this is a resend to get the message on Fedora Forum!)
I need a little help.... where in the spec file can I add -DOPENSSL_NO_HEARTBEATS ?
I think I found it - Add in the spec file to: RPM_OPT_FLAGS
Gah! I tried everything I could and I am not able to get this to work!
1) I downloaded F19 SRPM file and rebuild but it fails to rebuild on F18, so scratch that, I think.
2) I downloaded F18 SRPM file, changed the SPEC file by adding -DOPENSSL_NO_HEARTBEATS to RPM_OPT_FLAGS variable, then rebuild which compiled with no errors, then removed the old openssl files (rpm --nodeps -e openssl*), installed the new files (rpm -ivh *.rpm in RPM directory) then proceeded to the heartbeat site and it failed (red)
Any pointers?
Once upon a time, Dan Thurman dant@cdkkt.com said:
- I downloaded F18 SRPM file, changed the SPEC file by adding -DOPENSSL_NO_HEARTBEATS to RPM_OPT_FLAGS variable, then rebuild which compiled with no errors, then removed the old openssl files (rpm --nodeps -e openssl*), installed the new files (rpm -ivh *.rpm in RPM directory)
Don't do it that way! --nodeps is something you should never use. You could have "rpm -Uvh", or even "yum localinstall".
then proceeded to the heartbeat site and it failed (red)
Did you restart services (or reboot)? Under Unix, once a file is opened, the reference remains even if it is removed/replaced. If you don't restart Apache, it will still be using the old OpenSSL libraries.
On 04/10/2014 12:10 PM, Chris Adams wrote:
Once upon a time, Dan Thurman dant@cdkkt.com said:
- I downloaded F18 SRPM file, changed the SPEC file by adding -DOPENSSL_NO_HEARTBEATS to RPM_OPT_FLAGS variable, then rebuild which compiled with no errors, then removed the old openssl files (rpm --nodeps -e openssl*), installed the new files (rpm -ivh *.rpm in RPM directory)
Don't do it that way! --nodeps is something you should never use. You could have "rpm -Uvh", or even "yum localinstall".
then proceeded to the heartbeat site and it failed (red)Did you restart services (or reboot)? Under Unix, once a file is opened, the reference remains even if it is removed/replaced. If you don't restart Apache, it will still be using the old OpenSSL libraries.
Ok about --nodeps.
So what I did was: 1) yum clean all 2) yum update (nothing to update) 3) yum reinstall openssl* (reinstalled and to mitigate any issues caused by --nodeps, no issues) 4) yum localinstall openssl*.rpm (nothing to install) (same as rpm -Uvh)
So I was unable to rpm -Uvh *.rpm/yum localinstall *.rpm because yum/rpm detected no difference. Perhaps I need to change the SPEC file to a different version, say from 1:1.0.1e-37.fc18 to 1:1.0.1e-38.fc18? If so, where do I change the version from 37 ->38?
Once upon a time, Dan Thurman dant@cdkkt.com said:
So I was unable to rpm -Uvh *.rpm/yum localinstall *.rpm because yum/rpm detected no difference. Perhaps I need to change the SPEC file to a different version, say from 1:1.0.1e-37.fc18 to 1:1.0.1e-38.fc18? If so, where do I change the version from 37 ->38?
Yes, any new build should always have a new version. There should be a "Version:" line near the top, probably set to something like "37%{?dist}". I'd probably go with "37%{?dist}.0.1" myself (probably not an issue in this case since there's unlikely to ever be another update you'd load).
If you want to make it "nice" (in the small chance anybody else ever had to touch the system), you could also look for the "%changelog" section and add a note there about your change.
Sorry about the --nodeps mini-rant, that's just a thing I hate to see anybody ever suggest on a mailing list.
On 04/10/2014 12:56 PM, Chris Adams wrote:
Once upon a time, Dan Thurman dant@cdkkt.com said:
So I was unable to rpm -Uvh *.rpm/yum localinstall *.rpm because yum/rpm detected no difference. Perhaps I need to change the SPEC file to a different version, say from 1:1.0.1e-37.fc18 to 1:1.0.1e-38.fc18? If so, where do I change the version from 37 ->38?
Yes, any new build should always have a new version. There should be a "Version:" line near the top, probably set to something like "37%{?dist}". I'd probably go with "37%{?dist}.0.1" myself (probably not an issue in this case since there's unlikely to ever be another update you'd load).
If you want to make it "nice" (in the small chance anybody else ever had to touch the system), you could also look for the "%changelog" section and add a note there about your change.
Sorry about the --nodeps mini-rant, that's just a thing I hate to see anybody ever suggest on a mailing list.
Thanks Chris, for your help! I got the problem solved!
On 04/09/2014 02:52 PM, Dan Thurman wrote:
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
I noticed that when I updated, that the "latest" version is 1.0.1e? I cannot seem to find a "g" in the repos...is there some specific place I should look? Or will the version that got updated be sufficient?...
EGO II
On 04/10/14 17:18, EGO.II-1 wrote:
I noticed that when I updated, that the "latest" version is 1.0.1e? I cannot seem to find a "g" in the repos...is there some specific place I should look? Or will the version that got updated be sufficient?...
[egreshko@meimei addresses]$ rpm -q --changelog openssl | more * Mon Apr 07 2014 Dennis Gilmore dennis@ausil.us - 1.0.1e-37.1 - pull in upstream patch for CVE-2014-0160
Says it all....
-
Bruno Wolff III -
Chris Adams -
Dan Thurman -
Dave Stevens -
David Mehler -
Ed Greshko -
Edward M -
Edward M -
EGO-II.1 -
Franta Hanzlík -
Fred Smith -
g -
Ian Malone -
Jerry Feldman -
Joachim Backes -
Joe Zeff -
Jonathan Ryshpan -
Liam Proven -
Martín Marqués -
Matthew Miller -
Neal Becker -
Patrick O'Callaghan -
Rahul Sundaram -
Ralf Corsepius -
Rex Dieter -
SternData -
Tim -
Tom Horsley