Slashdot Mirror
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?
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.
The problem is that we aren't using safe-by-design programming languages like Rust enough. If we used Rust more, then many types of bugs and security flaws wouldn't even be possible. As more and more software developers follow Mozilla's lead and start to use Rust to build their software systems, we will see many common types of security flaws vanish.
Good security usually means re-architecting whatever legacy garbage fire has been burning in off in the corner for the last 12 years and that costs money. The insecure software is still generating revenue in it's current state and there are no consequences for poor software security. #Equafax
How are bugs still possible? That's how security holes are still possible too.
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.
>> 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.
The root is that our corporate laws allow liability (for defective products, in this case) to be completely separated from ownership (stockholders). US companies can fuck customers up the ass with barbed wire, and nothing happens to anybody within the company management or ownership as a result.
I don't respond to AC's.
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.
Mimetics Inc. Twitter
How Are So Many Security Vulnerabilities Possible?
Do you life in a house or apartment? Go around and look very closely at every aspect of the structure. As you go, make note every flaw you find, however tiny, but paying special attention to things that could be avenues for entering the dwelling from the outside even if everything is locked up. Now imagine 1,000,000 people all working constantly to find ways through those vulnerabilities without you realizing that is going on. Now imagine everybody in your city has an identical dwelling so that when one avenue is compromised, they all are.
That is how.
Companies do not care about security, because they see no value in it. They rush their own developers to release software, and never ask them to focus on security.
Developers do not care about security. They never face the consequence of their negligence on it
Consumers do not care about security. They shop for the cheaper or the most hyped product, not for the one that was correctly engineered. How could they know it really was, anyway?
Please, before you post on Slashdot about code vulnerabilities, make sure you have at least programmed a "Hello, World" before. This post reminds me of the time a frustrated boss demanded to know why the game AI I was programming didn't "just use common sense."
More vulnerabilities are happening because there is a *massive* increase in software in consumer products. A bazillion products now have codebases that didn't before - ovens, toys, even my damn Christmas tree. Combine that with professional and social media that's always looking to dredge up outrage, and an increase in bad actors who realize that public outrage can work in their favor, and boom! You have a constant stream of stories about security holes. Why is that hard to understand?
Engineers are increasingly educated about new security threats - we evolve much faster in dealing with new challenges than almost any other type of worker. But yes, things get through, because this shit is hard - much harder than clueless internet whining. Also, because we're on the front lines of two wars - against those who tear down what others build, and against those who squelch innovation to preserve their own fat-cat positions - that is exponentially more intense than it was even a few years ago.
Expect the future to get *much* bumpier than this.
Almost all security problems boil down to the absolute lack of support for the principle of least privilege. None of the commonly used systems have anything approaching this concept. The crude approximation available is to put each resource in a virtual machine and tightly limit its connections to other virtual machines that need to access it for a specific resource... then watch those like a hawk for traffic spikes etc.
The other thing that could help immensely is to install Data Diodes, which are gateways specifically designed to NEVER let data flow in the non-desired direction, guaranteed by physics. The come in pairs, they have a normal network connection on one side, and one of the pair can only transmit, the other can only receive, usually via a single fiber.
This stuff can be fixed, I've been saying so for at least a decade now (go ahead, search my comment history here and elsewhere)... ya'll are slow on the uptake. I figure another 5 years before it starts sinking in, and at least 10 more to get it done.
I agree that better programming languages with safety features would make a huge difference, if someone can make one that is easy to understand by average or below-average programmers, who write a lot of the software out there. Rust is quite safe, but has a lot of really weird-ass new concepts that many programmers can't be bothered to try to grok. Go is half-decent, but also a moderately weird and finicky programming language.
Safer web-app templating and db access libraries would also help a lot.
Company management wise enough to allow time for up-fron security reviews, tests, and fixes would also help alot. In contrast, most software projects are inherently behind on unrealistic-from-the-get-go schedules.
Where are we going and why are we in a handbasket?
Security is not free. It is neither free in that it requires lots of man hours of time to develop & code, and that security has no impact on the user experience.
You can do end to end encryption of all traffic, encrypt at all states, require multi-factor auth, require physical devices, require secure portal software. But all of these have operational costs as well. But in the cost of compute and in the usability of the software.
If you had to access gmail through a specific secure application, with 3+ factor authentication, and it was really really slow, would you use it?
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.
Security is also "unfair". You, as a conscientious developer, can do everything "right", and get totally pwn3d *anyway* because of some widespread, system/platform/framework/library vulnerability (perfect example: Heartbleed).
The only way to improve the odds is for a development team to have one or more members whose ONLY job is to be aware of every thirdparty library/platform/os used by the project & literally research every single one, every single day, to become aware of vulnerabilities as they're discovered... and for projects not under active development, maintain a working build environment at all times so *somebody* will be able to rapidly build updates to the app.
You can't expect developers to do it. We don't have time to recursively scrutinize our projects' thirdparty dependencies on a daily basis... at least, not if we need to actually get any *new* development done.
I'm not kidding about the build environment problem. I have a couple of published Android apps (developed with older versions of Android Studio) that get hopelessly mangled by recent versions of Android Studio. Google has done a *remarkably* shit job of breaking old projects with no working migration path beyond, "spend several days creating a new project from scratch & manually re-create the old project in the new release of Android Studio". I've heard similar tales of woe about Visual Studio... if you're *lucky*, an old project *might* load successfully into the *next* release of VS, but if you let your old project go *too* long, it's not likely to even be importable by future releases of VS without getting mangled into oblivion. And Visual Studio sinks its teeth *so* deeply into Windows, it's hard to keep old versions of VS around (and working) in perpetuity (without having mothballed old computers with it installed), and even harder to re-create those old installations years down the road.
Back in the happy days of Netbeans, Java, and Ant, you could generally build any old Netbeans project from the commandline using its generated Ant script, even IF a newer release of Netbeans broke it. With non-Gradle Android Studio 1.x projects... good luck... but you're probably fucked. StackOverflow has THOUSANDS of questions about "how to salvage old Android projects last built with now-obsolete IDEs (Eclipse, AS1.x, etc)".
Most programmers think code can be made secure if they only have better compilers, debuggers, or follow better practices. They are fundamentally mistaken about the nature of the problem.
This article lays out the nature of the error far better than I can. Please read it and then THINK:
https://medium.com/message/eve...
And then consider: âoeIt is difficult to get a man to understand something when his salary depends on his not understanding it.ââSâ"âSUpton Sinclair
I know quite a few CEOs and VP level execs. They are very focused on revenue. They are spending all their time trying to land new customers and grow the business. Security is a cost: generally: you have to pay money for it, either to security vendors or in headcount, and there is no corresponding revenue that you get. So it goes to the bottom of the priority list. Somewhere in their heads they know that deferring it is a bad idea, and the cost of a security breach is something they don't even want to think about, but there is always a new revenue target to hit, another customer to land, etc., and so the security stuff get put in the "maybe later" pile.
"Does it compile? Then it ships!" per-quarter profit margins demand it!
Companies do not care about security, because they see no value in it. They rush their own developers to release software, and never ask them to focus on security.
It's not that they don't care about security (although they often don't). It's because, in the competitive environment, the "invisible hand" separates the companies into "The Quick" (pun intended) and "The Dead".
For each new computer-based market opportunity there are typically far more companies trying to get to product than there are niches for them. The first one, two, or three will get through the "window of oppotunity" and take the market, and the rest will be left out when the window closes - perhaps to die, perhaps to move on to some other opportunity, rinse, and repeat.
To get through the window before it closes, development has to be fast. Something has to give, and practically EVERYTHING that gives makes security holes. So the Pointy Haired Bosses tell the workers to get the product to market and THEN worry about fixing the security holes.
Some of the developers make things secure anyhow. Most of them find the window closed when they're ready to ship, because the ones that did what management told them already got to market with the features working and the infrastructure made of swiss cheese. They took the whole market - before the bad guys discovered the holes, exploited them, and the media finally noticed.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Because security is a cost center while new features are a revenue center. The executives who ultimately decide priorities, budgets and schedules are taught to minimize costs while maximizing revenue. The results are, obviously, highly predictable if supremely disappointing.
Another thing to think about to understand it is that for thousands of years, people tried to make secure locks; every time locksmiths figured out how to open them - pretty easily. Security is very hard. Offline, it's okay that Pop-A-Lock can open your lock for $20. That's the accepted level of security.
Online, people thousands of miles away can use computers to try to crack the security on tens of thousands of victims, while the attacker is sleeping. They don't need to be skilled attackers, they just get hacking tools (software) from the relatively few people who are skilled. Popular web sites can be attacked a thousand times per day or more. Not even Chuck Norris can fight off a thousand attackers every day and never lose. On the WEB security is very hard. You MUST have layers of security, because somebody will break through the first layer, and the must have well-disciplined operational security.
* Medeco has finally done a reasonably good job of making physical locks that are hard for a locksmith to open. Not impossible, but hard. Breaking a window is still as easy as ever, though.
Instead you rely upon languages to handle the safety and optimizations your lazy ass couldn't be bothered learning in the first place.
And you wonder why someone else guts your shit - they understand the basics which you failed to learn.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
Nope. Sorry, but nope. If that was the case, the OWASP Top 10 wouldn't exist, a collection of 10 commonly made and reliably existing flaws in any piece of online application.
Anyone trying to get in would just have to try that top 10 and reliably get in. It's already bad enough with standard libs that are hardened against exactly those common problems, with everyone reinventing the wheel, we could get into any place with the standard toolbox.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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).
I would assert that it is a 99/1 ratio. Security is a solvable problem, and we have had rigorous, solid, time-tested methods of security since the 1960s and 1970s, be it physical security, network security, or security of a computer.
I did an "Ask Slashdot" about a similar topic a few weeks ago, but it was more inclined to why companies have no interest in security, because (to them) security has no returns.
The problem is that we already know how to do segmented operating systems, windowing systems that have varying levels of security, application security, solid encryption with good key management, secure tunnels. All mainstream x86-64 and ARM CPUs come with AES in hardware and a hardware RNG (even if you have to run it through Yarrow like FreeBSD does, just in case.) The issue is that developers cut corners. Why use a 4096 bit key, where big-O for this is O(n^3) when you can use 64, 64 bit keys for a fraction of the CPU? Why use all 14 rounds for AES-256 when you can use just one? Why use a salting/hashing mechanism when you can just store the password as plaintext? Who will notice? Who will care?
Then we get to more fundamental things. Why should developers care about security at all? If they don't make their deliverables for sake of security, they get admonished for it in public at the daily stand-ups, if not eventually fired. If their code causes people to sue the company, then the lawyers are the ones handling that... not the devs. Even if there are consequences, they are less than not making the sprints.
Then, we get to the bottom line: There is profit to be had by insecurity. If a CEO finds out their company got hacked, they can short their stock, wait a few months, announce it, and profit tidily. Insider trading laws are easily skirted around, especially if there is a few months delay between the transaction and the announcement.
To;dr, security is not a matter of "can't". It is a matter of "won't".
As you know, CGI programs run on the server. To do something in the *browser*, you had to use Java, or maybe Flash.
> And the Applet never caught on for too long.
Only for five years or so, but long enough to achieve critical mass since it was the only real option. ActiveX (formerly known as COM, formerly known as OLE) was very much not designed for the browser in the first place, and only worked (kinda) in IE, so it wasn't a real option for internet sites. It was used a bit for intranet.
Insurance is something that pays to cover risks, things that probably won't happen to you this year, and the expense would be more than the customer afford to cover out of their own pocket.
For example, home insurance will replace your house if it burns to the ground. You buy insurance because you couldn't afford to buy a new house out of your own pocket. You don't insure against needing to replace a toilet paper holder, or paint the walls, or weed the garden. These are ordinary, expected expenses that you just pay.
Car insurance will replace your car if it gets totaled. The average driver doesn't expect for their car to get totaled, and can't afford to pay for a new one with their own cash. Car insurance does NOT cover gas, oil, tires, spark plugs - ordinary, expected expenses.
Modern US health care plans get involved in every little $30-$60 doctor visit, and all the bureaucracy and red tape doubles the total cost of simple things like a checkup or vaccine. That's NOT insurance. Insurance is for unexpected events that you can't cover from your own bank account. An annual check-up, or flu vaccine, is both expected and affordable; it's not an insurable risk.
We used to be able to buy medical INSURANCE, coverage for *unexpected* events too costly to pay from your own checking account (ie major surgery or catastrophic illness). That was fairly affordable. For the ordinary, expected health care expenses you kept a few dollars in the bank, and later in a specific bank account called a Health Savings Account. Over the years various things have forced more and more crap to be covered by "health care plans" - you can't just buy medical INSURANCE anymore. That's added a lot of paperwork expense to what used to be a $25 visit for a sinus infection. Now you have $25 worth of doctor time and $30 spent on paperwork with the healthcare plan and government, so it costs $55.