Slashdot Mirror
Michal Zalewski On Security's Broken Promises
Lipton-Arena writes "In a thought-provoking guest editorial on ZDNet, Google security guru Michal Zalewski laments the IT security industry's broken promises and argues that little has been done over the years to improve the situation. From the article: 'We have in essence completely failed to come up with even the most rudimentary, usable frameworks for understanding and assessing the security of modern software; and spare for several brilliant treatises and limited-scale experiments, we do not even have any real-world success stories to share. The focus is almost exclusively on reactive, secondary security measures: vulnerability management, malware and attack detection, sandboxing, and so forth; and perhaps on selectively pointing out flaws in somebody else's code. The frustrating, jealously guarded secret is that when it comes to actually enabling others to develop secure systems, we deliver far less value than could be expected.'"
Computer security will kill itself.
Emotions! In your brain!
IT & PC security companies will never "fix" things or come up with a solid and secure foundation for computer security - because it would put them out of business.
When Virtual Security mirrors Physical Security - people should expect more from virtual security? How is a Night watchmen not a form of "vulnerability management" and "attack detection"?
All security in general is reactive. You can't proactively solve every problem - this philosophy goes beyond security. The proactive solution is to plan on how to handle the situation when a vulnerability gets exploited, something I think virtual security has managed to handle a lot better than physical security.
Reactive security is not necessarily a bad thing. Only by challenging today's security can we seek to inspire people to improve security for tomorrow.
I do, however, feel that security in the digital age is laughable at best. It turns out telling a computer not to do what it's told is significantly harder than telling it to do what it's told.
I just get this feeling like the approach is all wrong to security.
At the heart of the security concept is that CPUs generally aren't designed with security in mind. I blame Intel, ARM, Motorola, IBM, and anyone else I can. CPUs are just executing code they're told to execute. NX, ASLR, and other "security" features don't work. Particularly when the underlying architecture itself is flawed.
Well, no, IBM gets a pass. Given that the PS3 has yet to see a major exploit, I believe that the Cell may have security done right.
Non impediti ratione cogitationus.
Computer security is roughly equivalent to real-world security, only the malicious agents are extremely fast, can copy themselves at will, and can hit as many targets as they want simultaneously. When considered from the point of view of real-life security, our software security problems seem almost inevitable.
The central insecurity of software stems from the fact that security requires time and effort, which makes it hard to get management to fully commit to it, and there's nothing in the world that can make a bad or ignorant programmer churn out secure code. There have been solid steps taken that have helped a lot, and programmers are getting more educated, but at the end of the day security requires a lot of effort.
Security can be widely deployed by enterprise IT, OS vendors, and possibly some hardware OEMs. The larger the footprint, the easier it is for such real security to be rolled out. The thing is, while some IT departments have very good security, just as many have terrible. Hardware vendors are unlikely to have the expertise and are unlikely to be able to profit using an integrated security platform as a differentiator. This pretty much leaves OS vendors. MS has a monopoly so they don't have much financial motivation to dump money into it. Apple doesn't really have a malware problem, with most users never seeing any malware let alone making a purchasing decision based upon the fear of OS insecurity. Linux is fragmented, has little in the way of malware problems, and has niche versions for those worried about it.
I'm convinced malware is largely solvable. It will never be completely eliminated by the vast majority could be filtered out if we implemented some of the cool new security schemes used in high security environments. But who's going to do it? Maybe Apple or a Linux vendor if somehow they grow large enough or their platform is targeted enough. Maybe if MS were broken up into multiple companies with the IP rights to Windows, they're start competing to make a more secure product than their new rival. Other than that, we just have to sit in the mess we've made.
Considering that the x86 platform is inherently insecure, I don't understand why this is surprising to people. Until we move away from the architecture, I don't think someone who says they takes PC's security seriously is being as serious as they could be. And yes, I do realize that a new architecture is a huge change, and one that's going to be a long time coming... But it's something that WILL happen. We will eventually need to overcome the shortcomings of x86, and it's at that point that we can really start to take proactive PC security more seriously.
It may be that a secure and convenient system is possible, but it's too expensive for anybody to sit down and write.
Rather, we're slowly and incrementally making improvements. There's quite a bit of momentum to overcome (witness the uproar when somebody suggests replacing Unix DAC with SELinux MAC) in any installed base, but that's where the change needs to come from, since it's too expensive to do otherwise.
If time and money were no object, everything would be different. More efficient allocation of the available time and money is happening as a result of Internet collaboration.
So, 'we're getting there' seems to be as good an answer as any.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
-kgj
I think the issue is not that we're bad at security, it's just that attacks are cheap, so you need the virtual equivalent of fort knox security on every webserver. That sort of thing isn't feasible.
The lock on my house isn't 100% secure, but a random script kiddie isn't pounding on it 24/7, so it's good enough.
In my experience, developers don't want Security anywhere near their products. We insist that they fix these "theoretical" and "academic" security problems, ruining their schedules and complicating their architectures.
Fine! Whatever. We will continue cleaning up your messes and pointing out the errors in your coding (which we warned you about). You can continue stonewalling us and doing everything you can to avoid us. We still get paid and you still get embarrassed.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
Modern Microsoft OSs aren't really any more "inherently vulnerable" than anyone else that might be viable in the consumer space. At this point it's more about getting the apps onboard with the security model. In the server space, Win2008 r2 gets most things right - just about everything is off by default, the kernel itself is quite secure, there's a good model for running as a non-admin and escalating when needed.
The biggest problems with Windows right now are apps that pointlessly need to run as admin, and apps that don't sandbox even narrower than "all the current user's data". All OSs are equally vulnerable to social engineering trojans - if you can trick the user into giving you the root password, you win - but outside of that Windows itself is only particularly weak in that a lot of the code is still new.
The real trick for security - for Windows and everyone else - is to adopt a model more like SE Linux where you just agressively limit what each app has access to. SE Linux is too hard to configure for the broad market, but a simpler approach where each app is sandboxed in a VM with just the resources it needs will shut down the "drive by" attacks involving flash, PDF, and similar apps. You can't do much about social engineering trojans, but you can fix the rest with sandboxing/jailing that doesn't require the end user to configure stuff.
The Web browser shouldn't be special in this regard - every app should be jailed automatically, requiring effort from app developers to broaden an app's scope, instead of the current model where app developers are asked to do extra work to narrow an app's scope.
Socialism: a lie told by totalitarians and believed by fools.
That particular example is a bad one for the point you're making.
Things happen when you have control logic and peripherals.
By "peripherals" I mean anything the code can control. It could be a database, or a Space Shuttle main engine.
Dan Bernstein's theory, which he sharply distinguishes from least privilege, is to ruthlessly eliminate the code's control over anything not actually required. No matter how complex the code, it can't do anything that the computer can't. No compromise of my laptop could damage a shuttle main engine. Sandboxing is an attempt to implement this philosophy.
By "control logic", I mean anything that is an input that has results. A mouse is control logic. A radio button on a form is control logic that is simple enough to analyze. A web browser is control logic that is beyond definite analysis.
So a web form that builds a SQL statement from user input should have set off alarm bells on general principles, because it's allowing a malicious user to edit code in a complex programming language that has control over a database.
If you define security as being able to determine whether or not a program will reach an undesired state given arbitrary input, isn't that equivalent to the halting problem? Isn't that NP hard? I know that I generally force programs to halt when they're behaving badly, if they don't halt on their own.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Getting rid of illusions is a valuable service even without proposing a fix, and it's not the job of the fire alarm to put out the fire.
Sometimes saying there is no solution frees up resources to adapt and cope. If you call the fire department and say "my potassium stockpile has caught fire", the best thing you can tell them is that they're need to fall back, protect other buildings, and let it burn itself out.
I still try to protect my clients, but part of that is to warn them that certain problems are unsolvable with today's mainstream tools.
Until there are negative consequences for the execs, there will never be IT security because it costs money. If the execs of companies that have IT breaches were jailed for a couple of years (hard time, not some R&R farm) and personally fined millions of dollars, they would insist on proper security, rather than blowing it off. 'Course, these are the same guys who schmooze with, and pay bribes to, "our" elected representatives, so that's never gonna happen.
"Security is not a product, it's a process", and, since there's no easily calculated ROI on the time spent on securing IT, even when there's a paper process, it is so frequently bypassed that it might as well not exist.
#1. Getting management to say "OK we'll let the deadline slide, max out the budget and reduce some functionality/ease-of-use so we can fix the security flaws".
#2. Getting minimum wage Java programmers to understand/care about securing their code.
Things are not helped by the sad state of so-called security products by the likes of Symantec that seem very popular with PHB's, they must have a lot of sales reps hanging around golf courses.
Its also a bit much Google bitching about other people's security - wardriving streetview anyone?
#include <sig.h>
No. And no one is saying that.
You might want to look at this article.
http://www.ranum.com/security/computer_security/editorials/antivirus/index.html
There is no SINGLE solution that is 100% EFFECTIVE for EVERY scenario.
But the current focus on black lists is ineffective. At least white lists would give SOME degree of protection.
Fuck legacy. Seriously. I'm tired of everyone trotting out "legacy" as if it were some natural law.
A 100% brand new system today will STILL be vulnerable to the same attacks that were directed at the previous version of that system. That is simply bad design.
And why do you need that?
Why not just a series of steps getting from the current disaster to a state closer to "best practices"?
Because there will always be "malware" does NOT mean that the situation cannot be improved. Instead of millions of machines infected, how about we aim for an environment where only 100,000 machines are infected?
That's crazy talk. Microsoft has led the way in principles of application security, secure web frameworks.... they've not exactly blazed the trail with managed language runtimes and secure-by-default, but it's an understatement to say they have certainly caught up.
Take off every 'sig' !!
I'm convinced that the software companies intentionally fuck up the interfaces like that. That way they are not responsible if the user installs something bad.
And, exactly like you posted, the user will NOT read the pop-ups after the first few. All they will see is a "click 'yes' to continue" the same as they see on the EULA's and every other pop-up. The same as "do you want to run this".
A basic white list would be better for the users than the current situation. And pop-up a DIFFERENT box when the user is trying to install anything not on that white list.
Who makes the white lists? Why not the anti-virus companies? Yeah, I know about McAfee. At least this way they'd be more effective. If you want to install Civ9 and the anti-virus app checks the hashes and sees that it is legit, then no scary warnings.
It should be easier to keep a list of software from major vendors than to try to track every possible variation of every piece of "malware" out there.
Oh yeah, I sort of did forget about the zombies... I work in application security and probably have kind of a narrow view.
Take off every 'sig' !!
I would hate to work in an environment where "it's hopeless, nothing we do today works" was the prevailing theme.
Take off every 'sig' !!
No, no, no! You've got it all wrong. It isn't the infatuation with Turing Machines that is the problem. It is the infatuation with *Networks*. Once we eliminate all means by which one computer can communicate with another we'll have the perfectly secure computer that we've all always dreamed of.
Actually, that might not go far enough. Some evil hacker terrorist-type might still be able to infect systems through software loaded from a disc or something! Better to just do away with the whole I/O system. I'm not sure why some folks in this industry are so infatuated with it anyways.
Interesting points, but you are just a horrible person. Do you put on a balaclava and talk this way at dinner parties?
Take off every 'sig' !!
I'm assuming I'm misreading something here? The article is a little light on details but it sounds like all they're doing is constructing automated unit tests by brute-force running each possible input through an existing correct routine which can then be applied to later modifications of said routine. Which strikes me as remarkably bad in several ways:
- You need to know that the routine is correct in order for the "diagnostic subprogram" to create a correct set of tests. But if you already know its correct, why would you ever need to change it? If your answer is "requirements might change", then you've basically declared that the routine is no longer correct and that immediately implies your diagnostic tests are no longer correct, so any flags they might throw up can't be trusted and are therefore useless.
- Even for a computer, its impossible to test every input. For a single standard 32-bit integer you have 4 billion possibilities. A modern fast computer could probably perform a simple operation 4 billion times in a few hours. Chances are anything complex enough to fit under the article's purposes wouldn't also be considered a "simple operation". Never mind multiple inputs (two 32-bit integers as your input would make the test infeasible even on the fastest modern computer. And a string with no length restrictions can't possibly be fully tested via brute force on any finite system ever, since the number of possible inputs would be infinite). So you start having to come up with input classes (integers greater than 100 shouldn't be valid for a "percentage" for example). But to do that you need to know what that integer means. But short of following some VERY strict variable naming conventions, there's no way to do that. I could call it percent, or iPercent, or iPct, or p, or iDontLikeNamingMyVariables. Or heck I decide that I want tenths of a percent but decide floats aren't worthwhile so now my "percentage" can range from 0..1000 and the routine itself will implicitly divide by 10 (possibly by just plugging a decimal into the correct spot while drawing the number on a display -- no "real" division done). No automated routine can ever fill this in. Even a human would have trouble figuring out what I mean if I name my routine something like "PrintP10(int p)". A human would have to analyze the routine itself to see what its doing with the integer, and then possibly go back and analyze its context to see what the integer means if the routine itself wasn't obvious enough.
- Even should this somehow prove tractable, many "bugs" are in the design, not the code. Any sort of automated test routine like this can only find code bugs (which pretty much amount to crash bugs and formatting issues.. a really smart routine might be able to parse out printfs/DB access/etc calls and try to do some heuristic checking to see if %s's are being handled right, or SQL queries are being properly escaped to avoid injections, etc.. But heuristics aren't 100%.) On the other hand if I design a system to send a plain text password over an unsecured link, or write it to a directory that happens to be world-visible via the FTP site, again its not something that can be automatically detected (especially the latter -- your program might have been developed on a system that didn't even have internet access never mind a poorly-configured FTP.)
- UI elements tend to be horribly difficult to test automatically. All you can do is inject some mouse clicks and keyboard events and hope that the OS treats them the same as real mouse/keyboard events. Consider injecting events to click a button. They would probably consist of A) move the mouse over the button and B) fire a click event. Chances are the step A) will be invalid -- it will almost certainly consist of a direct positioning (ie: a cursor jump) whereas a real user would have to move the mouse across the screen. And moving the mouse across the screen may well hit some other control that has an OnEnter or OnLeave event trigger that in some way interferes
nt;
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
I'm wondering how the license issues will fall out on locked-down Android based devices, and that is part of the problem.
(Locked-down and tied-down are slightly different things.)
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
> "The frustrating, jealously guarded secret is that when it comes to actually enabling others to develop secure systems, we deliver far less value than could be expected.'"
The frustrating, jealously guarded secret is that when it comes to actually enabling others to develop secure systems, NOBODY WANTS TO PAY AN EXTRA BUCK, UNTIL THE DAMAGE IS DONE.
The most correct program in existence consists of exactly one instruction:
NO-OP
and it is unfortunately not correct in all contexts.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
You mean the race condition between the marketing department's release schedule and the engineering department's bugzilla?
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
Bosses keep saying, why re-invent the wheel?
If our wheels are triangular and Microsoft keeps selling us on the idea that wheels are supposed to be triangular, then we need more people to tell it like it is.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
You keep harping about the turing model.
What do you suggest to replace it? Magic?
A decision machine is going to behave like a Turing machine.
Period.
Analyzing where and how decisions are made is useful. Getting rid of the decision step itself is not.
Turing is not the problem.
The problem is the real world, and the fact that models are never the real thing, or there would be no reason to build models.
Inventing a new programing model that somehow avoids the Turing bottleneck (instead of postponing it or spreading it out) could solve the problem if you could solve the problem of solving problems without solving them.
The only way to escape entropy is to leave the mortal world.
QED, and if you don't understand why, well, anyway, the Turing model itself is not the problem.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
Bill Gates and Steve Ballmer made the mess, and I'm doing my best not to sit in it.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
if you put a lock on a box and leave the box in the middle of the highway, is the box secure?
I'm inclined less to access control lists (vectors, whatever) and more to ephemeral users (kind of like sandboxes for everything, but not really).
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
Come to think of it, we had less automotive pollution (overall, not in certain specific areas) in the '70s, too.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
I wonder if my sock puppet has mod points.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
it only postpones the problem, as long as the industry itself is pushing impossible deadlines and weighing them down (and fueling them) with impossible feature lists.
Sandboxing is good in theory, but nobody really does it right, yet. The present version is more of a low wall than a speedbump, for now. Today's low walls are tomorrows speedbumps.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
I've read through all the comments, and this is the only sane one that stands out. The principle of least privilege, as I see it, is the idea of letting the user give privileges to a program at run time, and they would chose the least possible set of resources to get the job done.
The main thing is that with cabsec, you NEVER trust a program with the full resources of a user, and thus it never has enough resources to take out your system.
Consider if Outlook were only allowed to talk to a mail server, and a datastore, and use the console IO. It wouldn't be possible for an email to take out anything else, as it would be out of the scope of allowed actions. Everyone could manage profiles for things to automate the normal routine stuff, and use a nice GUI for the tricky bits... saving the settings if the results were favorable.
The big plus of cabsec (CApability Based SECurity) is that it would allow pretty much anyone to manage their own system, and to NEVER worry about virii again.
It can be done, but for many good reasons most users have never heard of it.
On Linux and OSX apps that want to edit non user files either need to be started as root or they won't run.. period. When MS Windows reaches the same point Microsoft will have finally caught up.
Right now I have mission critical accounting software that won't run as anything but administrator and I don't feel like were winning the security war at all.
The principles of secure software are almost the same as bugfree software. No silver bullet -- again.
The same is true on any NT based Windows operating system. Set up a limited user account in Windows XP and try to run software that makes changes to the system...it won't work! Unless you use runas to run the software as an administrative user, it cannot change the system files. The only exception is if they are on a FAT partion (which doesn't support ACL's).
You seriously can't blame Microsoft because the developers of your accounting software chose to do things that require Administrator priviliges. Developers were told to stop doing that when Windows 2000 was released. Microsoft's only fault there is that they didn't put any hard enforcement of the rule until Vista.
As for the accounting software, there may be ways you can adjust the ACL's on the files and registry entries the software uses so that it can run under a regular user context. A lot of software got caught because they were doing stupid things like writing to the local machine registry hive or to data files inside their Program Files subdirectory. Of course, allowing all members of "Users" to change those objects might be another security issue in itself...
The clash of honour calls, to stand when others fall.
Even in shops that I have worked in where there was an attempt at high security at a network level, there are other events that occur for the admins to do their job that undermines said security such as using portable media, shared user IDs. This because security has only been done to the extent that it will cost no more money where a complete infrastructure of servers should have been put in place to allow people to work in the environment; safe staging servers and the like. Furthermore I see less 'security robust' operating systems replacing ones that are more secure because they are easier and cheaper to administer. Developers and admins complain because an operating system like Solaris or AIX are basically nothing but a kernel and therefore require more time and effort compared to a swiss army knife such as Red Hat. Sure, one could strip down a Red Hat install to the bare essentials but again, no one is allowed to take the time. Don't even get me started on the negatives of offshoring.
Companies have never, ever, invested enough in IT. They want servers to be quick, easy, and as cheap as possible. Until companies recognize the level of investment required in hardware and people to make an environment truly secure we will continue to be reactive.
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
Mr. Zalewski lives in his little unsecure world, not understanding the big picture. IBM Power Systems running i5/OS (formerly iSeries and AS/400) keep data and programs in separate memory areas. You cannot execute data as a program unless you go through an IBM compiler. To my knowledge there has never been a virus in the wild on this platform. We don't even need firewalls! This basic concept is not used in any other computer I know of, but surely the patents have expired by now and others can use this concept if they could break free of the PC processor mentality.
But security be damned. There's more money to be made with insecure systems (not just by the scammers but also the "security researchers" and all the other security infrastructure) and until that incentive disappears, we will have "just-in-time" security, which is now becoming "just-a-bit-late; sorry-about-that" security. People are more impressed when you fix their computer than when it runs for years without any viruses or other malware.
If I used a sig over again, would anyone notice?