Ask Slashdot: How Are So Many Security Vulnerabilities Possible?

dryriver writes: It seems like not a day goes by on Slashdot and elsewhere on the intertubes that you don't read a story headline reading "Company_Name Product_Name Has Critical Vulnerability That Allows Hackers To Description_Of_Bad_Things_Vulnerability_Allows_To_Happen." A lot of it is big brand products as well. How, in the 21st century, is this possible, and with such frequency? Is software running on electronic hardware invariably open to hacking if someone just tries long and hard enough? Or are the product manufacturers simply careless or cutting corners in their product designs? If you create something that communicates with other things electronically, is there no way at all to ensure that the device is practically unhackable?

Comments

10/90

[rudy_wayne]

Is software running on electronic hardware invariably open to hacking if someone just tries long and hard enough?

This is 10% of the problem

Or are the product manufacturers simply careless or cutting corners in their product designs?

This is 90% of the problem.

Agile development

[Anonymous Coward]

Who cares, we have arbitrary deadlines to meet. Ship it broken! We can fix it later.

Re:We aren't using Rust enough.

[Narcocide]

Just in case the uninitiated might confuse this for a serious statement; to be clear he's completely trolling.

Git-r-done

[Snotnose]

Security issues? Um, have you met the requirements? Yeah? Does it work? Yeah? The security issues aren't in the spec, release it.

The good news is much like Charlie Rose gets embarrassed off the national stage, hopefully companies that don't take security seriously will be forced into bankruptcy.

Yes.

[xxxJonBoyxxx]

>> are the product manufacturers simply careless or cutting corners in their product designs?

Yes.

I've been a software security guru for more than ten years, and none of the companies I worked for, whether Fortune 100 or commercial companies shipping commercial software, fixed all the vulnerabilities we found before shipping. (Some set the bar at "high" and some as "critical", but no one halted the presses for "medium".) For all I know, most of the vulnerabilities we found perished on a disbanded team's backlog years ago to the delight of hackers everywhere.

But the bigger problem would be the code that shipped that we never saw, whether it was an intern's "hackathon" project shat onto the web, something that crawled out of a pool of H1Bs, or a third-party app grafted in to fake reporting enough to get past the demo with the big client. I have more horror stories than I can relate involving things like this.

And 90% of the 90% are the biggest boys

[mykepredko]

