Patch NOW: Six new bugs found in OpenSSL – including spying hole The OpenSSL team has pushed out fixes for six security vulnerabilities in the widely used crypto library. These holes include a flaw that enables man-in-the-middle (MITM) eavesdropping on encrypted connections, and another that allows miscreants to drop malware on at-risk systems. A DTLS invalid fragment bug (CVE-2014-0195, …
The only attackable (as opposed to NULL dereference crash or DoS) one if you're not using DTLS requires a server running 1.0.1 or 1.0.2.
While Apple is using 0.9.8 on its clients, even if it were also doing so on its own servers, there are plenty of OpenSSL servers out there iOS and OS X devices may connect to that are running 1.0.1 or 1.0.2, leaving them just as vulnerable as everything else. At least they don't use OpenSSL in Safari or Mail, so it isn't as easy to hit this problem as it is on other platlforms that use OpenSSL everywhere.
No wonder Microsoft IIS is about to overtake Apache in website market share...currently only 0.15% behind and rising sharply while Apache nosedives.
Everyone is fed up with the endless holes and patching with the 'LAMP' stack and similar Open Source security nightmares...
Doubt Apache is losing it due to IIS. Not saying IIS isn't gaining traction however your statement is stupid. Web server market share for Apache is more likely being lost to NGINX.
Now maybe someone should audit NGINX code :-)
http://w3techs.com/technologies/overview/web_server/all (take with a pinch of salt)
If I path my LAMP server I don't need to reboot. If I patch my Windows server I always need to reboot. So please get [censored] and [censored] yourself to biological termination*.
Microsoft makes good stuff, but it isn't better than FLOSS by any means. More to the point, all the stuff that once made Microsoft good is stuff they've outright abandoned. Easy of use being the big one.
Besides, the biggest issue with Microsoft isn't just how they are steadily making their stuff worse than previous iterations, it is that you cannot trust the company's business practices. Not as an end user nor as a "partner." Even more so when we start talking about integration of NSA backdoors into the products and services!
I certainly don't want NSA backdoors in anything I use. I'm sure there are some in the FLOSS apps and servers I use...but one by one they are being audited, cleaned, patched and so forth. The community's eyes have been opened and the problem is getting solved.
The problem can never be solved with Microsoft. There will never be a point at which Microsoft products or services are free of US government surveillance. There will never be a point at which Microsoft products and services are safer and more secure from those I consider to be my security concerns than FLOSS.
What's more, FLOSS has become the easier to administer option. Both have shitty UIs for everything, and both are basically "use scripts and command line to get anything done." But FLOSS has Webmin, and Puppet works like a hot damn. FLOSS can have most things patched without reboots and most changes applied live. Microsoft's stuff can't.
So yeah. take your shit elsewhere, or at least man the fuck up and use a name, instead of abusing the Anonymous Coward mechanism in these forums.
*An overkill desire, perhaps, for your comment taken in isolation...but I am really rather sick of you. Especially given that you refuse to put your name to your sycophantic bullshit.
Referring to an earlier discussion about open source, this is EXACTLY what was meant by doubting the statement that being open automatically equates to being safe.
OpenSSL hasn't suddenly become open source, it was so from the start. Yet only now someone who specialises in security analysis is combing the code do the security problems emerge, putting the many eyeballs idea finally to rest. However, Open Source then enables you to develop a fix yourself if suitably equipped (or by paying a developer), whereas with closed platforms you're left to wait until the supplier gets round to it.
"Open Source then enables you to develop a fix yourself if suitably equipped (or by paying a developer), whereas with closed platforms you're left to wait until the supplier gets round to it."
I can't stress enough how right you are.
"doubting the statement that being open automatically equates to being safe."
Doubting -in retrospect- a statement that no-one has made to begin with is an easy way to look wise indeed.
On the other hand "show me a piece of code that you think is 100% secure, and I'll show you a piece of code that I know to be potentially exploitable."
You can cite me on that anytime. The means of exploitation may not be obvious yet, or the vuln may need some tech that hasn't been invented yet, but "potentially dangerous" is a certainty for code. ANY code. The good thing with open code is that vulns are weeded out rather quickly, and constantly. Don't give me that "2-years" or "10-years" crap: yes it happens, but rather rarely AND closed source is demonstrably worse: thousands upon thousands of "national-security"-grade plants are still running closed source control system software that is much more easily exploitable, and much more difficult to patch. Due to schoolboy-grade bugs that are almost 20 years old.
Things like this for example: http://www.bbc.com/news/technology-26881970
Now imagine how it is for less-critical stuff. To give you an idea, at work I upgraded 3 desktop machines from WindowsXP to Windows7 3 weeks ago. Windows7 was released in 2009, that is 5 years ago, give or take a couple weeks. Guess how many times a week it still needs a security update? (and I think it's a bloody good thing, too: see my statement above).
"a statement that no-one has made" ? ROTFL.
It was made by many, and repeated over and over. Now that is evident the codebase is too large and too complex for any kind of true peer review, and most FOSS users are exactly that - just users who install the software from precompiled binaries and have no programming skills thereby they have to trust what they install - no difference with closed source code - many try to pretend it was never said and hide behind a finger. C'mon, it's not the end of the world, after all most people use FOSS because it's cheaper, not because it's more secure, and that's not going to change.
And it is also false that "with open code is that vulns are weeded out rather quickly". When discovered, maybe, if that code is still maintained by someone. But closed source code has behind it a dedicated group of developers who are *paid* to maintain it - and MS became pretty quickly in delivering fixes, it had to (the monthly cycle is for sysadmins needs, delivering patches in critical production system needs care) - do you really believe they do not improve and fix it even when there are no disclosed vulns? I'd suggest you to try to work for an ISV - a good one, of course -, once in life. MS too delivers a lot of improvements and fixes beyond security stuff. Do you ever read what Windows Update delivers?
"closed source is demonstrably worse" - where's the proof? The link you post is just a sample of a single application - how many applications also run on FOSS software and are full of bugs, and running on outdated systems because nobody wants to fix and upgrade them? I've seen a lot of systems running old Linux releases, buggy kernels, outdated and vulnerable Apache and PHP versions.
I've a team of VA/Pen test experts, and they pierce through closed Windows-based and FOSS-based applications as well. What matters there is just the developers skill and training. Good developers will write good software, closed or open, lame ones will write lame code, closed or open.
Sure, the source code helps patching - just you can have source code even if it's not "open". I have customer who paid for the source code, and I have paid source code for libraries and applications which are not "open". And yet, to patch some code, you need someone really skilled and with a deep knowledge of the application domain - plus a whole build and test system s- sometimes you can afford both, sometimes you can't, thereby there's very little difference if the code is available or not, you're in the hands of the code/application supplier anyway.
"It was made by many, and repeated over and over."
Proof?
" where's the proof? The link you post is just a sample of a single application"
A single application that leaves 7600 national-security-grade very large plants wide open to pretty much any script-kiddy with no particular skill. Trawl tech news and you'll find plenty such examples, including powerplant control software and the like. Looks pretty serious to me.
"And yet, to patch some code, you need someone really skilled and with a deep knowledge of the application domain"
True
" - plus a whole build and test system s- sometimes you can afford both, sometimes you can't, thereby there's very little difference if the code is available or not, you're in the hands of the code/application supplier anyway."
Also true.
But in one case you get something that you -or someone of your choosing, or anyone- can check. In the other case you get something that you can't check, that you KNOW may have not been checked by anyone (because who has spare money for extensive checks when they know that you already paid and no-one can point the finger at you, ever, anyway?).
Sorry but put in the light of pure profit logic, your post suggests that closed-source software is necessarily bad. Now my guts tell me that it's not what you mean. Peraps the problem is that you posted this on your spare time, that would explain why your argumentation is blatantly full of holes. You should hire someone to make the argument for you. I'm pretty sure it would be better (can't be worse anyway).
Oh, just so that y'all know: most open source developpers are not unpaid enthusiasts: they are skilled developpers who are paid for their work and don't fear putting their own name behind their work. The same ain't true for closed-source software.
"A single application that leaves 7600 national-security-grade"
How many national-security-grade applications has been vulnerable in the last two years due to the "heartbleed" vulnerability? How many embedded system that could be gateways to critical systems will be left unpatched?
"But in one case you get something that you -or someone of your choosing, or anyone- can check. In the other case you get something that you can't check,"
False. I told you. In most cases you can check source code even if it's not open. You can also check Windows code, for example if you are a "national-security-grade" organization, and even if you are not. You may not fix it yourself, true. Why do you believe good organization set up VA and pen tests against the software they use? Exactly because they want to spot issues, regardless the software is open or close. Perusing over source code is not always the best way to spot issues. Often it's just a "post-mortem" assessment to understand where an issue stems from. Source code review is an expensive task - regardless if the code is open or not. You need experts, and a lot of time.
"you KNOW may have not been checked by anyone " - that's also true for FOSS. You have no warranty someone checked the code after it has been written and deployed. It could, but you can't know. Yet good closed source code goes through a lot of checks, especially in some sectors, including code reviews.
"Sorry but put in the light of pure profit logic". Profit has many facets. Quality is one of that. High quality products may sell better than low-quality ones.
"The same ain't true for closed-source software". Is it? Most developers want to show their names in good and successful closed source applications - just look at the "about" box, usually.
" most open source developpers are not unpaid enthusiasts" - yet many are. OpenSSL has been developed by a small group of unpaid ones, it looks... and without the proper QA infrastructure to support them.
"posted this on your spare time". Sure. I'm not paid to post here.... nor I steal my paid time to do it.
False. I told you. In most cases you can check source code even if it's not open. You can also check Windows code, for example if you are a "national-security-grade" organization, and even if you are not
Just like China can inspect the code for Windows 8…
China has been able to inspect Windows code since 2003. Now that there's an ongoing "cyberbattle" between US and China is no surprise MS could deny China the code now. But probably you didn't notice what happened in the past eleven years....
Surely you missed this: https://www.microsoft.com/en-us/sharedsource/default.aspx
If you don't qualify, it's a problem of yours....
> " most open source developpers are not unpaid enthusiasts" - yet many are.
Uh, what about "No, they aren't, and you're full of shit" ?
"Sure. I'm not paid to post here.... nor I steal my paid time to do it."
Actually I'm not sure how you ended up here. Pretty sure you don't "steal your paid time" for it, as you put it Not totally sure that you're not paid for it though, but if so it's most certainly a waste of money.
"Yet good closed source code goes through a lot of checks, especially in some sectors, including code reviews."
The paradigm espoused by Bill Gates et al for many years has been "Ship it first, fix it later", along with "Don't waste time rewriting bad sections, bang a patch on and continue"
This mindset has permeated through most consumer software. We have TRAINED endusers to expect computers to be unreliable, that the best way to solve a misbehaving program is to reboot and that new features are more important than fixing old bugs.
If you really believe that closed source is heavily audited (or even audited at all) except in a few corner cases then I have a bridge I'd like to sell you.
The paradigm espoused by Bill Gates et al for many years has been "Ship it first, fix it later", along with "Don't waste time rewriting bad sections, bang a patch on and continue"
Also known as "Worse is Better" and an important part of the Unix Philosophy. Gates didn't invent it, he just embraced it whole-heartedly.
We're still at the low hanging fruit stage of fixes for these packages. In crypto & security there are some damned subtle problems that will haunt you for a very long time. Throwing money and additional eyeballs at these problems is a start. Given the core nature of these to proper/secure operation, which expert(s) are on deck?
But closed source code has behind it a dedicated group of developers who are *paid* to maintain it - and MS became pretty quickly in delivering fixes, it had to (the monthly cycle is for sysadmins needs, delivering patches in critical production system needs care) - do you really believe they do not improve and fix it even when there are no disclosed vulns?
Come now, are you suggesting that every enterprise will just jump at every vulnerability reported and immediately release patches?
You ever tried reporting a bug to level 1 help desk support? (The only people one can reach, as it happens?) I had this with Netcomm with some of their 3G M2M routers. Not a security issue (although I'll bet they're Heartbleed prone), but a significant oversight in their OpenVPN implementation: inability to specify the cipher. OpenVPN defaults to Blowfish, Untangle (which is OpenVPN-based) uses AES128.
They couldn't see why we didn't just change our encryption settings: neglecting we had existing routers on military bases and mines that we couldn't easily access. Something we'd need physical access to do safely.
Most helpdesk systems are designed to sweep bugs under a rug. You can't see what issues others have reported, just your own. It gives a "bug free" appearance, but it means that others' solutions and workarounds are invisible to you, and it also means they have to work harder resolving needless duplicate reports.
Open Source projects by in large, use publicly open bug trackers, and only do things in private when there's a serious security issue.
As for time taken to patch: well, time can vary for both sides. Commerce will generally wait until it's economically convenient (sometimes that's immediately, sometimes never). Open Source teams will wait until they have time.
"You ever tried reporting a bug to level 1 help desk support? (The only people one can reach, as it happens?) "
It depends on what kind of customer you are.
" their OpenVPN implementation"
Oh, an open source code... beware of those who employ FOSS not because it's better, but because it's cheaper to do so...
"Most helpdesk systems are designed to sweep bugs under a rug. "
Change suppliers. You're using the wrong ones. I have several I can access their bug tracking system and see what others have submitted - maybe non everything, true, but almost. Sure, maybe I have to pay support - but not always going the cheaper way is better.
"You ever tried reporting a bug to level 1 help desk support? (The only people one can reach, as it happens?) "It depends on what kind of customer you are.
One that bought their product.
" their OpenVPN implementation"Oh, an open source code... beware of those who employ FOSS not because it's better, but because it's cheaper to do so...
Mmmm, yes, OpenVPN is open source. Netcomm's web interface, isn't, and it's that, which was preventing us from configuring OpenVPN properly.
Once we knew enough to hack up Netcomm's scripts to do what we wanted, it worked. But, I had to get through their L1 support first.
Then they superseded that model, and we had to go through the whole exercise yet again.
"Most helpdesk systems are designed to sweep bugs under a rug. "Change suppliers. You're using the wrong ones. I have several I can access their bug tracking system and see what others have submitted - maybe non everything, true, but almost. Sure, maybe I have to pay support - but not always going the cheaper way is better.
Ohh, we're doing that already. I suspect we've bought our last Netcomm modem now.
We've found one, at the recommendation of one of our clients which looks good as an off-the-shelf router, and we've also found a supplier for industrial computers that sells some low-cost Linux-based devices, some of which can do 3G and could easily run OpenVPN along with any software we want. (Debian/ARM-based OS, and we already build our software for Ubuntu.)
"If you aren't big, you don't matter" That's life... in how many fields you get privileges only when you're "big enough"? Every vendor has special privileges for "big customers", do you discover it now? Even those selling you FOSS software - do you believe Red Hat treats the basement developer the same way of a big company, or a governative one? How would you deal with a customers that buys 10.000 licenses of your software and one that buys only one?
Anyway MVP are not big - just "important". You get code access in exchange for support. Looks fair to me.
Unless the customer themselves are assholes - I.E. sociopathic or possessed of an intolerable personality - then I would treat the 10,000 unit customer the exact same as the 1 unit customer. The rationale is simple, and based in raw economics:
1) End customers and SMBs are used to getting the short end of the stick. Treat them well and they will tell others.
2) Today's 1 unit customer is tomorrow's 10,000 unit customer. Businesses grow and change, and I think past the end of this quarter.
3) I would rather have 100x 100-unit customers than one 10,000 unit customer. I don't like the idea of all my income being dependent on one (or a small collection of) businesses/individuals. That gives them massive amounts of power over me, and I went into business so that I could RAID 6 my income.
Treat people decently and they'll keep coming back, often times with a friend. Treat people like shit and word about that will spread a dozen times as fast. Or, put simply: obey Wheaton's law...
...don't be a dick.
Ever tried reporting a problem to Open Source Developers. Their answer is usually, no answer or its the way you're using it or no-one else has that issue. People often don't report issues because they never hear anything back or the answer is usually some smartarse answer blaming the user.
This issue has shown that Open Source is just as prone to errors as Closed Source. The Open Source people have just fallen off their hobbyhorse and are trying to point the finger elsewhere.
I thought part of the problem with OpenSSL was that there were too few people involved. There was a very small team (3 people?) who wrote and maintained it. QA and testing needed to be done by a larger team which just didn't materialise.
The good thing is that we know there were 3 people involved, none of them an unpaid summer intern.
Now, when you buy in a closed-source piece of software that "securely" controls how your customers pay you... can you safely assume that it wasn't put together in 2 weeks by an unpaid summer intern?
[DISCLAIMER: no unpaid summer intern was harmed in the making of this post. Unpaid summer interns are what keeps the industry afloat, else we would have to pay developpers, that means cuts in the shareholders' dividends or management junkets, god forbid]
And still they wrote lame code because had to write it in their spare time (maybe with a wife shouting "turn off that damned PC, it's Year's End, come here and spend some time with the guests, my mum told me I should not have married a nerd! John the lawyer doesn't spend all the time writing code for free and drives a Ferrari!") without being paid to write good code and with a QA team ready to test what they wrote.. and no one will fire them if they keep on writing lame code.
And still they wrote lame code because had to write it in their lunch time (maybe with a boss shouting "turn off that damned PC, it's months end, come here and spend some time with the accountant/customer/quality assurance bloke what never saw a line of code in their lives).
FTFY
If you believe that spending time with customers and QA is wasted time, because they "never seen a line of code", thereby they're not nerdy enough to be your peers, well, you show the stupid attitude of many nerds that believe IT should be the realm of nerds only, made by nerds for nerds. That leads to nerd-designed software for nerds, that everybody else simply don't use because often nerd-friendly means user-unfriendly. And if OpenSSL had some QA, we would not be here talking about it...
If you buy in a closed-source piece of software, the law affords you certain protections. Namely that the product is fit for purpose. Failing that, the act of purchasing gives you a target for any legal action.
Open Source is a good thing, and can be, theoretically, more secure than closed source. Simply because more eyes can, again theoretically, see the code. The fact they can, unfortunately, does not mean they do.
If you buy in a closed-source piece of software, the law affords you certain protections. Namely that the product is fit for purpose. Failing that, the act of purchasing gives you a target for any legal action.
The exclusions you have to sign up to for license seem to prevent any sort of buyer protection. Why do we not object? Mainly because this approach also gives the smaller shops an ability to also generate an income and give us clever stuff without losing it all immediately on insurance, so it's something we have to live with.
"OpenSSL hasn't suddenly become open source, it was so from the start."
As previously mentioned, OpenSSL has suffered from the complacency that comes from being around for so long that people assume someone else must have already checked it.
"...The complacency that comes from being around for so long that people assume someone else must have already checked it."
There is a LOT of software which matches this description - and I encounter plenty of resistance to updating away from it, usually with this justification being rolled out.
Newer code tends to be "safer", because people are more paranoid and actually check it.
I shudder to think what even simple static testing of the source of the average linux/bsd distribution wiould show up and yet that's likely to be the tip of the iceberg (closed source is no better).
putting the many eyeballs idea finally to rest
Does it? Bit of a tree falling in the forest scenario. Just because people could have been looking, doesn't mean they were. Still doesn't change the fundamental idea of "with enough eyes, all bugs are shallow" (though you may argue about the smarts behind the eyes, if you wish).
"Yes, grashopper. Non high assurance code for tasks needing high assurance code .... IT WILL HURT YOU."
(Maniacal laughter continues. Fade to black. Then a shot is heard. )
"The sudden proliferation of OpenSSL bugs is to be expected and a good thing. Like finding dirty socks during spring cleaning,"
Absolutely. But we really have to step it up.
Btw..
1) Isn't today Snowden aka. "Summer of Surveillance" 1-year anniversary? Coincidence??
2) http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0224: "Unable to find Vuln"... WUH?
@DAM -> moi aussi. (for both)
@Dan55 -> I see what you did there.
@ AC -> Quick to fix in Open Source
Open Source isn't better only because of the many eyes. Open source has the advantage of (anyone) being able to say -> oh hell this has been here since day one.
Rather than with closed source *this is a new bug*. And not knowing. Furthermore "someone who specialises in security analysis" could have looked at OpenSSL any time they liked in the past. That someone who does has chosen to do so now, well, there's a whole other bag of discussion.
Might be wise to note that there's been a ton of money thrown at openSSL recently.
"Security through public reviewing" can be worse than "security through obscurity" depending on the scenario at hand.
If a given "package A" attracts more "many eyes" from miscreants than from white hats then you're in deep shit. Given that white hats will usually do it "on good will" and miscreants will usually do it "for the money", who do you think is more motivated?
And while closed source will force miscreants to try "what if" scenarios before landing a successful attack, with open source you can just point and say "look, there it is". No trial and error because the source itself will confirm it.
Now, that doesn't mean open source is necessarily worse, but does mean you have to do your best to make it airtight from the go, especially regarding security related software, because you can't, or shouldn't, depend on the first person to spot a bug being "a good guy".
p.s. on a side note, that might be the RightWayTM for M$ to kill XP for good. Release the source. Would we be running for the hills... Heck, even so much as release only source to things that they've already changed. Should pretty much bring in a steady stream of 0-days with world+dog searching for bugs and M$ not releasing fixes. But maybe it's so bad they're too embarrassed to show it.
"Security through public reviewing" can be worse than "security through obscurity" depending on the scenario at hand.
Neither approaches work - though I do have fun sending white noise files about the place.
GIGO testing needs to be used a bit more though it is an art not a science - unless anyone knows better?
OpenSSL: Where gross incompetence, kindergarten-level maturity and absolute corruption meet.
OpenSSL's latest success story? Intentionally, specifically, completely, proudly and possibly profitably withholding notification of this group of bugs from Theo, OpenBSD and LibreSSL.
That's gotta be worth another $2 million USD.
This post has been deleted by its author
...running in circles, chasing tails.... systems are too complex, way too many potential variables and vectors for vulns.
Fuck it, go out in the sun, have sex, take some drugs. Computers used to be fun. Now it's all just a big fucking bore.
My two pence. Not interested in whether you agree or not - I have nothing constructive to say, I'm just done with IT today lol ;)
Unaffected by this OpenSSL issue perhaps, but IE and Office feature again in this month's Patch Tuesday announcement (https://technet.microsoft.com/library/security/ms14-jun) with two critical remote exec vulnerabilities. BTW, my OpenSSL is already patched - stick that in your pipe and smoke it.
I recorded a podcast about this latest vulnerability a few hours before we went public talking to Mark Cox one of the founder members of the OpenSSL Foundation and Head of Security at Red Hat who have been involved in the build testing and push of updates to fellow Linux distributions, service partners and the embedded device community.
The podcast is available on thecloudevagelist.com website or iTunes channel or by clicing http://bit.ly/Th64oP
http://thecloudevangelist.com/ 10 minutes mp3.
Deserving a downvote for the "bit.ly" link obfuscation and MITM spying; not for the "evagelist" typo.
Ok, granted not all closed-source software companies are dicks but in general many are. With Open Source you point the flaw and everyone is up in arms scream how crap open source is and then of course nose onto screen to start patching.
With some closed source companies, of which I can think of one example starting with the letter V and ending with the letter W that will simple take a gagging order out on you to stop you saying a thing. No one knows if the problems have been fixed except that the ones making the report are now silenced.
<sarcasm_on>
So if there is a bug in your code. Get a gag order. Job done, bug destroyed
<sarcasm_off>
http://www.theregister.co.uk/2013/07/28/birmingham_uni_car_cracker_muzzled_by_lords/
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
