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?
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.
>> 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.
Yes, the big issue here is that it's common knowledge consumers by and large refuse to be bothered to get educated and the bulk of the major software development companies out there aren't don't have leadership ethical enough to be able to resist taking maximum possible advantage of their naivety. Unfortunately this knowledge gap is also being turned against our own government even as our own government participates in using the very same knowledge gap on the general population. It's a huge ugly mess, really, and it says a lot about the spiritual deficiencies of humans as a whole, and I still completely in all seriousness blame Microsoft for starting it.
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 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.
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
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
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.
Succinctly put:
People think agile is about "Getting shit done!".
It turns out to be "Getting shit, done!"
Science advances one funeral at a time- Max Planck