The Cost of Crappy Security In Software Infrastructure 156
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!'"
Ugh (Score:5, Insightful)
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.
Re:Ugh (Score:5, Insightful)
This 1 million times THIS!
Any tool that is useful will be dangerous.
Re: (Score:2)
Agree.
As you increase the general-purpose utility of any piece of technology, you open corresponding opportunity for abuse or exploitation.
Security comes through ongoing practice. This includes implementation specifics, ongoing management operations and individual initiative/decision capacity of users.
To believe there is a technology solution that - correctly implemented at the correct point of design and lifecycle - would automatically solve the security "problem"? This is a naive point of view, which ign
Re:Ugh (Score:4, Insightful)
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.
True. But I think the biggest impediment to secure systems and code is what people like my 82 year old dad are going to do if you ask them to start making selections or decisions regarding how tight or loose they want access to the internet. He's going to get angry and tell me, like he always does when I have to clean viruses off his computer, "I just want to read my email!" And there's more people a lot younger than him that will respond the same way, only it'll be over free smilies, fonts or porn.
Re: (Score:1)
Have you considered buying him a Mac? Best investment I ever made when it came to my parents' computing, and my dad is even an electrical engineer. Some people will complain about the cost, but unless your time is completely free, it is easily worth it.
Re: (Score:2)
Have you considered buying him a Mac?
...or installing Linux Mint for him? (a decent amount cheaper, and less confusing for someone moving from Windows...)
Re: (Score:2)
I'm running Linux, Windows, OSX and FreeBSD at home on various computers, let alone vmware, and mobile (android, webos and ios) devices. What's easiest for me, isn't what's most compatible for my parents/grandparents. I will
Re: (Score:1, Funny)
I considered giving up my girlfriend and peddling my ass down the gay part of town, but no, I really didn't. Just like I would never buy a Mac for myself or my family when I could get the same performance and security out of a Linux box for 1/7 the price.
Here's a Mac-related joke, though - why did they bury Steve Jobs face-down? So people like you could stop by for a cold one! Hah heh, silly Macfags.
-- Ethanol-fueled
Re: (Score:2)
Have you considered buying him a Mac? Best investment I ever made when it came to my parents' computing, and my dad is even an electrical engineer.
Funny. My dad was a mechanical engineer and you'd think he'd know. I've told him under pain of death that he is never to buy another computer without my input, and yes, it'll be a Mac. Every computer in my house is a Mac, except for the file server, and it's running Mint.
Re: (Score:2)
why not? (Score:2)
for a home machine why not run a GUI?. It's not like it hurts anything.
Re:Ugh (Score:5, Insightful)
I personally am from the IT school of "all operating systems suck, so pick what sucks less", and in some cases, the Mac recommendation may be the best way to go.
First, Apple has actual customer service compared to the PC companies (well, unless you buy from the "business" tier and get the better support plan.) So, they will have someone to call to get problems fixed and questions answered that isn't you.
Second, building them a desktop is in some ways the best solution, but it means you are on 24/7/365 call if anything breaks.
Third, Macs are not unhackable, but as of now, the biggest attack is through Trojan horses, while Windows is easily compromised through browser and browser add-on holes. So, for now, Macs have a less of a chance of being compromised by browser exploits.
Fourth, Time Machine isn't perfect, but compared to other consumer level backup programs, it is good enough. Especially if paired up with Mozy or Carbonite for documents. That way, the parent's documents are stashed safely even if the computer and its backup drive are destroyed or stolen.
Fifth, the App Store and a stern instruction to not run anything unless it came from there will help mitigate the possibility of Trojans. It isn't perfect, but it is a good method.
Of course, Linux is a workable solution as well, but a Mac's advantage is that it still has a mainstream software selection available for it, so Aunt Tillie can get a copy of Photoshop if she so chooses.
Bad advice (Score:2)
Re:Ugh (Score:4, Insightful)
I find the biggest impediment to secure systems is cost. In previous companies I have worked for, there was a mantra by the management, "security has no ROI."
The fact that on the accounting ledger, proper security practices, doesn't mean black numbers are added, but that red numbers are not added escaped them. The typical response when I asked what the contingency plan about a break-in was usually "We call Geek Squad. They are open 24/7."
Yes, good security costs. Good routers, firewalling, hiring clued network guys, and running penetration scenarios are not cheap. However compared to other business operating costs, it isn't expensive on the relative scale.
Because there is little to no penalty if a business does get compromised, there is not much interest in locking things down. Until this is addressed, crappy security policies will be the norm.
Re: (Score:2)
Security has a best case of no return and a worst case of "you lose everything".
Preventative doctor visits also have no ROI, yet they keep saving money by saving lives.
Ask them why they think banks "waste" money on security.
Re: (Score:2)
I think it's harder to cut your hand off with a chainsaw than you realize, since they really require two hands to operate. A circular saw, on the other hand. . .
Re: (Score:2)
Hit a nail in a tree onetime and see where it wants to go. It won't get your arm, but a chainsaw to the ribcage is not much better.
Re: (Score:2)
NOODLE ARMS! Really. You should have control over that bastard.
Re: (Score:2)
I grew up in rural area where logging was and still is a common occupation. Noodle arms has nothing to do with it, if you are not paying 100% attention at all times when it kicks back bad things will happen.
Re: (Score:2)
But don't you think it's advisable to pay 100% attention at all times when using a chainsaw? I mean, it is a chainsaw after all. . .
Re: (Score:3)
Indeed. You're supposed to treat it like it wants to murder you at the first opportunity.
Re: (Score:2)
Or to the neck. A guy I knew lost his brother due to a chainsaw accident.
Re: (Score:2)
My chainsaw is a couple of years old, but it just has a startup lock that requires two hands. Once it is in operation, it requires only one hand to operate.
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Re:Ugh (Score:4, Insightful)
Yeah, and tools have safety standards too. Just because you accept the risk of a car crash when you buy a car doesn't mean you have to accept the risk of your car spontaneously exploding.
More importantly, if you're writing PHP code that costs money when you have an XSS vulnerability, that means you're responsible for your users' information. So, no, if you want to leave your PHP open to XSS, do it where it doesn't add to the cost of crappy security. And do it in a way that doesn't result in your site being hijacked to serve malware and spam for months on end before you notice.
You're not an island. Personal responsibility means you don't blame other people for stuff that's your own responsibility (like getting hacked); it doesn't mean you can just neglect the responsibility of protecting you customers' or boss's data, or the network that your share.
Re: (Score:2)
That kind of safety is already available in modern implementations in the form of buffer canaries, randomized memory maps, read/write/execute memory protections, and managed memory allocations that are nearly transparent to the users. This is analogous to your car example, in which safety features exist in order to mitigat
Re: (Score:2)
But designing things well is hard. For one, most designs like that focus on wants and nice to haves, and not strictly on needs, and the other, the designs are discarded when
Yeah, yeah, yeah. (Score:5, Insightful)
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.
Re: (Score:2, Insightful)
Except the industry has painfully simple solutions to buffer overruns, like, say, almost any programming language developed after 1990 has no risk of buffer overruns.
Re: (Score:2)
No risk of maturity either.
Truly powerful tools are always dangerous.
Re: (Score:1)
Oh yeah, I've heard that java is such an immature platform that no one ever uses it, and it can't do ANYTHING.
Get over yourself.
Re: (Score:2)
The JDK has never had a buffer overflow?
Secunia disagrees.
Re: (Score:2)
I don't feel up to dealing with dissembling of this sort. You said "code a buffer overrun". You can't do that. The end. The JDK ISN'T programmed in java. The applicability of overruns it gets(which are basically impossible to cause with a significantly more complicated exploitation to run arbitrary code first) are irrelevant.
Re: (Score:3)
Fine, then I will just admit this one flaw is something java does a good job at preventing. It still will not magically check your inputs for you.
Re: (Score:2)
No, it doesn't, but the original point is that the industry does nothing systematic for security. It's untrue. We actually work pretty hard as a whole on considering at least nominal security. Perfect security requires a non-existent level of perfection, so we address the problems with our software as it stands, and plan for the underlying basic security concepts that are well known and we can afford to.
I honestly belief that software engineering is natively one of the most security conscious professions
Re: (Score:2)
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++.
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
For starters, all C++ sequence containers implement .at(), which is bounds-checked. Secondly, both C11 and C++11 support threads. Third, I'd laugh my ass off if anyone even attempted to write a kernel using a safer language that doesn't implement pointers or the concepts of auto and static duration. Even C++ (which implements those concepts) is deemed unworthy of kernel-code because of the potential performance issues caused by implicit copy constructors used for type conversions, the consequences of sem
Re: (Score:2)
The only thing specified by standard C++ regarding operator[] is its semantic (a[n] <=> *(a + n)); everything beyond that is unspecified. Two versions of operator[]() (one const, another mutable) are declared for all sequence containers except std::array, which is intended to work like a raw array when one is expected while supporting an interface that makes it compati
Re: (Score:3)
The designers of Java tried to do two things regarding security:
1. allow running untrusted code (applets) without letting it break out of its sandbox
2. prevent unsafe memory access by bounds checking, type checking on casts, no explicit deallocation
#2 is a prerequisite for #1, since if code can write to arbitrary memory locations then it can take over the Java runtime process. However, #1 is not a prerequisite for #2. Java has in practice done poorly at meeting goal #1 but has been quite solid at #2.
Re: (Score:3)
Note that while Java may prevent common bugs like buffer overflows, they may simply cause it to throw an unexpected exception which is caught by random code which then causes the software to behave in an unexpected way. So it's an improvement, but not a magic solution to all your security issues.
And you can probably do all kinds of exciting stuff with random Java programs by throwing so much data at them that they run out of memory and explode in a hail of cascading exceptions.
Re: (Score:2)
I wasn't saying it was a magic bullet, I was saying it addressed a fairly basic common security problem by being an advancement in technology. But it's 20 years old now, better things have come along too.
Re: (Score:2)
What are you saying? That modern languages aren't powerful because you can't perform buffer overruns? You realize that even if your statement that more power --> more exploit were true, there are a million other vulnerabilities out there besides buffer overruns, which is a feature completely useless for the vast majority of programming.
Re: (Score:2)
Yes. If you truly cannot have buffer overflows, then there are many things the language cannot do. You will never, for example, be able to write a device driver for any existing hardware architecture in any language that does not allow you to construct fixed-length buffers and fixed data structures. By definition, any language that supports those things can experience a buffer overflow.
This is not to say that languages should not have string handling capabilities that are immune to buffer overflows, mind
Re: (Score:2)
Buffer overflows are independent of whether you have fixed-length buffers and fixed data structures. You can have them with variable-length buffers as well.
The essential problem that causes a buffer overflow is that your language supports a data-copying (or data-writing) operation that either does not care about or must be explicitly told the amount of space available in the destination. This essentially means that you must have range-checking for all pointers.
Last I knew, Ada is both immune to buffer overf
Re: (Score:2)
No, it isn't. Not on any hardware built in the past two or three decades. Hardware is almost invariably configured at run time these days; the order in which devices are iterated depends on when they were plugged in. Heck, we now have hot-pluggable hardware that looks like an actual PCI device (Thunderbolt). There's no way to compute the address
Re: (Score:2)
Whether the "driver" is written in a low-level language with pointers or not, the piece of code that is actually interacting with the hardware (in this case, the JIT) is not written in a pointerless language. You can always add layers of abstractions to try to hide what's going on at the bottom layer. That doesn't change what is going on at the bottom layer. It's just a convenient fiction.
Re: (Score:2)
And compiler-level support for the equivalent of an address in memory (pointer). After all, that's what the address of the device is.
Yes, blame the developers! (Score:5, Interesting)
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...
Re:Yes, blame the developers! (Score:4, Interesting)
- They parse or merge database commands (SQL injection)
I would argue that this one is sometimes the fault of the tool. In most database APIs, there's a function like:
run_sql(String command, Object[] data)
But the language that most amateur programmers use only has:
mysql_query(String command);
Looking at that function signature, who's the know that you're supposed to also use mysql_real_escape_string. Even if you know what you're doing, you might accidentally use addslashes or mysql_escape_string. Or forget it for one parameter.
Interestingly, the language that does this best, is also the second worst language ever invented (after PHP). In ColdFusion, if you do this:
select * from cats where cat_name = '#catname#'
It's perfectly safe, since ColdFusion detects that catname is inside of quotes, so it automatically escapes it. You can still use variables inside of SQL, since it only escapes them when they're inside quotes.
Re: (Score:2)
Your example is still a failure of the developer understanding the tool which caused the problem, not the tool missing an alternate secure way to do it.
Re: (Score:2)
Say someone sells a car where there's three pedals: a gas pedal in the normal place, a brake pedal in an unusual place, a pedal that functions like a brake normally, but swerves into oncoming traffic if you're going over 50 mph. Is it the users fault that suddenly they're all crashing? The manual clearly states, "don't ever use the pedal where the brake pedal used to be, because you might swerve into oncoming traffic". But still, isn't it mainly the manufacturer's fault for including that pedal at all?
Re: (Score:2)
Developers are not end users... they are some level of engineer, as they are BUILDING things for end users to use... They should be reading some kind of docs before choosing tool / function they use for the job... the more powerful the language the more you need to know.
In your example the developers should be the ones that build the BAD CAR with the exploit in it that was sold, they where not the poor end users that purchased it.
Re: (Score:2)
They should be reading some kind of docs before choosing tool / function they use for the job... the more powerful the language the more you need to know.
This is the exact opposite of how normal people describe powerful languages. The most powerful languages let you get the most work done while fighting your language the least. With a language like Java or Python, I can generally *guess* what the correct function to do a task is, and it tends to work (although if you do this in Java, you tend to get the worst possible implentation -- but it will work correctly). In PHP, you need to read the full documentation for every function you call, then Google it to ma
Re: (Score:2)
This is the exact opposite of how normal people describe powerful languages. The most powerful languages let you get the most work done while fighting your language the least.
When a language is doing lots of work for you, you'd better know what kind of work it's doing.
Re: (Score:2)
In my opinion, acting like an engineer means accepting that you're only human and are going to make mistakes. Therefore, adopt tools and practices that reduce the chance of mistakes and reduce the damage when mistakes do occur.
In the case of SQL, pick a database interface that automatically escapes every string substituted into a query. This one architectural decision eliminates an entire class of bugs; it's much more effective than double checking hundreds of individual query constructions. And it has the
Re: (Score:2)
This so much. I went from ColdFusion development to PeopleSoft, and I find myself missing such nice things from ColdFusion.
Re: (Score:2)
I can't bring myself to actually miss anything about ColdFusion, but I do find it interesting that they managed to solve the #1 security problem on the web. If only they could automatically detect when you're trying to store a password, and run it through bcrypt first ;)
Re: (Score:1)
> I would say the programing languages and OS already do a MUCH better job than the application developers...
Unless the language in question is either PHP or JavaScript.
The first was written by someone with no clue about language design or network security. The second was written by a competent enough programmer who was constrained by having to write the language and library from scratch within a week.
PHP's idea of a database API was an "execute string as SQL" function, pushing the responsibility for avo
Re: (Score:2)
- Prototypes are taken directly into production. The prototypes intention was to actually flesh out the business rules. After initial testing does it do what the customer wants or can it do what the customer wants, customer is happy and wants it right now.
So how did the prototype get so poor -- after 4 or 5 iterations where the develope
Totally off-base (Score:4, Insightful)
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.
Re: (Score:2)
I disagree. While what you're saying COULD be true, everything I've heard from everyone from programmers to IT employees point to the opposite. As if the news weren't enough. Sure, a security firm getting hacked might be an instance of "if someone wants to hack you badly enough, they will," but many more problems arise because management makes the decisions about where to spend resources, and they're always pushing edge for features because that is where the money is.
Re: (Score:2)
Whoa, I'm blown away by the concept that there are compromises that establish a balance of different needs due to budget limitations. That never affects anything but security.
Re: (Score:2)
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.
Whoa, I'm blown away by the concept that there are compromises that establish a balance of different needs due to budget limitations. That never affects anything but security.
Stop being stupid. Sarcasm doesn't make you right, and my point is quite clear, but I see I need to spell it out for you anyway.
There IS industry-wide apathy, and the reason is because higher-ups benefit more from pushing features that edge out the competition next month than they do from long-term investment in security that might save them two years from now, which is what they are doing. If the managers/CEOs at a small car maker could save money by making one identical key/lock across all their cars, the
Re: (Score:2)
The car industry did move towards key fobs that authenticate legitimate holders. And the computer industry can do similar kinds of tricks.
Re: (Score:2)
We do. We do all the time. That doesn't mean that every choice made should be with a "Security first, freedom second" attitude. Every situation needs known severe risks addressed, and everything else played by ear. That's just how complex projects work.
Re: (Score:2)
Even the companies not in the tech sector I've worked for have had massively larger IT budgets than legal budgets.
"Rock-solid HW/OS"? We'll get right on that... (Score:3)
...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?"
Re: (Score:2)
... and yet such PITA systems like SELinux do exist and are utilized.
Solutions are there, people need to just stop being lazy bitches about it.
Just Ask Apple (Score:2, Insightful)
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.
Re: (Score:2)
I'd say ask IT security people. Apple is hardly a good example since their reasons for their walled garden model has been more about what makes money than what makes things secure. It's been very successful at creating a certain experience for the users, but only recently has it taken up the slack as far as security goes, so I feel Apple deserves the criticisms it receives.
Re: (Score:2)
That's funny--I don't hear that sort of screaming about OpenBSD, which is miles ahead of Apple on making a solid, secure system. Maybe it's not the greater security and stability that pisses people off. And it's not the reduced functionality, because OpenBSD has that too. Maybe it's the reduced ability to tinker and fiddle, and the fact that you don't actually own what you bought, and the fact that Apple really are arrogant and paternalistic.
(Actually, I think OSX is a perfectly adequate system. It's Ap
It is a double edge sword (Score:4, Insightful)
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.
Re: (Score:2)
Wait, the evil bit[RFC 3514]? ...
Rgds
Damon
Re: (Score:2)
The great majority of applications today could be coded up in environments similar to what developers are already used to using, but constrained by sandboxes, if the sandbox author were to provide useful tools for the developer to do things they want to do. Examples include local storage on the file system, database interactions, etc.
Oddly enough, efforts to solve the concurrency problem might also help our security problem. Witness http://flowlang.net/ [flowlang.net] for example. Being able to analyze the source latti
Re: (Score:2)
Like Perl?
Well that was 7 minutes I won't get back (Score:2)
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.
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
The underlying platforms and infrastructures we develop on top of should take care of [ensuring security], and leave us free to innovate and create the next insanely great thing.
The other major factor in why things are so bad is that we don't care, evidently. If developers refused to develop on operating systems or languages that didn't supply unattackable foundations, companies such as Apple and Microsoft (and communities such as the Linux kernel devs) would get the message in short order.
This article is missing even a gesture towards explaining why "the infrastructure" should be responsible for security while developers create their masterpeices, and boils down to mere whining: "Security isn't fun so someone else should do it for me!" Perhaps the worst part is that there is a good argument to be made that the OS and hardware should take of security, and a fundam
IT weenies don't know anything about security (Score:1)
Re: (Score:2)
Correction: MANAGERS don't know anything about security.
Let me assure you, IT does - unless MANAGEMENT has ensured they only hire those who don't. The ones that do, however, cannot exercise it because of MANAGEMENT.
Re: (Score:1)
The probem is always management. It is taught in business school. They tell the other guys what to do and set the budget.
In a large office with 3,000 users a few IT support guys are rushing around constantly and do not have the time to update and do testing. The budget is never set high enough to do it as they are viewed as cost sink or cost center by the finance department. The bean counters are much to blame as do the management for not selling themselves better about the hidden costs not shown in Excel b
Re: (Score:2)
Oblig Farside (Score:3)
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.
That's why I code in .NET (Score:1)
Re: (Score:1)
My specialty is not .NET.
I can tell you that when I rewipe my computer with a fresh Win 7 image there are over 120 security updates and half are .NET. Hours later there are more security updates with the .NET platform. I do not think it is secure as you think.
Wah, wah, wah. (Score:3)
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.
So close, and yet so far (Score:2)
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.
Re: (Score:2)
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 capabili
Re: (Score:2)
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.
Re: (Score:2)
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.
Stupid article. Important point. (Score:4, Interesting)
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.
Re: (Score:2)
int read(int fd, &char[n] buf; size_t n);
char buffer[10] ;
&buffer[9] will point to the address of the last element of the buffer.
&buffer[10] is outside the buffer range -->> BUG, C programming 101.
if the function as stated above requires that n be the buffer size, then:
1. You will always be passing a pointer to outside the buffer size.
2. You will always be required to read ONLY the full size of the buffer.This will prevent reading more than what the buffer can hold, but it will also prevent reading less than the buffer size.
Re: (Score:2)
The intent of the new syntax is that &char[n] buf means passing a reference to an array of size n. char[n] is an array type, something C currently lacks. Syntax like this is needed so that you can have casts to array types.
I've had a few go-rounds at this syntax problem. See "Strict pointers for C" [animats.com]. Unfortunately, there's no solution that's backwards-compatible with existing code. However, mixing files of old-style and new-style code is possible, and mechanical conversion of old-style code to ne
Ah ah (Score:1)
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 i
We get to choose... (Score:2)
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.