That can be simply listed as (in the order that I see them):
- Microsoft as an OS vendor (I know I'll get attacks from various ACs that think any criticism of MS is unfair but they are putting 'way more energy into sucking user's personal data into their servers than protecting said personal data)
- Large service companies with poor security for customer databases (I just saw Uber had a big hack last year that they've been trying to keep quiet).
- The 10% of so of the user population at large which don't have the intelligence to question email/text/phone/Facebook/etc. requests for their personal information.

The remaining 10% would be poorly defined standards (for example IoT) where the possible vectors and impact of security intrusions have not been thought through.

Re:And 90% of the 90% are the biggest boys

[Anonymous Coward]

Software is complex. Any non trivial piece of software probably contains a bunch of libraries that are themselves complex, and built on a best effort/time basis. At almost every stage there is the potential for abuse. Where a library appears to be secure in of itself, it may contribute to poor security when it is used in ways that are not anticipated.

Operating systems are complex. They themselves are made up of many components which are made up of many libraries, which themselves may be made up of many libraries. Security vulnerabilities may be anywhere in there, or emergent from the collective. Combining a relatively secure OS with a poorly written application which runs with user privileges may expose other issues.

Operating systems and programs often support old interfaces. That is not automatically bad, but it is yet more attack area you have to cover and eventually deprecate.

Operating systems and programs may be wrote in inherently less secure languages such as C/C++, and it may even be for good reasons, but buffer overruns may allow control of the program flow. Just get the overflow to get to your tailored jump instruction and your tailored data, which is really more cpu instructions, and now you have control.

People are stupid. People are lazy. Even smart people may not do an exhaustive search for vulnerabilities for everything they download, since well, the job needs doing, so they do the quick check and some additional reasonableness checks and move on with life. Still, clicking on what you should not is a bad thing. If you see a web page that just looks scary, power off your PC manually and don't reload your old tabs on startup. That will prevent some bad things, but not all.

Hackers exist, be it a nation state such as Russia or even the United States, or simple criminals. Some of them may even be working on obscure OSS libraries that other famous package use. I'd almost bet some vulnerabilities are deliberately introduced. I'd pretty much bet some work for Microsoft, likely from every major nation state in the world. It is hard to secure against unintentional backdoors, but even if they don't have them now, you can expect some deliberate backdoors in future updates. Hell, how do you know that phone update is of the good, and not some clandestine agency downloading a special edition?

Hardware exists with back doors, some intentional, some possibly not. Some of the management interfaces are scary as hell. Are you really sure no one is taking advantage of any of that? Silicon is usually not manufactured with say complete control of the process. Are you sure the gates AMD specified are the only gates in the CPU? (or Intel for that matter.)

COTS hardware may not get updated and even if it is, updates and such are likely a low priority. Have you plugged your smart TV in? Does it have a camera? A microphone? Do you really trust it? Is it in your bedroom? What about the gadget that monitors your kid? How an ooma really still be in business at that price? (I admit I have an ooma device.)

They don't know how to cost-effectively. Locksmith

[raymorris]

I think most companies don't know how to produce reasonably secure software cost-effectively. They aren't motivated enough to spend a ton of money on security. So they give up on trying all that hard, to varying degrees.

Some companies try educating programmers a bit about security. That's good, but not sufficient. Programmers are constantly learning new frameworks, new libraries, new languages, new systems they have to integrate with ... They aren't going to be security experts too.

In my experience, the main cost-effective way to improve security is to have a security professional consult with developers at three points in the process of a software project. Then integrate part of what's learned into automated parts of the DevOps build and release process. One hour from a security person at each of these three points can really make a difference, not only in the current project, but in future projects. Have the security person join a meeting and be part of the discussion at these three points:

The initial overall design / architecture
        This will allow the security professional to point out spots where security issues commonly occur, "be sure to use TLS (ssl) for this connection". It will also catch major architectural decisions that lead to big security problems that are very hard to fix later (such as an ISP planning on managing customer modems over their public IPs).

Finalizing the design details
    Similar to the above, but at a finer-grained level

Pre-release testing and approval
      Around the time you're starting integration testing, your security person can review the implementation based on notes they took in the two earlier stages. For some of these code-level things they can add to your existing pipeline, so from then on Git will warn you immediately when you try to commit code that follows a dangerous pattern such as use of std::process::Command with variables influenced by user input, or improper reuse of mutable buffers. (Here I use Rust terminology, the same errors can be made in most languages. Few bugs are langauge-specific).

Not only will this catch issues in the current project, but everybody learns from the interaction in order to avoid creating similar problems in the next project. Instead of studying 2,000 pages about security, the developers are being made aware of the specific issues that they tend to create in the specific domain the company is writing software for.

This process allows one security professional to effectively serve many programmers on many projects, much like your database expert might work with developers on many projects. You can get a lot of security improvement for not much money.

* Before somebody says "2,000 pages is ridiculous. Security is easy, all you need is the OWASP Top 10â, I'm a member of OWASP. I know very well the quick "rules of thumb" we publish. I've personally read over 10,000 pages about security and I don't know anywhere NEAR all that there is to know.

Re: We aren't using Rust enough.

[TechyImmigrant]

>It does mitigate certain families of security flaws.

Crypto types like Rust because it deals with a particular class of problem that is impossible to mitigate in C. Namely knowing what the compiler will do, for sure. Will it erase that buffer or will it optimize it away the erasure? In C there are a wealth of examples where code that compiles to secure object code on one compiler manage to get broken by another compiler. Or when the optimization level is changed. There is no "Best Practice" to make this problem go away using C. Rust specifically address this problem and while the other safety features are nice for mitigating security vulnerabilities, it is that specific problem that makes Rust appealing to the people who have looked under the compiler hood from a security standpoint.

Insurance would be great. That's how we got fire s

[raymorris]

The fire code is written by the National Fire Protection Association, a group formed by insurance companies, in order to reduce their losses from fires. Underwriters Laboratories (UL Listed) who check products for fire and electrical safety - same thing. "Underwriters" means insurance companies. Insurance companies are professionals at analyzing and reducing risk and they do a VERY good job of it. They use very advanced methods to determine risk. I'd LOVE to see insurance companies get involved in IT security, the same way they are involved in fire safety. Ever noticed car commercials advertising their high IIHS safety rating? IIHS is Insurance Institute for Highway Safety, insurance companies testing cars to make them safer.

> Insurance can pay out on the promises, and the insurers themselves are borrowing against still future promises to pay, which when they come due can be rolled over or hedged and thus the cycle continues ...

That's not how insurance works. The insurance company uses mathematical models to determine that of they insure 10,000 customers with a given risk profile, about 1% of those customers will have a claim. The average claim will be about $3,000, suppose. That's $300,000 the insurance company will have to pay out this year. Divided by the 10,000 customers, that's $30 per customer in claims. Each customer also costs $3 for mailing invoices and such, so the average cost per customer this year is $33. Therefore the premium they charge is $43. $10 gross profit per customer.

Insurance companies aren't betting hoping they don't have claims. They have a million customers, of course they'll have claims. With a million customers, the law of averages kicks in and they can predict rather accurately how much the total claims will be this year. So then they set the premiums (their prices) for the year a bit higher than their costs.

The one big thing that can screw that up is a major flood. A major flood could have a million people making claims all at once. That's why insurance companies don't sell flood insurance. Only the government sells flood insurance. (In the US at least).