Slashdot Mirror
The Cost of Crappy Security In Software Infrastructure
blackbearnh writes "Everyone these days knows that you have to double- and triple-check your code for security vulnerabilities, and make sure your servers are locked down as tight as you can. But why? Because our underlying operating systems, languages, and platforms do such a crappy job of protecting us from ourselves. The inevitable result of clamoring for new features, rather than demanding rock-solid infrastructure, is that the developer community wastes huge amounts of time protecting their applications from exploits that should never be possible in the first place. The next time you hear about a site that gets pwned by a buffer overrun exploit, don't think 'stupid developers!', think 'stupid industry!'"
Tools are dangerous. If I want to cut my hand off with a chainsaw, I can. If I want to leave my PHP script open to XSS, I can.
The next time you hear about a site that gets pwned by a buffer overrun exploit, don't think 'stupid developers!', think 'stupid industry!'"
Yeah, yeah. Hate the game, not the player, and all that. If you code a buffer overrun and you get pwned, it may mean the industry is stupid. But that doesn't mean that you're not stupid too.
Most web app exploits ARE the developers fault!
- They don't check their inputs (length) buffer over flow
- They parse or merge database commands (SQL injection)
- They don't limit abuse (brute force retry attacks)
Yes some of these can be mitigated at other levels, but ALL are common APPLICATION DEVELOPER ISSUES! by measure of deployment to number of exploits I would say the programing languages and OS already do a MUCH better job than the application developers...
EA David Gardner -"... but the consumers have proven that actually what they want is fun."
Computers are inherently instruct-able. That's their power, and that's where all security flaws come form. The underlying problems don't arise out of an industry-wide antipathy. If anything the reality is opposite, the entire industry in quite interested in the fundamentals of security.
The problem lies in the fact that we want to be able to tell computers what to do with a wide assortment of options on each of multiple layers(machine, operating system, high level language, and user application). Every one of those layers necessarily includes things we won't want to do that someone else could want to(i.e. security flaw)
This is like blaming car theft on a general malaise towards car security, when in fact it's a simple matter of cars that don't go wherever the driver wants or only ever accepts one driver is nigh useless.
...because we love hearing not only the clamor for new features, but also:
"Why won't you run on commodity hardware? I can get a system that does everything yours does, plus more [including things others make it do against my will], for half the price!"
"Why is your system so much slower? Every benchmark shows that other systems can do X in a quarter of the time [leaving the other 75% for executing malware]."
"Why does your system make it such a PITA for me to do this simple operation, when all the other systems let me [or any unauthenticated user] do it with a few simple lines of code?"
When you protect developers and users from themselves, when you start making engineering tradeoffs that reduce functionality and tinkering and fiddling ability in exchange for greater security and stability, some people start screaming that you've being evil, paternalistic and unfreedomly and not letting them decide for themselves whether they want to make tragic mistakes.
If you design your tools and infrastructure to prevent those with bad intent, it can also prevent those with good intent from using your system.
There is no magical solution that will solve our security needs. In reality, everything will require tradeoffs which developers have to balance out according to what they are trying to do.
The author can think of himself as an artist all he wants to. Here's a newsflash: other "arts" have to do things responsibly, too.
His whole argument is like an architect blaming the bricks when his/her poorly designed building falls over.
America's biggest threat is not terrorism. It's complacency. For such an arrogant industry, IT "solutions" sure do have a LOT of holes. That's what you get when you demand quantity over quality.
I've got a Farside on my cube wall. The caption is "Fumbling for his recline button, Ted unwittingly instigates a disaster." The picture is a guy sitting in an airplane seat about to grab a switch that's labeled "wings stay on" and "wings fall off".
It's a reminder to me to try to avoid giving my users a way to shoot themselves in the foot.
On the other hand, people need powerful tools to get their jobs done, and those tools can do horrible things when used incorrectly. There's only so much we can do to make things safe.
I .NET there is no buffer overflow or html inject (querystring and post data are scanned by default) or sql inject (using SqlParameter all data are encoded).
I "feel" a lots safer about basic security problem.
The article focuses on security problems that have been largely addressed, in exactly the way he's complaining hasn't happened yet. He focuses on smack stashing and buffer overruns, for example...and disregards the latest higher-level languages that manage memory in ways that makes these attacks far less common. He entirely ignores the most frequent and effective attacks (XSS, SQL injection) nor does he talk about the underlying causes of such vulnerabilities. (I, for one, am extremely curious how a SQL injection attack can be the fault of a fundamentally insecure operating system, since in many cases the attack traverses across multiple different OSes with nary a hiccup.) I'm not entirely convinced that he even understands the current state of what most vulnerabilities look like, to be honest. And finally, he gives absolutely no indications as to how to accomplish this lofty goal of an OS that would prevent there from being such a thing as an insecure app in the first place. It looks to me that all he's doing is whining about the fact that he's having to learn about proper and secure programming methods, which is taking away from his hobby of eating bear claws two at a time.
For your security, this post has been encrypted with ROT-13, twice.
Blaming the users, developers, tool chains, internet, or operating systems isn't going to help fix anything because those aren't the root cause of the problem.
Complexity is the problem. The solutions we're all used to using involve adding even more complexity on top of things, which makes it impossible to secure things.
There is another approach. It's called capability based security, and here's how it works:
For a given process, create a list of the files it needs to access, and the rights it needs for each. That list goes to the operating system, along with the program to run. The OS then checks the list consistently any time a file or other resource is needed. There is a special (but not onerous) way for the process to request access for other files from the OS (like when you need to open or save a file with a new name) called a "power box".
At no time is a process allowed to just try things out and scan around.
This means that you can simply and effectively limit the side effects of a given program, and not have to worry about buffer overflows, etc... because they can only result in processes which end up with the same limited access.
A capability based security system provides a realistic, reasonable, and fairly easily understood way of providing security which does NOT require trusting code (outside that of the actual OS).
This is the way forward out of the security morass we find ourselves in. I've been preaching this message for a while, and I hope that there are some out there in this wilderness who agree with me.
The article is stupid. But the language and OS problem is real.
First, we ought to have secure operating system kernels by now. Several were developed and passed the higher NSA certifications in the 1980s and 1990s. Kernels don't need to be that big. QNX has a tiny microkernel (about 70KB) and can run a reasonable desktop or server environment. (The marketing and politics of QNX have been totally botched, but that's a different problem.) Microkernels have a bad rep because CMU's Mach sucked so badly, but that was because they tried to turn BSD into a microkernel.
If we used microkernels and message passing more, we'd have less trouble with security problems. The way to build secure systems is to have small secure parts which are rigorously verified, and large untrusted parts which can't get at security-critical objects. This has been known for decades. Instead, we have bloated kernels for both Linux and Windows, and bloated browsers on top of them.
On the language front, down at the bottom, there's usually C. Which sucks. The fundamental problems with C are 1) "array = pointer", and 2) tracking "who owns what". I've discussed this before. C++ doesn't help; it just tries to wallpaper over the mess at the C level with what are essentially macros.
This is almost fixable for C. I've written about this, but I don't want to spend my life on language politics. The key idea is to be able to talk about the size of an array within the language. The definition of "read" should look like int read(int fd, &char[n] buf; size_t n); instead of the current C form int read(int fd, char* buf, size_t n); The problem with the second form, which the standard UNIX/Linux "read" call, is that you're lying to the language. You're not passing a pointer to a char. You're passing an array of known size. But C won't let you say that. This is the cause of most buffer overflows.
(It's not even necessary to change the machine code for calling sequences to do this. I'm not proposing array descriptors, just syntax so that you can talk about array size to the compiler, which can then do checking if desired. The real trick here is to be able to translate old-style C into "safe C" automatically, which might be possible.)
As for "who owns what", that's a language problem too. The usual solution is garbage collection, but down at the bottom, garbage collection may not be an option. Another approach is permissions for references. A basic set of permissions is "read", "write", "keep", and "delete". Assume that everything has "read" for now. "write" corresponds to the lack of "const". "delete" on a function parameter means the function called has the right to delete the object. That's seldom needed, and if it's not present, the caller can be sure the object will still be around when the function returns. "Keep" is more subtle. "Keep" means that the callee is allowed to keep a reference to a passed object after returning. The object now has multiple owners, and "who owns what" issues come up. If you're using reference counts, only "keep" objects need them. Objects passed without "keep" don't need reference count updates.
Do those few things, and most low-level crashes go away.
I won't live to see it.
The equivalent thing would be outlawing the use of C++ for anything carrying confidential/secret information.
True. All future operating systems should be written in Ada instead of C/C++.
Ask any MBA or beancounter. THey will gladly tell you that IT is a cost center that adds no value so there is no costs at all associated running IE 6 with no security updates after June 7th 2009, on a Tuesday that wont work with intraCrap from MegaCorp.
It is not like any financially sensitive information is ever used on computers anyway and since it is a dollar sink there is nothing wrong with using that and switching to typewritters since after all they are just a cost. ... (... end sarcasm)
My rant above is a serious issue. Especially for hospitals for HIPA requirements that still use IE 6 and unsupported who no updates, XP SP 2. The bean counters tell doctors what medical appropriate procedures to run too and not just how to handle IT and it drives me crazy when I contract work for them.
The worst offenders are not that McCrappy or Symantic endpoint, but software that is 100 security updates behind! Can't get more updates because the intranet app developers are lazy and do not want to support it, or are evil and do this on purpose so your employer can buy version B for $150,000 so they can run updates again or join the rest of the world and join Windows 7.
A patched Windows 7 office with IE 9, up to date updates and no flash or outdated java running in the internet zone, is like 300% more secure. The calls for malware go down drastically. The problem is always the MBAs and the obsession over the share price going up.
http://saveie6.com/
There are established and well-founded rules regarding static load and fire protection safety in regulations/laws for buildings.
But none of those make buildings vandalism- and arson-proof. Builders don't have to worry too much about malice; programmers do.
We can have a wide open no holds barred space to create anything good, bad or indifferent. Or we can lock it all down according to someone's idea of safe, fair and convenient. Under the second plan. a thousand things you are going to want to do will not be possible because they exceed the mandate of the security environment (no matter where you arbitrarily draw the line.) So you get to pick your demons. Me I like it the way it is. That's just me.
The high-level ideas of Java are sound, but the implementation (or "execution" in manager-speak) has been, and still is, awful. So awful that it is now considered a security risk to have Java Web Start enabled in browsers. I also managed to crash a JVM (about a year ago) by running a PDF parser on the JVM. I am quite confident a properly crafted PDF could have taken over my user id. So, in practice, Java is highly dangerous.
A properly failing program is vastly more secure than one which will open the gates to the confidential database. A proper exception stacktrace can usually be used to fix programming errors. Your post is actually demonstrating your security saviness. Proper programs do not "catch exceptions by random code". Unexpected exceptions should terminate the thread or maybe the whole process, depending on the circumstances. And that is the default behaviour.
That's vastly more secure than CAD workstations.
The AppArmor model isn't really capabilities. It's building a kind of sandbox, but of the wrong kind.
A good model is to let the user chose what they want to allow to happen... directly. If they don't feed a file to a process, it won't be able to touch it, ever, in a capabilities based system.
Having system administrators trying to figure out all the possible uses of a program isn't going to work, for the exact reasons you gave. The users are in a far better position to decide what they want done. A capability system allows just that, without weird random side-effects or restrictions.
for a home machine why not run a GUI?. It's not like it hurts anything.
It is not about freedom, but about the egregious laziness, ignorance and anti-professionalism on the side of the "management talent". These people are happy so spend fortunes on lawyers and to listen for hours to lawyers, but they think it professionals should better be ignored.
C++ is perfectly safe if you know what you're doing. The great thing about C++ is that it supports everything without ever getting in your way. Standard containers (including std::string) are perfectly safe; if you do shit, you get an exception, not a core dump.
C++ offers all the advantages of higher level language in a language at the same conceptual level as C, which is important for debugability, as the number of tools available to analyze, debug, and profile machine code is far greater than the number of tools available to debug, profile, and analyze byte code; and while you can claim that Java can be compiled to machine code, it differs from C or C++ in that it demands so much from its abstract machine that its own core can not function without a runtime, meaning almost all interactions with the hardware itself have to go through that runtime thus making it much harder to debug without tools specifically designed to understand the runtime.
You can write functional, declarative, statically typed, dynamically typed, event-driven, object-oriented, reflective, and meta code using C++, but you can't do most of these using Java. You can even implement your own allocators, smart pointers with specific garbage collection algorithms, and safe containers with it (if the standard ones aren't good enough for you) without needing another language, and you can link directly with machine object code from other compiled languages as well as export your own functions into libraries usable by other programs. The only thing you can't do very well in C++ is weak typing, but Objective-C++ has that covered, too...
The only problem with C++ are the people who do not really understand the language and approach it as if it was C with objects instead of a completely new language partially compatible with C.
"Everyone these days knows that you have to double- and triple-check your code for security vulnerabilities, and make sure your servers are locked down as tight as you can. But why? Because our underlying operating systems, languages, and platforms do such a crappy job of protecting us from ourselves".
That's not true, if the underlying Operating System is designed with build-in security, then any potential security vulnerabilities in the applications are very much mitagated and baring software bugs, the Linux security model does the job.
AccountKiller
"avoid buffer overruns you have to do bounds-checks at run-time. But these are very expensive." In the real world, this creates a runtime overhead of about 10 to 20%. Hardly an issue compared to the security costs of a successful penetration
...is that every C++ programmer thinks he is writing "robust" code and that array bounds, safe pointers and so on are not necessary in their case. Because they are so special, of course. Reality is, people make mistakes in anything non-trivial and the bad guys will exploit these mistakes. And that includes things like the Linux kernel and Google Chrome. I don't know the situation with ::std::string, but ::std::vector::operator[]() does not check bounds and it is used millions of times in real-world code. So the STL promotes unsafe-by-default programming.
Finally, C and C++ do have no proper concept of multi-threading and there are probably millions of race-condition problems waiting out there to be exploited by the Russkies and Chinese.
but have you ever seen a manager sitting down with his most experienced software developers and system admins and tell them "let's design a security policy which is both effective and acceptable to end-users" ? Surely they shell out lots of money on IT, but all the reasoning related to security risks boil down to "we are a business and we these twenty-five plugins installed on all corporate PCs". Convenience trumps security any time, in my experience. Security is definitely not managed - it is considered a nuisance and something not really worth bothering about. A "chief security officer" will be appointed and then the subject will be ignored, when the rational thing to do would be more user education and designing security policies and processes in a way that integrate into the business processes. As opposed to obstructing them and then being circumvented by users. The underlying reason for that sad reality is a lack of management attention and serious desire to improve that aspect of the business.
Yes: "Well designed equipment today is much safer ... reality that industrial accidents are everyone's problem. The resulting disabilities are a tax on society."
Yes. "The argument that safety is futile and no effort should be made to improve it is the voice of laziness"
No: "A remote code execution exploit is a serious matter and should be accounted for in business decisions while calculating risk avoidance. "
How the heck can you calculate the financial loss from malware inside your network ? It might range from the mundane to the destruction of the company, if a capable, cheaper-cost-base competitor gets the complete crown jewels.
Also, you are regurgitating the Beancounter/MBA Fallacy "what you cannot quantify you cannot understand and change". We all go great lengths in terms of hygiene and use of condoms, without anybody calculating the "financial loss" from AIDS or the plague. We know it is horrible and we spend serious effort (e.g. daily dishwashing) to make sure we don't get the diseases. Also, I find it completely impossible to quantify the losses from an exploitable weakness. There are too many variables inside and outside your company to make a proper statement.
All we can say is "damage might be from zero to complete financial destruction of company". Of course, you might make a more detailed statement if the exploit only matters in a specific department (e.g. only accounting uses Windows and the exploit). But still, how can you properly quantify your financial details being in the hands of your asian competitor ??
Yes: "Well designed equipment today is much safer ... reality that industrial accidents are everyone's problem. The resulting disabilities are a tax on society."
Yes. "The argument that safety is futile and no effort should be made to improve it is the voice of laziness"
No: "A remote code execution exploit is a serious matter and should be accounted for in business decisions while calculating risk avoidance. "
How the heck can you calculate the financial loss from malware inside your network ? It might range from the mundane to the destruction of the company, if a capable, cheaper-cost-base competitor gets the complete crown jewels.
Also, you are regurgitating the Beancounter/MBA Fallacy "what you cannot quantify you cannot understand and change". We all go great lengths in terms of hygiene and use of condoms, without anybody calculating the "financial loss" from AIDS or the plague. We know it is horrible and we spend serious effort (e.g. daily dishwashing) to make sure we don't get the diseases.
When you open an email, you only give it access to write to a window on the screen, and a connection to the email server. This would mean that a rogue email could at worst send out copies of itself, if it managed to confuse the reader. The process would not be able to randomly go out and open files, write them, etc.
Lots of things get fixed when you say no by default instead of yes.
You doubt that it would work, but at least you're thinking about it.
If the user gets to decide what to feed to a process at run-time, instead of the process having all of the users access the user can then be responsible for their choices, which the OS will respect. Right now we don't even have a good way to do this. (As I said, AppArmor isn't capabilities)
Being able to even express the idea coherently is a step in the right direction towards doing something with that idea. Thanks for helping me do that.
Experts say Macs will be targeted more and more in upcoming years. Low market share is no longer protecting the platform, it seems.