Slashdot Mirror
2014: The Year We Learned How Vulnerable Third-Party Code Libraries Are
jfruh writes Heartbleed, Shellshock, Poodle — all high-profile vulnerabilities in widely used libraries that rocked the software industry in 2014. Sadly, experts are now beginning to believe that these aren't the only bugs lurking out there in widely used open source code, just the ones that grabbed the most attention. It's beginning to look like one of the foundation concepts of open source — that with enough eyes, all bugs are shallow — is a myth. Of course, probably no one believes that all bugs are instantly shallow, no matter how open is the source, or that open source software is immune from bugs -- particularly ESR, coiner of the phrase.
Good luck with your "Free Internet" campaign without open source.
The phrase might be true, but we're seeing the effects of insufficient eyes. In reality, how many sets of eyes are actually reviewing these libraries at a source code level? I rather strongly suspect that in most cases they are simply used under the assumption that "well, everyone uses it, it must be okay".
Shellshock did not affect a "library", but an executable.
Open source, closed source, they have the same problem: 1 vulnerability is now shared across every app that uses that library
So why do we use libraries in the first place if they are so flawed? They cut delivery time and maintenance costs down by a huge chunk
In context rolling your own code to do the same work seems preferable but its vulnerabilities are limited to YOUR codebase and YOU gotta fix it (versus an army of OSS people who are shitting their pants that their library is in the news again)
So yeah, despite the problems I'll stick with OSS libraries
the big news is that people are now thinking that bugs in software is big news.
My magic 8 ball tells me that in 2015 we will learn that proprietary and embedded software is even more vulnerable. My Tarot Card deck tell me that we will see a lot of hacked car wrecks in 2015, now that Volvo released the demon by putting a web browser into in-dash system. Rest of the lemmings are sure to follow. Not that you really need a browser to pwn a car, with Bluetooth-to-CAN-BUS exploits shutting down cars demonstrated as early as 2012.
I don't know anyone that ever thought "Open source" was bug free. The point is that people can more easilly find and fix bugs with open source. With closed source, there could be some obvious and dangerous mistakes in the code but no-one but those with access to the source will know it exists. It's then up to whomever owns the source to decide if it's profitable enough to fix it. The problem with that system is there are people with access to the source... People come and go from every company on earth every day. So they're finding these vulnerabilities, and leaving the company with them. They can sell these to whomever they wished if they so chose. The NSA and others like them probobly have all the major players broken so they can view the source as well. The point being is that closed source is only closed to YOU With open source, you can look at the code yourself, and if you see a bug the general community doesn't think is a big deal and doesn't want to fix... if it's in fact, a big deal to you, you can go right ahead and fix it yourself.
Whether it's OpenSSL or Windows APIs hackers are looking at every possible vector to attack systems. To be honest with ourselves, the software engineering community has to realize that security must be given the same priority as any other code quality metric. While we may not be able to test for every possible vector there should be a standard set of vulnerability tests that every organization should be able to test for before releasing code. Likewise regression tests need to be exercised prior to any subsequent release of the system. I also think that software engineers need to be more objective with themselves and to think more along the lines of how their frameworks/systems could be attacked. Of course that's never going to solve the insider problem as far as attack vectors are concerned but it should go a long way in addressing these kinds of problems.
Harrison's Postulate - "For every action there is an equal and opposite criticism"
Is that with FOSS, decent developers can fix bugs and keep moving on a deadline. We found an oversight in Apache Storm's HDFS integration that affected us, but not most users. So I patched it and sent it along. Had it been an Oracle product, not an Apache product, it would never have happened on a timeline acceptable to our schedule.
Security bugs? I like to throw this one out there at people who think big companies cannot unleash epic stupid on their paying customers that makes even most 0.0.1 projects on GitHub look production-ready.
The security of the open source model isn't really the problem or the answer here. The problem is homogeneity. A million different sites and applications rely on just a few libraries, so that when a bug hits one, it has massive impact on the entire internet.
We also know that the answer isn't in rolling your own security. Very few people or organizations are likely to be able to securely implement their own version of TLS. Even the best packages of today didn't start out perfect, they had to iterate through several flaws to get to where they are today.
So perhaps the better answer is in having more packages to choose from? Instead of picking just openssl by default, it would be better to have a broad array of choices. With a dozen packages on the market, that might mean 11 times out of 12 the bad guys wouldn't exploit our site. If the packages are interchangeable, we'd be better positioned to switch them quickly in case of emergency.
John
In the cases that were software defects, the defect was rapidly fixed upon discovery. That's really the meaning of all bugs being shallow, not that they won't ever exist.
That said, POODLE is not a code defect, but defect in the standard (well, except the bit where an implementation skipping validation of the pad). Shellshock was indeed a grave defect, but I think a correct takeaway there is to avoid having a shell language be in the path where untrusted data could be injected as much as possible (as well as fixing it). A fair amount of noise has been made in some circles along the lines of 'told you so, open source is riskier than proprietary', though in the same time frame we've seen Apple's implementation have 'goto fail' and Microsoft's SChannel has also had at least one recent issue.
The short of it is code is not magic. If code is taken for granted, it will be neglected (whether OpenSSL or some boring proprietary function well out of view of marketing concerns). Neglect in security centric libraries is particularly dangerous. In this case, I think Heartbleed panic was the proverbial tide to rise all boats, causing investment across the industry in scrutinizing all TLS stacks.
XML is like violence. If it doesn't solve the problem, use more.
You are wrong, each and every person connected to the internet is an open source user. Open source iis first and foremost used on the planet, your email for example isn't routed around the globe by Microsoft Exchange servers, nor global DNS done by Active Directory servers.
The hundreds of thousands of bug reports submitted and successfully used to patch open source prove you are blathering about a process you don't understand.
You also are a moron with no understanding of how your computing world works.
The quality of open source software is kind of crusty these days. No matter how open it is, making stuff work properly should be priority number one.
For example, try to adjust the display brightness of a laptop under Mint or Ubuntu. It goes in multiple steps because there is multiple listeners for the adjustment event. Even basic stuff like this does not work properly.
Open-source does not make code automatically bug-free. No more than using a safe-malloc-library does, or deploying DEP on your executable, or ASLR, or coding only in a language that's considered "secure".
What it does is allows certain types of security problems to be POTENTIALLY spotted. It's a +1 on the score, not a game winner. And it doesn't mean that proprietary is -1, either. It just means that you are so confident in the quality of your code, you can show people that by opening it up.
What gets me about proprietary software is not that they choose to do it so their rivals can't copy (a bogus argument in any country that properly enforces licensing agreements, which is why you can get a peek at MS code if you have a need to), but that they are SO ASHAMED of their code they don't want you to see it.
The 3DFX card drivers, for decades, basically allowed complete DMA access to all of RAM. It was that easy. But nobody could spot it because nobody could see the 3DFX code. You don't get that in open-source drivers and the SECOND it's spotted, by anyone, it will get fixed. That's the difference - the reaction. When we found these problems, they were urgently fixed immediately. When we find problems in proprietary code, it can be (as recent articles state) known for 90 days or more without anyone bothering to even look at them.
Open-source isn't security. But it's like saying to a guy, at a security conference, "Here, I'm so confident in my gadget, that I'll let you play with it". Sure, he might break it, he might compromise it live in front of all your customers. But in an technology sector concerned with SECURITY, not profits, that's actually exactly what you want and the perfect impetus to keep improving so that next week you can do the same again, and again, and again until you've ironed out most of the bugs. You'll NEVER get them all.
But the confidence to do that is critical. I've been at tech conferences for my sector where suppliers hand out products and, in the space of a few minutes, I point out massive flaws and problems with them. They soon stop handing them out for people like me to play with. That's not the attitude to have when it comes to security, but I understand why a business would do that.
It's not the be-all-and-end-all but it's a nice thing that does not hurt to do. Those that don't understand this do not have security uppermost in their mind, only oneupmanship, and "my OS is better than yours" crap.
In security, and cryptography especially, given your enemy the source is a show of bravado and confidence. It's like the old backup adage. If you're so confident in your backups, high-availability, failover, etc. then why are you not prepared to let me take an axe to your primary server? If I was in charge of a large company and my IT guy assured me the disaster recovery was so easy and already-in-place, I might well choose to say "Yes... go on. Take an axe to it.", if nothing else than to see their reaction and see the plan kick into place.
Passing that test would cement your place on my team for a long while. Failing or chickening out of it might well mean I test it more regularly and keep a close eye on you.
Open-source doesn't have automatic properties. But it a checkmark in your favour if you're claiming to write software well that millions of people might choose to use.
I don't know anyone that ever thought "Open source" was bug free.
Every FOSS fanatic on Slashdot for the last 17 years has implied that bugs would be found and fixed FAST - not linger for years.
The point is that people can more easilly find and fix bugs with open source.
They could but do they? Nope.
ESR's claim has nothing to do with the frequency or discovery of bugs. All he says is that given enough observers, bugs are quickly characterized. It is implied that any given bug has already been discovered. There is no benevolent cohort of experts continuously auditing code bases and his statement doesn't claim there is.
Lurking at the bottom of the gravity well, getting old
So all we need are 11 more sets of programmers to program free version of SSL 2-12?
(esp. with the title) In 2014, with all that panic, we saw/learnt that professionals (admins,programmers,huge companies, e.t.c.) use the open-source code irresponsibly. Also, 2014 taught us that when someone gives us candy, better double check it before we consume it.
An open source project can have as few as just one set. There are some projects that nobody other than the developer ever contributes to. Just one guy occasionally working on some little project that some people use. Those all those people COULD look at the code, they don't.
Likewise commercial firms can, and sometimes do, pay many people to look at the code. In addition to having a big development staff they can have dedicated QA staffs. They can have a person, or many people, who's job it is literally to sit and look over the code for security issues every single day.
You are buying in to the same fallacy that the article is talking about: That because something is open is just means that more people MUST be looking at it. No it means people can look at it, but they may choose not to.
Exactly. Saying bugs are shallow doesn't mean they don't exist. Shallow vs deep refers to how much effort it takes to characterize and fix - is it a "hard" bug or an "easy" one. Wikipedia explains it well:
As the Heartbleed bug shows, even shallow bugs[7] may persist in important pieces of open softwareâ"it took two years for the bug to be discovered, and the OpenSSL library containing it is used by millions of servers. Raymond said that in the case of Heartbleed, "there weren't any eyeballs".[8]
When it was discovered that there was a problem, many eyeballs starting looking at it and it didn't take long (hours) for someone to clearly identify the problem and the solution.
In contrast, there is code at my workplace that only I look at. There are intermittent problems that have persisted for MONTHS. I'm just not seeing quite what the cause is. If 1,000 other programmers looked at it, one them would probably spot the problem right away. It would be shallow _to_them_.
Has anyone noticed that there are now astronomically more OSS users now? The number of OSS users is also growing at an exponential pace.
What we should expect with those stats is that there should be more cracks and bugs in OSS due to the higher percentage of people programming/using it.
Also, as the value of OSS increases to the market and more information are handled by OSS there is more incentive for old vested interests to search for the downside as a form of marketing. We never heard about all those MS Windows security deficits until years after the fact. Well after they had been exploited by te NSA.
It's interesting that SO FEW bugs have caused issues in OSS considering the sale of that ecosystem.
There is also more incentive for companies protecting turf to pay OSS project insiders to plant exploits as a way to undermine that.
It's better to rely on 'Repairable By Design' than 'Defective by Design' .
So "Security through complexity" then?
Sounds complex.
Mod me down, my New Earth Global Warmingist friends!
Unfortunately, assuming the number of developers is constant, with 12x as many libraries every one of them is virtually guaranteed to be far less secure than if all the developers were working on improving the same library.
So the root of the issue is that we need to dedicate more total resources to development, auditing, etc. the fundamental security libraries. Whether the best outcomes would then be seen by focussing all those resources on a single library, or spreading them across multiple competitors, is a seperate question. Somehow though I suspect that having 12x the resources focussed on a single library would be far more effective than having 12 competing libraries all staffed at current levels - wherin the majority of labor would be independently duplicating effort between projects. With enough resources there might be some benefit in having two or three competing implementations under development, but I suspect we're currently a long way away from "enough".
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Corporations like Apple and Google have been making their billions by exploiting open source, without giving much back. These bugs were in libraries that corporations built their businesses on, and lurked while the corporations made their money. Billions of dollars later, these understaffed and underfunded projects still had the bugs, and instant karma got the corporations for a change when the exploits started coming. Shows us a lesson in how vulnerable to exploitation open source is, and big corporations wouldn't have it any other way.
So all we need are 11 more sets of programmers to program free version of SSL 2-12?
Yes, and demand for them. But the big problem you're correctly implying is there's no economic justification that will drive this behavior. Maybe it will take a dozen big companies and foundations to drive this. Imagine if IBM, Microsoft, Google, RedHat, Yahoo, HP, Dell, Apache, Wikimedia, Mozilla, FSF, Apple, Intel, AMD, nVidia, Bungiesoft, and others each contributed their own versions of openSSL; each written in their own choice of language, using their own code, and building their own implementations of everything from the crypto through the command line interpreter logic. My company may decide we do more business with Intel, so we choose theirs. Or your company may be more Apple focused, so you'd choose theirs. In every case, we'd all nervously watch each other looking for signs of intrusions, hoping we won't be the victims, but knowing that alternatives exist if we are.
While a 1/12th scale incident of Heartbleed is still a huge problem for a lot of companies, it's no longer the catastrophe-sized disaster that Heartbleed actually was.
John
3) Port to to multiple architectures (and OS's) to catch bugs not reported by the original build environment. This is one of the approaches OpenBSD uses to improve security and was quite common in the open source software world when ESR coined the phrase.
The OpenBSD team found one very long lasting (30+ years) bug in the legacy BSD code when the Sparc64 build barfed.
A Shadeless room is a brighter room.
2014: The Year We Learned How Vulnerable Third-Party Code Libraries Are
Really? Like we did not know before?
I don't think anyone in the industry who is both sane and honest ever pretended that FOSS was bug-free.
We know that software, ALL software, contains bugs.
Also, plenty of projects don't have too many contributors, so the "many eyes" principle hardly applies.
But if you've got the source at least you can have a look, (and really should, if you are considring using something for a mission-critcal application).
Then fix, if required,and contrib back.
Certainly, vulnerabilities in FOSS stuff tend to get fixed pretty quickly when found.
When the Heartbleed vulnerability was found, there was spotted another OpenSSL security vulnerability which had not been fixed for 4 years and it even had a public CVE record in place.
Actually the number of developers ( and developer effective effort ) that would work on such a library is not constant. Once you get too many developers on a single project a larger effort is required to required to just for code / development syncing. The other issue is especially with open source developers is not all developers are interested in working in the same development models among other issues. Which means single projects tend to discourage some potential developers from joining in. There also is the issue of developers wanting to feel helpful a good developer will often feel more appreciated on working on a smaller project.
Finally just because implementations are separate does not mean that their is not cross pollination. Fundamental concerns found by one project are very likely to be searched for in other projects. Likewise with good ideas introduced in one project will often be picked up by other projects. Further because of a diverse system of libraries it is more likely that good ideas can be experimented with safely in different projects.
Apk hits opensores idiots with truth and all they have is downmods to hide it as usual? Yes.
Apk hits guillible slashtards with best trolls & the laughter NEVER ENDS? Yes... apk
Maw! Fire up the karma burner!
From the perspective of most IT customers, bugs are bugs regardless of closed or open source. They still rely on other people to find them, patch them and release changes.
Companies who rely on open source libraries may or may not have the ability or spare resources to go digging through the code of a library, finding a security issue, writing a patch for it, recompiling the library, then using that patched copy in production. Companies in the 'service provider' realm may be able to do this, simply because they are staffed appropriately and have a greater IT focus. I do IT work for airline customers. Airlines want as little to do with IT as possible, even though it's a key part of their business...it's not directly related to the surprisingly low-margin business of moving people and planes. I would never advise a customer to roll their own Linux distribution, for example, even if it was based on a commercial one. There's just no appetite for keeping things maintained in a business who doesn't live and breathe technology.
The problem is that, increasingly, even closed source vendors are relying on open source libraries to provide large blocks of their application's functionality. A company who doesn't write operating systems generally shouldn't try rewriting these very important pieces, of course, but the closed source companies providing applications that use open source libraries need to be on top of these issues and ideally contribute back their patches.
Whether closed or open source, companies need to be able to respond quickly to security problems, and those problems may end up getting traced back to something like OpenSSL, the Apache stack, etc. Open source has the advantage of "more eyes" looking at the code for vulnerabilities, and less commercial pressure. Closed source companies have the opportunity to provide (usually at a cost) the expertise and support necessary to find and fix a customer problem. I've had both awful and good experiences with both trying to get bugs resolved. If you pay for it, and the closed source vendor has good support, they will move heaven and earth to fix your problem. For non-technology companies, closed source or support-funded open source companies like Red Hat give internal IT teams a good boundary between them and "the vendor" as well as someone to call when they have done their homework and find they can't fix something. For the Googles, Facebooks and maybe some academic institutions, the internal IT department can be staffed with kernel hackers and the like to maintain their own highly-optimized implementations. Techies tend to forget that users and companies have very little desire to mess around with technology, and use it to get their work done.
So there were a few high-profile security flaws found in important open source software recently. So what? People are talking almost as though this somehow proved that open source is not superior or maybe even inferior to closed source software.
It isn't like there has never been a high-profile security problem in important closed source software. Nor is it likely there will not be others in the future.
Here is an awfully safe prediction... in the future there will be more high-profile security bugs found in open source software AND in closed source software too.
Certainly the age of the code that caused these bugs is reason for concern. Hopefully lessons are being learned and improvements being made. But to even try to make a comparison between open and closed source software regarding security? Good luck with that.
How can you possibly count the number of zero day exploits in either? By definition you don't know that they are there! At least with open source if you really care you can do something about it.
Sadly we humans only seem to be able to handle 2 or 3 options. If 12 existed we'd hone in on 3 favorites and 9 would be outliers.
It's not that just "being open source" automatically means code is being validated by lots of eyes. It means that you can look at the code. All we need is more people interested in doing that, or paid to do so. They also need to have the knowledge/skill necessary to do that.
And as always, being closed source would not have made the issues easier to find. And then you'd be at their mercy waiting for a fix. These were all found and all fixed relatively quickly, so let's focus on that.
SSL certainly isn't a simple library. Increased complexity makes it easier to make a mistake and harder to find it.
I refuse to sign
it would be better to have a broad array of choices. With a dozen packages on the market, that might mean 11 times out of 12 the bad guys wouldn't exploit our site
1 Staffing and maintaining a single project is no small feat in itself.
2 The smaller the piece of the puzzle that you are trying to replace, the more likely you will be driven towards the same solution.
3 Does even the IT pro have the time and resources to research and test a dozen choices for each of the one hundred, three hundred, or more third party libraries they may need?
Preach it brother! The whole world should be using BSD!
What is wrong with security through obscurity?
OpenSSL, Netscape NSS, GnuTLS, as well as various proprietary SSL implementations have all had serious bugs over the last few years. Some of the bugs affected multiple unrelated code bases.
How much diversity do you want? How did the diversity help?
Finally! A year of moderation! Ready for 2019?
What is up with this article? What about closed-sourced apps like ISS or windows, with tons and tons of vulnerabilities found (and some fixed) every week? Because there have been a very small handful in some high-profile open-source projects means open source doesn't work?
That's the stupidest thing I've ever heard. If anything, because those bugs were found and fixed shows that open source DOES work. If they were closed products, those bugs may likely still exist and No Such Agency may likely still be exploiting them. Not to mention all the back-doors they force into closed-source software, which is harder to do with open source in the first place.
The point is, for something to be secure you have to be able to audit it. In the open source world, you can do this. In the closed source world, you have 0 ability to confirm that something is secure, you are just taking a salesperson's word for it. THAT is lack of security awareness.
First off, let's be clear - I'm not arguing against alternatives, there are many good reasons to have them. But when the single major widely-used library is already "under-funded", starting a dozen more similar projects all competing for basically the same developer base is unlikely to improve things.
As for attracting OSS developers, I'm unconvinced. Sure, for "sexy" projects many will prefer a smaller project where their contributions are likely to be more appreciated. On the other hand, for a utility library only ever seen by a tiny percentage of developers, especially one designed to be a drop-in replacement for competitors, that appeal is likely going to be overshadowed by the fact that they're working on "just another implementation of X"
And perhaps more to the point, those motivations are primarily relevant to *volunteer* developers. But as I understand it for a big, high-visibility project like Linux the majority of code contribution now comes from developers working in the employ of major downstream users. No reason at all they shouldn't be paid to spend a bit more time on high-stakes things like security.
As for the resources needed - I suspect there are plenty of developers per se already working on the projects - major bugs are after all typically fixed within weeks. What's really needed is better auditing. Which yes, does call for a skillset with considerable overlap with developers, but is not really the same thing.
And I hear you on the cross-pollination - the point though is that when problem X is discovered in codebase Y, you now also need need enough auditor man-hours to also analyze codebases A,B, C, D, E, and F for similar problems. And if you want the libraries to be drop-in replacements for each other then god forbid you should add a feature or fix a bug that requires an interface update. Assuming the internal architecture is at least moderately different in all the implementations it may not even be possible to change the interface in a way that doesn't require a major rework of one or more implementing projects. Even if it is you're going to be looking at a lot of duplication of effort for any changes.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Wrong, those devices are connected to the internet where open source rules.
I'm older than IBM mainframes, boy. You have not been in the field longer than me.
>We also know that the answer isn't in rolling your own security. Very few people or organizations are likely to be able to securely implement their own version of TLS.
TLS is the issue. It isn't simple. It isn't even secure in many compliant configurations. It invites implementation errors.
A good spec of a secure protocol would make secure implementations easy. If you don't think about the implementability while you're writing a spec, you're doomed, like TLS is.
"Don't roll your own security" is advice aimed at people who don't know about security. Some of us have to implement and 'roll' the specs. The world looks different when your reputation is tied to your stuff not get broken before senility sets in. You can do it right, but you need all the elements in place including a well thought out spec.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Microsoft, Google, RedHat, Yahoo, HP, Dell, Apache, Wikimedia, Mozilla, FSF, Apple, Intel, AMD, nVidia, Bungiesoft, and others each contributed their own versions of openSSL; each written in their own choice of language, using their own code, and building their own implementations of everything from the crypto through the command line interpreter logic.
...and then, due to the nature of software today, you wind up with all of these in your organization, and now if any of them are compromised you have a problem. I'd rather engineers from all of those organizations worked on OpenSSL (or whatever) to make it as secure as possible, perhaps forking it occasionally to solve some particular problem and then merging the code later.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I think reuse is far more secure than multiple options. In the long run. Reuse will find more bugs and make it more aware. Reuse will have a much larger impact, but that just ups the priority to get it fixed. Multiple options will only decrease the impact but will open up for duplicate bugs, finding less of them, more entropy for fragmentation, and less priority & longer time for getting them fixed. Multiple options will be less secure... you just won't think it is.
I have never been a believer open source code is automatically more secure. Different projects have different code quality. Depends on if/how they are managed and who all is willing to step up contribute their time and effort.
There have been some advantages unique to open source projects such as static analysis vendors developing, testing and marketing their wares blessing a huge swatch of open source land with the fruits of their labor as well as the ability for savvy users to evaluate willingness to use software based on observation of code quality which can be difficult to discern from commercial software.
Yet for the most part for most of us mortals the end result is simply a function of who is willing to step up and contribute what.
I agree that more diversity in the software ecosystem will cause critical bugs to have less impact to the world overall, and will hopefully drive competition to make the offerings more efficient and stable. However I think that this is a straw-man and the real conclusion we should draw is this:
When you write code, you are going to screw up. If you aren't writing bugs that people notice, you aren't working on anything worthwhile. While the bugs that were found were costly and dangerous, the question is were these found quicker than a closed source solution? Were they fixed faster than a closed source solution? Is there anything that can be done to allow quicker roll back or disabling of vulnerable features? When you write code, you need to design for failure, because it will happen and plan so that the recovery will be as quick as possible.
Adding additional software library offerings will only add stability in the sense that one particular vector wont affect as much of the Internet, but you introduce more surface area for attackers to poke at, and more vulnerabilities overall. Given the challenges to write really solid code, I think I'd like to have fewer, but really well vetted open source software solutions. Of course, I am not correct in this opinion, as there are no 'right' decisions here.
HA! I just wasted some of your bandwidth with a frivolous sig!
No, you should feel contrite that you are daring to report a bug in software that is obviously perfect. There are two classes of software error: hardware error, and user error. In the first case, you shouldn't have bought that in the first place, so it reduces to the second case. Our QA process will take advantage of this breakthrough, but the documentation will not be updated.
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
Very few people or organizations are likely to be able to securely implement their own version of TLS.
Security and Complexity are enemies. Call me paranoid, but given recent revelations, I suspect TLS was purposefully made complex--so that any implementation was likely to have bugs that could be found and exploited.
Secure communication shouldn't be, and doesn't have to be, so mind-bendingly complex. It should be relatively easy to implement secure communication libraries. It should be fall-off-a-log easy to use said libraries, so that software developers can get client/client apps, client/server apps, and even server/server apps communicating over a secure channel without needing 20 years of security experience first. The code examples showing how it's done should fit on a single printed page.
Until the (purposeful?) complexity is ejected, secure communication will continue to be a fantasy.
TLS is the issue. It isn't simple. It isn't even secure in many compliant configurations. It invites implementation errors.
A good spec of a secure protocol would make secure implementations easy. If you don't think about the implementability while you're writing a spec, you're doomed, like TLS is.
Well said! You deserve +5, Insightful. Get on it, mods!
Security researchers have known about vulnerabilities in third-party components for years. Anytime you increase the attack surface of an application through the use of third-party components (commercial or open source), you're potentially introducing vulnerabilities that you didn't create. A formal study was conducted by Aspect Security in 2012. https://www.aspectsecurity.com... which illustrates how big of a problem this actually is. Up until this time, the security community always knew it was a problem, but didn't have much stats to back up their claims. This research (as well as other data points) was essential for OWASP to introduce a new category in the OWASP Top Ten 2013 - A9: Using Components with Known Vulnerabilities. 2014 was not "the year we learned how vulnerable third party code libraries are". It was the year that organizations which had no security best practices in place, paid a much higher price than organizations that did.
Computer Science is still a newbie discipline. Much more relevantly, the problems introduced by the sudden social change of what a network is are a pretty big deal.
Here's how you know it's crazy: look at the hacker hysteria, and how it has barely gotten any better. The vast majority of "hackers" who cracked stuff back in the day were treated entirely ludicrously, like some kind of wizard. Everyone here probably remembers indefinite detention and ludicrous punishments such as "can't use a computer", which would be absolutely unthinkable for even a bank robber who had served his time.
If you piped your water supply through every enemy state in the world, you would probably want to inspect it before handing it out as drinkable. But, if you did not do that inspection, would you complain about the pipe manufacturers, for not making a pipe no one could interact with? Like, "why isn't this pipe adamantium"? And would you ignore all the enemy nations and go throw in jail the guy who put green food coloring in to show that an actual bad guy could have done something much worse?
The other big thing is how fast expectations change. Every few years someone has rigged up a specialized framework that solves some set of "needed for profit" set of network issues, and then the advantages of that force migration towards it. While in theory each of these individual solutions could be highly secure, the fact that they are new features hurts that a whole lot.
As people decide on a feature set that they actually need for certain purposes, and finally discard the idea that something is bad because it is old, we will start to see really solid code that is trusted. In MANY places, we already HAVE this.
More importantly, in disciplines whose lengths of existence rounds to millenia instead of decades (network security) or a century (computer science), you have things that "everyone knows", and those things have been true for generations. Meanwhile, in computer science, you see holy wars wrapped in holy wars, and a lot of it is due to communication issues.
When everybody has the same goal, as is pretty much the case for usability issues, the shallowness of bugs posited by the many eyes hypothesis would be a good thing. When it comes to security issues, it sets up a race between the white hats and the black hats, and there is more incentive for the black hats (collectively, the rest of us have as much incentive as do the black hats, but that is not the case individually - for one thing, an attacker satisfies his goal by finding just one vulnerability.)
Your manner of writing and your choice of idioms and colloquialisms reveal you to be about half my age; those from my era have a different "look and feel" as it were. Refine your abilities as a poseur, so they will shine in the darkness like a luminescent swamp gas.
Which Linux user actually got hacked by a library vulnerability this year? Speak up now. Oh, hmm, the sound of silence. Certainly not me, and not anyone I know of.
The thing is, sometimes the many eyes just aren't pointed in the right direction. A publicly disclosed vulnerability changes that instantly, hundreds or thousands of expert eyes to got work, fixes happen fast, and the community learns from the incident, often resulting in the eradication of a whole class of risks.
When all you have is a hammer, every problem starts to look like a thumb.
Give us a name and some links so we can check your assertions.
You do understand that we all think this AC and apk's AC are the same poster pretending to be supporting, right?
What are the number of developers who worked on OpenSSL?
Do provide links to your identity, so we may marvel at your accomplishments and technical acumen.
Life is complex too and it is good so. It is also this complexity that developed as a response to viruses and bacteria. It is probably unavoidable. Connection to interwebs means you are connected to all hackers of the world at once. Using common software means that they had eternity to find weak spots. The cheap and good enough protection that nature had to this problem was complexity and dynamic adaptation to agents of destruction. Theoretically we could develop those things well enough if we tried hard enough but bean counters and our own laziness being forces of nature prevented such positive development.
One difference is that if you use openssl and someone finds a huge bug then it gets fixed. If you've got the proprietary library and it has bugs you will never be told about them and if there are patches you'll have to wait many months to get them (or worse they'll require you to pay to buy an upgrade, you won't ever be able to backport fixes). So yes you may have a dozen solutions, but only 1 out of 12 probably lets you learn about severe vulnerabilities in a timely manner while also letting you supply your own fix. Maybe 3 out of 12 let your in house expert examine the code. Most won't give you free critical patches and definitely won't provide patches for older versions. We have the variety of solutions already however what we need is a variety of open source solutions.
Cool story bro.
Mod me down, my New Earth Global Warmingist friends!
I'm sorry, one or both of us (depending on how that error is scored) has fallen victim to Poe's Law. If high-paying jobs are a result of egotism I may have to try it some day. For the present I suppose I'll have to send off for another batch of <sarcasm> tags.
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
The only thing you have blown is any shred of credibility
2014 was the year we learned that the Internet is insecure. Not a library, not a router, not a hacker, the whole Internet is insecure. There are British security experts building it up, and Japanese security experts tearing it down. Putting nude pictures of yourself on any cloud site is just plain stupid. GIving your credit card number at any prompt is just asking for hacking. The NSA reads your e-mail, and if they didn't the KGB would. I can encrypt my e-mail, but very few people have keys, and what back doors are built in to my encryption software?
If I have to send someone a user name and password, I send the user name via e-mail and the password via SMS. It is unlikely that anyone has hacked both.
Face it: the Internet is not secure.
hang on those dozen packages might still be reliant on the same broken library.
Go well
Which Linux user actually got hacked by a library vulnerability this year?
Strange how this device creeps up now and then in unexpected contexts.
Well I can't think of one... so that must mean nobody? ...... Right? No harm in drawing conclusions as my experience is a good enough proxy for the remainder of the world.
The thing is, sometimes the many eyes just aren't pointed in the right direction. A publicly disclosed vulnerability changes that instantly, hundreds or thousands of expert eyes to got work, fixes happen fast, and the community learns from the incident, often resulting in the eradication of a whole class of risks.
All of these new eyeballs must have forgotten to update the OpenSSL change log with their contributions.
The obvious solution is formally verified code. The airline industry can produce it, so it's not outrageously difficult to do. It is expensive, but so is patching SSL after getting hacked every year or so.
This wouldn't be the same industry busy rolling out untrusted "NextGen" navigation and communications standards?
Pretty much this. Open source works, but only when you can actually get eyes looking at the code. If you incorporate mission-critical software that works good enough already, you're not likley to be motivated to get involved with the project. The BSD's are sort of a cathederal project, but looking at all the parts systematically is usefull to see problem areas before they blow up in your face.
The heartbleed incident does not disprove that 'given enough eyeballs all bugs are shallow'. Instead, it proves the importance of Open Source software. It also illustrates the disadvantage of not having an enormous marketing machine that can spin such incidents. Instead of calling this bug 'catastrophic', we should have called this 'an opportunity to further improve server security'...
grow up !
So now that someone has identified ugliness in the Bash code, is an effort being made to clean things up?
*sigh* back to work...
SSL/TLS is so massively complex I have serious doubts it can be made bug-free. Do we REALLY need this concept ? Cant we just use much more simple symmetric ciphers ? My feeling is the IT industry has been conceptually pwned. We are already very deep in a rabbit hole and its name is "SSL/TLS".
"Don't roll your own security" is advice aimed at people who don't know about security. Some of us have to implement and 'roll' the specs. The world looks different when your reputation is tied to your stuff not get broken before senility sets in. You can do it right, but you need all the elements in place including a well thought out spec.
A good start is to have some sort of test suite. When implementing a spec, TDD is very much the way to go. You should also try to make sure you've got tests for all the failure modes that you expect (including all the ones in the spec). Yes, that can be devilishly hard. Do it anyway.
"Little does he know, but there is no 'I' in 'Idiot'!"
Wake me up when you have discovered a different free enterprise system.
Whenever I hear "metric", I know it is MBA bullshit. Long known as Beancounting. "you can only manage the beans you can count" and similar mantras. Let me pose a little question: How do you "measure" the number of bugs not yet discovered ?? Stop worshipping to pseudo-science from the social engineers.
We could technically have simple, Enigma-style cipher machines in every household. But that would threaten the power base of the military so this will never fly. Their buddies in Saudi-Arabia will make sure.
Because the closed source shops prefer not to discuss these issues. And have you've seen our new glossy product folder, our lowpaid code monkeys^H^H^H^H^H^H^H^H^H^H^H^Hsuperb software development gurus don't make mistakes. No sorry, for whatever reason the legal department does not allows us to give you any warranty on our software.
The security of the open source model isn't really the problem or the answer here. The problem is homogeneity. A million different sites and applications rely on just a few libraries, so that when a bug hits one, it has massive impact on the entire internet.
We also know that the answer isn't in rolling your own security. Very few people or organizations are likely to be able to securely implement their own version of TLS. Even the best packages of today didn't start out perfect, they had to iterate through several flaws to get to where they are today.
So perhaps the better answer is in having more packages to choose from? Instead of picking just openssl by default, it would be better to have a broad array of choices. With a dozen packages on the market, that might mean 11 times out of 12 the bad guys wouldn't exploit our site. If the packages are interchangeable, we'd be better positioned to switch them quickly in case of emergency.
Today, disk space is very cheap. Memory is very cheap, and I think nothing of having 32gigs of ram. My point-- do away with dynamic linking for your application. Do static linking, except possibly for display libraries. If a flaw is found, its going to require many recompiles, but that is offset by the non-reliance of multiple dynamically linked libraries. As was mentioned, get a flaw or security issue with that library, or create a "man in the middle" attack with one dynamically linked library, and voila, your security is compromised. With static linking, your application is more secure and is known to work with more versions of the operating systems
Leslie Satenstein Montreal Quebec Canada
I look at it as a methodology to spread the risk.
We've had a few packages dominate the landscape, and each of them has had some of the best and the brightest people looking at it, reviewing it, analyzing it, looking for flaws, running code analysis, fuzzers, everything. We've done exactly what you've said: we dedicated resources to develop a single (or few) libraries. Yet they still have flaws.
I don't believe the perfection-alone-model works, because there is no evidence that it does. So far we have evidence that every commercial-grade protocol and implementation has had some kind of security flaw. Therefore we need to stop believing that we can engineer our way out of the situation, because we haven't. We need a completely different and complementary approach. We need to better manage the risk of failure.
To me it doesn't matter why someone would choose a particular library over another, only that we don't all put our eggs in the one basket. The evidence suggests they're all going to fail at some point; it's only a matter of when.
John
Then why are their so many more mission critical program ending bugs in FOSS software then closed source?
Or 11 more sets of programmers to go over the existing code.
The shallowness issue isn't to do with the number of eyes using the code, it's the number of eyes looking at the internals.
The vast majority of "legacy code" has _never_ been audited. Everyone assumes "Someone else already did this. It's safe"
I've had that exact argument raised by managers (many of whom are computing greybeards who should know better) as reasons for sticking with legacy code instead of moving to newer packages. The stupid thing is that they continue to raise this argument and be proven wrong (the glaring X11 bugs being a classic case - they fell out within minutes of someone going "I wonder if?" and hitting the source with a basic static analyser)
The opensource code base is enormous but even a couple of small projects systematically looking for the low hanging fruit would be better than status quo. You can pretty much guarantee that blackhats are already doing this but they have no interest in publicising the results.
There's also a strange mentality at work.
Many years ago, as a DNS admin I discovered that BIND interprets IP addresses in the configuration files with leading 0s as octal.
This is an explicit violation of the RFC (which states that IP addresses are dotted decimals) and as such I posted about it on Bugtraq
Instead of it being fixed, there was a flamewar. Several people (including Bind's author, who was also the RFC author) pointed out that 0xNNN also works and claimed that "it's supposed to work this way".
When I pointed out the RFC paragraph and stated that either the RFC or the code needed to be altered so that everything was consistent, the response was a flamefest.
Not long after that, spammers and others started posting URLS of long decimals, binary, octal and various other formats.
That flaw is STILL in bind, and STILL catching out DNS admins who try 0-padding their config files for readability - and the RFC has never been altered.