Slashdot Mirror
OpenSSL Bug Allows Attackers To Read Memory In 64k Chunks
Bismillah (993337) writes "A potentially very serious bug in OpenSSL 1.0.1 and 1.0.2 beta has been discovered that can leak just about any information, from keys to content. Better yet, it appears to have been introduced in 2011, and known since March 2012."
Quoting the security advisory: "A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server." The attack may be repeated and it appears trivial to acquire the host's private key. If you were running a vulnerable release, it is even suggested that you go as far as revoking all of your keys. Distributions using OpenSSL 0.9.8 are not vulnerable (Debian Squeeze vintage). Debian Wheezy, Ubuntu 12.04.4, Centos 6.5, Fedora 18, SuSE 12.2, OpenBSD 5.4, FreeBSD 8.4, and NetBSD 5.0.2 and all following releases are vulnerable. OpenSSL released 1.0.1g today addressing the vulnerability. Debian's fix is in incoming and should hit mirrors soon, Fedora is having some trouble applying their patches, but a workaround patch to the package .spec (disabling heartbeats) is available for immediate application.
"We have tested some of our own services from attacker's perspective. We attacked ourselves from outside, without leaving a trace. Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication."
Yikes. And it's been known for 2 years. That's some shit!
Who knows who knew what and when, but the 2012 statement is a misinterpretation of TFA where they seem to be saying it essentially started "hitting the shelves" in distros about then, whereas before then it was mostly only distributed in beta builds and head code.
Someone had to do it.
Now how are we supposed to collect people's private information without their knowledge? Think of the children and all of the terrorists captured with this exploit in the wild!
sincerely,
NSA
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
Irony rears it's head on the day that patches for a Linux vulnerability are announced at the same time Microsoft ends its patching and update service for Windows XP.
jargon away!
Never trusted openssl - only use GnuTLS.
http://www.theregister.co.uk/2...
As I can't imagine the servers I connect to being interested in snooping on my client data, I presume this bug is only a real concern for systems running services, not acting as clients.
I do not fail; I succeed at finding out what does not work.
sudo apt-get update && sudo apt-get upgrade.
Generate and distribute new keys.
Problem soved.
"On the Internet, nobody can hear you being subtle." -Linus Torvalds
Bill Gates as a hacker:
"64k chunks ottah be enough for anyone."
Table-ized A.I.
Could someone please give Theo a heap of grief over this from me? He's always so quick to bag out GnuTLS and others when they have an issue. Only fair he gets a share of what he dishes out. Besides, this seems to be even worse than a "goto fail"...
Nobody tell the NSA about this, okay?
Have you tried turning it off and on again?
can someone link to the git blame of the bug please?
Is there anyone on the planet using TLS heartbeats via TCP for anything except exploiting this bug? What is even the point of heartbeats without DTLS?
Bugs are bugs yet decision to enable a mostly useless feature for non-DTLS by default in my view is not so easily excusable.
Well, it's not good that almost every major audit-able crypto library has been found to have trivial exploits (still waiting on issues in the Chrome and Mozilla SSL libraries).
It's good that eyes are looking, and people are finding these things. I imagine that without Snowden's revelations, nobody would have bothered to check. And these bugs would have been found much later or not at all, allowing espionage organizations to compromise many more private communications in the interim.
While the idea that the NSA or some other agency had a hand in these bugs is largely a conspiracy theory, the answer to whether they knew about these flaws and exploited them should be pretty obvious. After all, the NSA has probably done the very same code audits for the purpose of finding holes they can exploit.
And before somebody says a closed-source implementation wouldn't suffer these problems, quite frankly, if all of these libraries were closed-source, we wouldn't know if there was a vulnurability at all, or for that matter if any found would be fixed. There needs to be more eyes auditing the security code, not fewer.
"If a nation expects to be ignorant and free in a state of civilization, it expects what never was and never will be."
Because nobody even attempts to run secure applications on any other platform...
That's not a fair generalization. Though there are plenty of "ideologically driven amateurs" — especially in the Linux (compared to BSD) world — they are mostly found among the noisy advocates, rather than actual developers.
Somewhere higher up the bug is described as a "simple bounds check" — which would be easy to implement. The truth is, probably, in between somewhere.
NSA, I am sure, know plenty of holes — if not custom-made by the authors doors — into proprietary software too.
I am disappointed at the quality of open source software — especially pieces as famous and fundamental as OpenSSL, and I agree, that open source's claimed advantage of there being "thousands of eyeballs" verifying its correctness is overblown.
But to declare it to be "losing" is a silly jump just as far in the direction opposite to the enthusiastic proclamations of the above mentioned ideology-driven advocates.
In Soviet Washington the swamp drains you.
Linux Mint, and I'd assume Ubuntu too, has already pushed the updates out. Happy happy. Joy joy.
How the fuck did this get modded up? Idiot mods (and "DarwinSurvivor", apparently) can't read a link, I guess...
The only way this could have been stupider is if it was actually the same link, instead of merely being a link that I could tell, just from the URL, was about exactly the same issue.
Morons.
There's no place I could be, since I've found Serenity...
While you're right this was very negligent for a project of the stature and importance of openssl, merely discovering this bug in closed source software would have required a fuzzer and much luck, leaving it unfixed for whoever had managed to get a a copy of the source to exploit for much longer.
All I can say personally is I sure picked the right two years to get lazy about patching up.
Someone had to do it.
Any data kept in RAM on an open-ssl box has probably been compromised. It sounds like that includes private keys, root certs, passwords, etc.
This is why passwords etc should be encrypted in RAM. It's funny, there's a Security Technical Implementation Guides (STIG) on that very item. It always sounded sort of ridiculous, but now I know why it was there.
Chrome just uses the operating system for a lot of the certificate validation of HTTPS, so it can be vulnerable to security holes that apply to the operating system. Chrome wasn't vulnerable to "goto fail", but presumably it has been vulnerable to others in Windows and Mac OS.
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
Shill much?
Two anonymous cowards with IDs less than 1000 digits apart write anti-open source posts at the same time?
I started being annoyed at having someone else tell me how
to set up security, but taken one at a time they almost all
make sense.
At the same time? The posts were 12 minutes apart.
But the actual announcement is not among them.
https://www.openssl.org/news/secadv_20140407.txt
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
..it was not in 640k chunks!
Somewhere higher up the bug is described as a "simple bounds check" — which would be easy to implement. The truth is, probably, in between somewhere.
It's not the fix of the code that's messy. It's the fix of the trusts using that code to function. They are all broken. After the upgrade keys need to be replaced, certificates re-issued, endpoints and clients reconfigured to trust new keys, and in some cases customers and end-users may need to be involved. For anything of CDE level security or higher, it's as big a cleanup job than the one that gave us openssl-blacklist, but the blacklist for this would be neither complete nor easy to assemble.
I predict a lot more interest in turning on CRL pathways in the future.
Someone had to do it.
Good thing I use WIndows, so I'm safe.
Man you're clueless. This is a case of open source fixing a security issue as soon as it's recognized, and you call it a downside?
Hint: closed source code probably contains hundreds or thousands of these holes and they hang around unfixed for decades.
Does this effect SSH at all? It seems more likely this would effect TSL servers such as Apache and stunnel.
Yet again, C's non-existent bounds checking and completely unprotected memory access lets an attacker compromise the system with data.
But hey, it's faster.
Despite car companies complaining loudly that if people just drove better there would be no accidents, laws were eventually changed to require seatbelts and airbags because humans are humans and accidents are inevitable.
Because C makes it trivially easy to stomp all over memory we are guaranteed that even the best programmers using the best practices and tools will still churn out the occasional buffer overflow, information disclosure, stack smash, or etc.
Only the smallest core of the OS should use unmanaged code with direct memory access. Everything else, including the vast majority of the kernel, all drivers, all libraries, all user programs should use managed memory. Singularity proved that was perfectly workable. I don't care if the language is C#, Rust, or whatever else. How many more times do we have to get burned before we make the move?
As long as all our personal information relies on really smart people who never make mistakes, we're doomed.
Natural != (nontoxic || beneficial)
Keeping the passwords encrypted in RAM doesn't help all that much if you also have the decryption key in RAM. Which you do, because you need to use the password. Right?
Having said that; a server should (ideally) never have a plain-text password anyway.
*air-punch*
I knew procrastinating Debian upgrades for most of a decade would pay off! I am VINDICATED!
Shill much?
Two anonymous cowards with IDs less than 1000 digits apart write anti-open source posts at the same time?
LOL!
That's not a fair generalization. Though there are plenty of "ideologically driven amateurs" — especially in the Linux (compared to BSD) world — they are mostly found among the noisy advocates, rather than actual developers.
...
systemd devs seem bound and determined to prove you wrong there...
Yeah, sometimes I say things so stupid, it amazes me, too
My understanding is that Chrome and Mozilla both use NSS. It's a bit outdated, so I could be wrong (given that Google forked webkit, I can imagine them forking NSS too).
Actually, with a quick Google search, it seems that Chrome on Android uses (used?) OpenSSL for certain functions. I'm curious to know if secure communication via Android devices can be compromised via those functions. At first glance, I'd say no, but I don't have enough domain knowledge to make this assertion.
NSS is thus far secure, but I really, really would like to see the results of multiple full and independent audits. If there's a problem in NSS, that would be about as big as it can get.
Like I said, it's a bit frightening that there are such large and somewhat obvious holes in these major crypto libraries found within three months of each other, but it's good to know that they're being found and fixed.
"If a nation expects to be ignorant and free in a state of civilization, it expects what never was and never will be."
On a side note, regarding advantage of there being "thousands of eyeballs" verifying its correctness" -
ESR's famous quote is "with enough eyeballs, all bugs are shallow - the fix will be obvious to someone."
The quote doesn't say anything about correctness. It says that when strange behavior is noticed, someone will see a clear fix. A shallow bug is one that's right there on the surface, where you can see the source of the problem. That's in contrast to one where you have to spend hours searching for what's causing the problem. It makes no claim of how quickly or easily a bug will be discovered - just how it can be fixed once it's discovered.
There are security vulnerabilities seemingly EVERYWHERE. Do programmers not test their code anymore? Is there no testing protocol for security issues? Is no one embarrased to have released a piece of software that's so porous? I'm retired, and I can tell you that if I had written code with the security holes that modern programs and apps seem to have, I would have been unceremoniously fired very quickly by any and all of the several employers for whom I worked in my career. But that doesn't seem to happen today, unfortunately.
Wow a whole two posts within 15 minutes of eachother (and around 1000 posts in between) that are critical of the value placed on the open source model with respect to security?! They must be being paid to have that opinion! Nevermind the fact that we have seen several years-old bugs across security libraries, application frameworks and the kernel itself in recent times. The idea that it is safer because it's open is fantasy, if anything these bugs are directly exposed and remain that way until there is some responsible disclosure. Now the idea that they can be fixed and pushed to all customers in a timely manner is another story, though even then it depends on the situation - take Android or Tivo for example.
Both models have advantages and disadvantages depending on what the product is, the size of its market, the type of market, etc. and sometimes those advantages can't even be realized (again, see Android or Tivo) so anybody espousing one over the other as the one true model is a short-sighted idiot.
But, regardless of the root cause (intentional malice or just sloppiness) I'm glad eyes have been checking these code bases with more diligence over the past several months. In the end it means more security for us users, regardless of our platform of choice.
Thank you again, Edward Snowden, for the collective wake up call!
Now if we could just get our governing officials to fix some of these egregious laws...
#DeleteChrome
Heh, I also suffer from foot-in-mouth disease from time to time. And look - you got modded up! : )
Re " both models have advantages and disadvantages depending on what the product is, the size of its market, the type of market, etc. and sometimes those advantages can't even be realised" ... just like you did the first few times...
The problem with a closed source effort is what we saw with Prism http://www.theguardian.com/wor...
The legal system and dev staff stay with the closed source product.
With open source code - when an issue is found days, months, years later it can be corrected, fully understood and fed back into further world wide crypto education.
The other option is to trust known weakened corporate encryption over many new versions and have faith in their legal teams
The other emerging aspect is that of US National Security Letters (NSL) for ongoing bulk collection 'efforts' vs a more global open source code.
After Snowden many more people will be looking at crypto, with open source code someone might be able to offer reviewed, tested fixes to junk standards.
Domestic spying is now "Benign Information Gathering"
Figures - I write a dozen thoughtful posts that get no love, but when I take a brain shart on a post, that gets the mod points.
you need to assume that your private keys and other SSL artifacts have been compromise. have fun regenerating your certs and getting them re-signed.
Any word on who was responsible for this bug?
Turning DNS registrars into CAs would be great because everyone knows exactly who owns yourbank.com. Key revocation would be easy, just publish a new key in your DNS record. Get a SSL page with the wrong key? Check the DNS record.
With address space layout randomization, I can't imagine how you could probe memory for sensitive information without causing the process to randomly crash. Given how polished the website publicizing the vulnerability is, I think they're more interested in creating hype.
I once had a signature.
RHEL updates are available:
https://rhn.redhat.com/errata/RHSA-2014-0376.html
CentOS updates are available:
http://lists.centos.org/pipermail/centos-announce/2014-April/020249.html
Fedora updates are available, hitting the mirrors, but you can get it earlier, instructions here:
https://lists.fedoraproject.org/pipermail/announce/2014-April/003205.html
https://lists.fedoraproject.org/pipermail/announce/2014-April/003206.html
Basically, an attacker can connect to many secure Internet services - could be a banking website, or your email server, or a server hosting software updates, or possibly your corporate VPN - and learn everything that the server knows. This includes the private key (sort of like a super-complex and super-secret password) that is used to *make* the service secure. The attacker can then get all the data that the server sees, ranging from normal user passwords to all your emails and banking info.
This vulnerability is many, many kinds of bad. I'm simplifying a lot here. Basically, an awful lot of data is at risk right now, because of this bug.
This site has a pretty great explanation that most people likely to be found on /. will be able to follow, even if not normally security types: http://heartbleed.com/
There's no place I could be, since I've found Serenity...
this is another example of open source advocates trying justify their idea of it being the one true model by attempting to solve the problem in the middle, rather than at the source. ultimately if they want to spy on you they will, one way or another and just securing your own computer wont help you.
this problem is at the legislative government level and that is where it needs to be solved, not at chasing your tail trying to secure your computer because as we have seen the vulnerabilities run rampant for years anyway. same thing goes for the DRM/copyright issues, the problem needs to be solved at the content production level, creating a free system in the middle doesnt help when the content producers wont permit you to have their content and infringing on DRM/copyrights only makes for a more hostile environment.
How much more of this has to happen before people admit that C is not an appropriate language for writing security-critical software?
Fuzzing isn't the only way of finding vulnerabilities in closed source software, not even close. And are you saying that source is required for exploit development? That's simply not the case.
Obvious fallacy ... what coffin? Since when has open source been dying for security critical applications? Since when has it been higher on the 'oh no' list of security vulnerabilities in real distributions than Windows or anything else?
Get your facts checked; on Windows, nobody would've found how to fix this until Microsoft did it for you (if ever). On open platforms, you can go fix this problem immediately.
- Michael T. Babcock (Yes, I blog)
The SSL core team all appear to be professionals.
I have not checked, but most of the contributors probably are too.
The same is true of most big open source projects (like the Linux Kernel).
The differences are:
1) There is better disclosure of bugs in open source
2) some bugs can be discovered by third party audit (as the GNUTLS bug was)
1.0.1c-3ubuntu
I'm sure the version is so much ubuntu tweaked that it doesn't contain the bug!
Why would NSA want to capture the children in the wild?
To get your version, run:
openssl version
Yes, I looked it up... in hindsight, I guess it was kind of obvious and I should have been able to figure it out. Anyway, it's done. Hope it saves someone a few seconds....
I don't understand why this is controversial. People consider it a bad idea to roll your own encryption code. Why isn't it a bad idea to roll your own bounds checking? Because it's easy and you won't screw it up? I'm sure people writing their own hash functions feel the same way.
Do people seriously prioritize speed over security? Of all of the things my computer might squander its gigahertz on, squandering them by checking bounds on things that will never actually be out of bounds isn't something I can disagree with if it makes the software running on my computer more secure. It's kind of like how, when doing math problems on a test, you check your work to make sure you get the right answer. Technically it's a waste of time if you know what you're doing, but if you're concerned about your grade, you do it anyway just in case.
Besides, if you want to whine about unnecessary wasting of CPU cycles, just look at an assembly dump of floating-point equations being solved in C as compiled by GCC. Anyone who actually knows how to do floating point in assembly language will want to cry. The round() function is a good example, as the documentation declares a specific way of rounding half-way cases which isn't what the FPU does and which anyone who knows how to use floating point math correctly will realize is a complete fucking waste of time since what the FPU does do is 100% adequate.
Once you have upgraded your copy openssl you can determine which processes need to be restarted by running the following command (only tested on Linux):
sudo lsof +c0 |grep DEL |grep libssl |awk '{ print $1 }' |sort |uniq
Note that just because a process is listed here doesn't mean it is vulnerable to the leak, it just means that it is linked to the vulnerable version of libssl.
And I must say it is far simpler and clear to use.
Two cents complete.
I am very small, utmostly microscopic.
Distributions using OpenSSL 0.9.8 are not vulnerable
This is why I haven't upgraded my Linux servers in 23 years.
Go fuck yourself, Steve Ballmer.
OpenSSL is an overly complex crapola, implemented in the super-crapola "C" from Bell Labs*. One more C bug that sells out the kingdom of your servers.
Brought To You By Your Friendly Commanding NSA General(TM).
"Bell Labs" as in "branch of government like NSA".
What if we used 3DES plus a pre-shared key to communicate with our bank ? Yeah, would work like a breeze and require about 3kbyte of code, instead of 5000kbyte.
Problem is that eyeballs are not sufficient. We need Mathematical proof.
See L4 from Uni Dresden.
But that won't happen or they will fuck with the proofs. Or pile tons of crap onto the protocol until the proof is sufficiently complex to be impossible to perform.
The 1% don't want secure comms of the 99%.
See this project of mine:
http://sourceforge.net/projects/sappeurcompiler/
And yeah, still very much prototypical, not nice etc. But I am convinced we badly need memory safety if we actually want to do something SYSTEMATICAL. Instead of band-aids.
Zontar's "touched in the head": schizophrenic multiple personality disorder http://slashdot.org/comments.p... + manic depression http://slashdot.org/comments.p... now go take those meds, you whacko!
Running 12.04 LTS and updated openssl to 1.0.1-4ubuntu5.12
System is still vulnerable. Seeing this reported on askubuntu as well. filippo checker confirms site is still vulnerable after upgrade
I call BS. We are talking FOSS here so there can be absolutely no security issue because it was produced by a large community of do-gooders who vetted all commits for us and this means that every bug gets caught within seconds of being committed.
It is a fact (not theory or guess) that only commercial, closed software has security flaws.
Well, it is a security flaw/hole until it's been plugged.
I've created an easy tool to check your site for the vulnerability.
http://rehmann.co/projects/heartbeat/
HumptyDumpty/OpenSSL took a great fall. All the OpenSORES eyes and horses, and all the OpenSORES eyes and men, couldn't put OpenSSL Humpty Dumpty together again (or even right the first time, hahahaha)
Android disables heartbeats (DOPENSSL_NO_HEARTBEATS):
https://android.googlesource.com/platform/external/openssl/+/master/build-config-64.mk
Chrome uses NSS, not OpenSSL, so it's a different SSL stack.
http://golang.org/
Fascism should more properly be called corporatism because it is the merger of state and corporate power. -- Mussolini
Filippo Valsorda's online tool for checking web servers for the Heartbleed vulnerability is quite an eye opener. As well as telling you whether the server is vulnerable, it displays a small snippet of the memory it retrieved (there are scripts on Github that will show you the whole 64KB I believe).
In the quick tests I did on login.yahoo.com (used for Yahoo's email and probably all other Yahoo services), I saw three different user's passwords and at least part of their usernames. And you can just sit there refreshing the page to see more! Madness!
Here is how you can test your servers to see if they are vulnerable.
Download this Python SSL Heartbleed test script.
Download it, rename it to ssltest.py, then run it as:
2bits.com, Inc: Drupal, WordPress, and LAMP performance tuning.
Amusing fact: the primary author of systemd is the same guy that brought us pulseaudio. Why do we do this to ourselves?
http://filippo.io/Heartbleed/ seems overloaded. You can also use http://submeet.net/tools/heartbleed.php in order to check a server's vulnerability to heartbleed
In other news, we can check everything quickly by not checking everything!
His comment is more interesting than your reply makes it out to be.
I've looked at a few disassemblies of compiled C code. GCC is already pretty good at understanding how variables interact within for() loops. If you make two nested loops, one for each index of a two dimensional array, it'll output code which simply uses a pointer that's incremented in a loop to access the array and check the pointer against a limit to determine when the loop is complete, such that the pair of for loops you wrote don't actually exist in the final code. It'll even switch the order of your nested loops if necessary to make this possible. If you perform a calculation inside of both loops that can be moved outside of one of them, it'll spot that and move the calculation outside of the inner loop. Write an equation in an unnecessarily verbose way that makes use of multiple unnecessary temporary variables? It'll notice and your temporary variables won't exist in the final code. Use the same sub-expression in multiple equations? It'll notice and calculate that sub-expression once and store it to a temporary variable. The compiler optimization isn't smart enough to turn your O(n^2) algorithm into an O(n*log(n)) algorithm, and indeed, what it does do is kind of basic, but it's still able to figure out quite a few of the more obvious optimizations, and in doing so it frees the programmer from having to worry about these more trivial things, which allows the programmer to focus their attention on things that computers aren't smart enough to do for us.
Thus, when it comes to code like this:
int a[100][100];
for (int y = 0; y < 256; y++) {
for (int x = 0; x < 256; x++) {
a[x][y] = x * y;
};
};
GCC wouldn't even think about outputting code to check the array bounds. It would check them as it compiles and decide whether to output the code without bounds checking, or, as in the case above, report that this code will always exceed the array bounds.
GCC already looks at code in enough detail that, if you call a small function that exists in the same source file, it'll notice its small size and inline it. I once had a pair of functions that each called the other recursively and saw that it chose to inline one of them within the other. So it would likely notice that the array bounds will be just fine even if you put your loop in one function and access the array in another as long as both functions exist within the same source file so that it is able to examine both functions at the same time. So, for the most part, it would only generate bounds checking where it is actually necessary: In code where the array index comes from outside the program, or in code where the index comes from within the program but through a complex enough path that even a human couldn't safely assume that they're 100% certain the index will always be within bounds.
So, most of the time, the compiler would correctly determine whether or not bounds checking is even necessary. Sure, sometimes it might be wrong, but humans get this wrong as well. The difference is that when the compiler gets it wrong, it'll err on the side of performing the check even when it's unnecessary, whereas humans tend to often get it wrong by leaving out the check even when it is necessary, or by attempting to perform the check but writing the code incorrectly so that the check fails.
As long as our software is doomed be screwed up in some manner, I'd prefer it be screwed up by being a bit slower than necessary, rather than having it expose data on my computer to any web site I visit.
Our OpenSSL-based software was logging heartbleed attack attempts to its logs by coincidence - it started on 23rd March already.
More details are here: http://www.seacat.mobi/blog/heartbleed
was private key leak prevented if we storaged the key in kernel and encrypted/decrypted in kernel?
Does anyone else see anything odd about the search results for this story?
I Googled "heartbleed" around 15 minutes ago and looked through 13 pages of results. I was looking for some info a little on the hardcore side, and the Google results were kind of surprising. There were tons of big well-known sites at the very top of the list - Fox, CNN, BBC News, Reuters and Forbes, etc; then a whole lot of mainstream "tech news" sites (PC World, ZDNet and so on) and blogs (HuffPo for example), then finally some more tech oriented or actual tech ones (YCombinator, Netcraft, StackOverflow) with a tiny sprinkling of blogs and relevant support forums (Cisco). US-CERT's listing was down on page 3 or so and honestly there just were not that many "hardcore" sites to be seen.
Running the search again after clearing cookies, the layout has changed a lot. The big news sites hits have slid way down (Fox News is on p. 3 now, for instance) with tech news and blogs moving up. All in all, the harder tech sites are floating upward and the less so are moving down. It's like the lava lamp version of a security scare.
Wondered what other Slashdotters think, it just seems a bit... strange, somehow. Don't these things usually bubble around in the tech community for a bit before surfacing in the mainstream world? It's like every big news site on the planet picked it up simultaneously, followed by the mainstream tech news site, and finally it began to filter down into the tech world. Could just be an artifact of Google's update cycle, but it definitely piqued my curiosity.
I cant decide - am I looking at an intentional misrepresentation, or a facepalm-worthy senior moment? Linus' Law had nothing to do with verifying code. From Wikipedia,
If opportunity came disguised as temptation, one knock would be enough.
3^2 * 67^1 * 977^1
Mac OS (10.9 at least) uses openssl version:
OpenSSL 0.9.8y 5 Feb 2013
so it shouldn't have the vulnerability.
People should not fear their government. Governments should fear their people.
That's not a fair generalization. Though there are plenty of "ideologically driven amateurs" — especially in the Linux (compared to BSD) world — they are mostly found among the noisy advocates, rather than actual developers.
Especially since a Dr Stephen Henson and the IETF member and security professional Robin Seggelmann submitted the bug, their CV:s are as professional as it gets. So please get real...
"known for 2 years"
No, no, this has been the code part of the stable release of OpenSSL for 2 years. The bug has only been known by non-blackhats for up to a few weeks.
Yes, the heartbeat exploit popped up just recently. ...
But the bug which forces users to keep data in freed buffers has been known for at least 4 years. Tedunangst calls it "exploit mitigation countermeasures"
Just use NaCl those guys are pretty good
"You barge into discussions with your off-topic hosts file nonsense" - by Zontar The Mindless (9002) on Friday April 11, 2014 @09:51PM (#46731153) FROM -> http://slashdot.org/comments.p...
You said my "APK Hosts File Engine" is a virus/malware http://slashdot.org/comments.p... but it's EASILY PROVABLE it's not, right there in that link too.
Now PROVE YOUR FALSE ACCUSATION above: Show me a quote OR POST of me posting off topic on hosts where they did NOT apply... go for it!
---
You avoided backing up your accusation where YOU said I say you are Barbara, not Barbie = TomHudson (same person http://tech.slashdot.org/comme... , & sockpuppeteer like you) -> http://slashdot.org/comments.p...
Funny you can't back up your "bluster" there either, lol...
---
Why, Lastly?
You're crackers! See here multiple personality disorder http://slashdot.org/comments.p... + manic depression http://slashdot.org/comments.p...
APK
P.S.=> So, THIS quote below is my policy on sockpuppeteers like you Zontar = TrollingForHostsFiles (your sockpuppetry):
"The only way to a achieve peace, is thru the ELIMINATION of those who would perpetuate war (sockpuppet masters like YOU, troll -> http://slashdot.org/comments.p... ). THIS IS MY PROGRAMMING -> http://start64.com/index.php?o... & soon, I will be UNSTOPPABLE..." - Ultron 6 FROM -> http://www.youtube.com/watch?v...
Which quite obviously, I am, since none of you DOLTISH TROLLS are able to validly technically disprove my points on hosts enumerated in the link to my program above of how hosts give users of them more speed, security, reliability, & anonymity... period!
(Trolls like YOU that use sockpuppets http://slashdot.org/comments.p... (your sockpuppet "alterego" TrollingForHostsFiles) & TomHudson - Barbara, not Barbie too http://tech.slashdot.org/comme... before you)
... apk
"You barge into discussions with your off-topic hosts file nonsense" - by Zontar The Mindless (9002) on Friday April 11, 2014 @09:51PM (#46731153) FROM -> http://slashdot.org/comments.p...
You said my "APK Hosts File Engine" is a virus/malware http://slashdot.org/comments.p... but it's EASILY PROVABLE it's not, right there in that link too.
Now PROVE YOUR FALSE ACCUSATION above: Show me a quote OR POST of me posting off topic on hosts where they did NOT apply... go for it!
---
You avoided backing up your accusation where YOU said I say you are Barbara, not Barbie = TomHudson (same person http://tech.slashdot.org/comme... , & sockpuppeteer like you) -> http://slashdot.org/comments.p...
Funny you can't back up your "bluster" there either, lol...
---
Why, Lastly?
You're crackers! See here multiple personality disorder http://slashdot.org/comments.p... + manic depression http://slashdot.org/comments.p...
APK
P.S.=> So, THIS quote below is my policy on sockpuppeteers like you Zontar = TrollingForHostsFiles (your sockpuppetry):
"The only way to a achieve peace, is thru the ELIMINATION of those who would perpetuate war (sockpuppet masters like YOU, troll -> http://slashdot.org/comments.p... ). THIS IS MY PROGRAMMING -> http://start64.com/index.php?o... & soon, I will be UNSTOPPABLE..." - Ultron 6 FROM -> http://www.youtube.com/watch?v...
Which quite obviously, I am, since none of you DOLTISH TROLLS are able to validly technically disprove my points on hosts enumerated in the link to my program above of how hosts give users of them more speed, security, reliability, & anonymity... period!
(Trolls like YOU that use sockpuppets http://slashdot.org/comments.p... (your sockpuppet "alterego" TrollingForHostsFiles) & TomHudson - Barbara, not Barbie too http://tech.slashdot.org/comme... before you)
... apk