Slashdot Mirror
The Six Dumbest Ideas in Computer Security
Frater 219 writes "The IT industry spends a huge amount of money on security -- and yet worms, spyware, and other relatively mindless attacks are still able to create massive havoc. Why? Marcus Ranum suggests that we've all been spending far too much time and effort on provably ineffective security measures. It may come as a surprise that anti-virus software, penetration testing, and user education are three of "The Six Dumbest Ideas in Computer Security"."
Why, would you rather I leave the door open to get some light in the basement?
Be relentless!
These people get the crap and then bring it into the cacoon, thus negating the hundreds of thousands of dollars of security infrastructure
What are some of the dumbest security *policies* you've encountered?
I worked for a firm earlier where we had to change our passwords every week where the password had to 1) be exactly 14 characters and 2) be ~60% different to the previous four passwords.
The result was of course that almost every user had their passwords on post-it notes.
To illustrate, ask yourself this question: why do most corporate computer users have permissions on their computer to download and execute arbitrary programs?
Now, it should be noted that even Linux gives the average user this capability. But that needn't be so.
Antivirus programs are a bandaid, not a solution. But most people treat them as a solution, and therein lies the problem.
If you really want to take care of security issues, you have to do so at the foundation.
Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
Yeah, I'm taking all my anti-virus software off the computers right now. I don't know why I ever though it was useful anyway. It's more efficient to deal with the infections as they come in then it is to try to prevent it.
I'm gonna stop using condoms too while I'm at it.
Sometimes my arms bend back.
Woah, he's not talking about Slashdot?
In #4, "Hacking is Cool", he obviously means "cracker." Also, the last part of that section says that security professionals should not know how to crack. Bullshit. If you don't know how exploits are used, how can you block them? How can you write a secure program if you don't know what a buffer overflow is?
I patch PHP to set a constant in the namespace of the script whenever a 'dangerous' function is called (eg: system(), shell_exec, the backtick operator etc., others
If the script is allowed to call the functions, all well and good, it's just logged. If not, the offending IP address is automatically firewalled. I purloined some scripts from the 'net that allow shell-level access to manipulate the firewall.
So, now I had a different problem - the webserver wasn't running anywhere near the privilege needed to alter the firewall, and I didn't want to just run it under sudo in case anyone broke in. I wrote a (java (for bounds-checking), compiled with gcj) setuid program that takes a command string to run, an MD5-like digest of the command, and a set of areas to ignore within the command when checking the digest. The number of areas is encoded into the digest to prevent extra areas being added. If the digest doesn't match, the program doesn't run. This is a bit more secure than 'sudo' because it places controls over exactly what can be in the arguments, as well as what command can be run. It's not possible to append ' | my_hack' as a shell-injection.
So, now if by some as-yet-unknown method, you can write your own scripts on my server (it has happened before, [sigh]), you're immediately firewalled after the first attempt - which typically is *not* 'rm -rf
Well, PHP and SQL injection of course, but the same script is used there - if the variables being sent to the page are odd in some way (typically I look for spaces after urldecoding them as a first step - SQL tends to have spaces in it
What would be nice would be a register within a PHP script that simply identified which functions were called. In the meantime, this works well for me...
Just thought I'd share, because it's similar to what the author is saying regarding only trusting what you know to work, and everything else gets the kick (squeaky wheel-like
Simon
Physicists get Hadrons!
is the permit by default tendency. This is like having a fence that springs out of the ground only when certain people are sensed approaching it. It needs to be up and topped with barbed wire and the only gate needs to be locked until someone is given a key to it. NAT routers are like that. They can only forward traffic when you bother telling it to and until then sit there stupid making you wonder why your new SSH installation won't talk to the outside world.
OTOH, it is a collosal pain in the arse to deny all traffic and only allow what you want because so much code is network aware these days and designed to talk to some place across the net. Then again, it does tell you which apps are communicating in the first place.
On my Windows boxes I use Sygate Personal Firewall to create a specific list of allowed executables and block everything else with a block all entry at the bottom of the fall-through list. No match, no talk. Inbound and out. Combined with NAT it makes for very little traffic reaching my internal network. When I leave my desk for the night and Windows is running, remove a few check marks and save and it only allows the file sharing app to talk and I keep that updated and locked down at all times.
It also can be set to approve or deny execution of code that may have changed since last allow/deny challenge.
That which is not forbidden is not only not compulsory, but probably suspicious.
If my grammar and spelling are off, I am [distracted/tired/careless] (take your pick)
Unless they ban the movie Hackers and eradicate all copies of it everywhere, they're not gonna make hacking uncool...
Don't forget Sneakers, which was way cooler (IMNSHO) than Hackers.
"Alcohol, Tobacco, Firearms, and Explosives" should be a convenience store, not a government agency.
Password must be 10+ characters in length, contain upper and lower case letters, 3 numbers and 2 special characters.
Result:
Users keep their passwords on post-it notes stuck to their monitors.
2) Constant password expiration
Passwords expire every 3 months. New passwords can not resemble old passwords.
Result:
Users keep their passwords on post-it notes stuck to their monitors.
noexec can be easily circumvented. Read here for more information.
/dev/hda7 on /tmp type ext2 (rw,noexec,nosuid,nodev) ./date ./date: Permission denied /lib/ld-linux.so.2 ./date
Relevant example:
alex@joker:/tmp# mount | grep tmp
alex@joker:/tmp#
bash:
alex@joker:/tmp#
Sun Dec 3 17:49:23 CET 2000
1) Default deny instead of default allow. Actually, default deny is just as stupid as default allow, as if you have default deny, people just get sick of being asked if they want to allow something, and end up clicking "yes" on every box they see.
Why on earth would you allow your users to select what is acceptable? I believe his proposition was stating that you as the systems admin should set what people can use, and block everything else, otherwise if users could specify what was allowed, then you're back to square one like you say.
2) Enumerating Badness So you want to write a virus scanner that somehow can recognise viruses without being told which programs are viruses. Modern virus checkers already mostly do this. With spyware it's very hard for a computer to tell the difference between a program you wanted installing and one you didn't. How do you expect it to tell?
Simple, you have a fixed set of programs that are allowed to run, and you don't allow users to install additional programs. Anything not designated as allowed to run therefore gets stopped in its tracks before harm can be done.
3) Penetrate and Patch So you are saying we should write code without bugs and holes? What a great idea that is? why did no-one think of saying that before?
Actually I think his point is that code is being written insecurely when it really could be written securely. Look at how things are now, the buffer overflow is a security flaw that has been known about for quite some time, and there are very easy ways to protect against it, yet buffer overflow exploits are still quite common. The point is we shouldn't be trying to understand the flaw and try to patch it, we should try and understand how the flaw ever came to existing, and fix that!
4) Hacking is cool You think people should learn how to stop hacking and intrusion without learning how existing hacks work? Then you are stupid. Shush.
As I explained in an above post, his point is that time could be better spent learning about the root cause of the security exploits (things like buffer overflows) and how to prevent them, rather than spending the rest of your life trying to guard against the countless flaws that the various programs you'll run may have.
5) Educating Users So you are saying that we have to do security without teaching users how to do it. That just isn't going to work unless you never let users install their own applications or plug-ins. Yes teaching users is hard, but it has to be a vital part.
His point here was that users shouldn't even be able to cause harm in the first place, and if they can, then no amount of education is likely to prevent them from inadvertantly harming others. That said though I do believe users should be educated, but I agree with his point as well.
6) Action is better than Inaction So, after saying the state we are in is rubbish, you now say we shouldn't actually change anything. Eh? Or are you saying "don't try something new without testing it first"? Well thats more than a little obvious.
It should be obvious, but how many companies got burned because they switched to very insecure wireless networks early on?
All up the points he raises are interesting, if idealistic at times. Next time you should try reading better
When users are annoyed by questions they don't understand, support costs go up. Windows users really can't answer questions about whether to allow various TCP connections. Since only programs we approve can be installed on the "users" machine, there is no point in default deny.
Just like currency security doesn't try to identify all the different kinds of forgery, so the idea of "trusted" computing is that all programs are bad except the ones signed directly or indirectly by Microsoft.
To be effective, "trusted" computing must be airtight against workarounds by end users. That is why hardware enforcement is an integral part of the picture. The XBox project has been very effective in eliminating holes in the "trusted" computing hardware, thanks to the many volunteer hackers attacking it.
Currency security experts don't spend time on basement printing presses. They spend time on creating currency features that are expensive to reproduce on a small scale. End-user freedom is not an issue in the "trusted" computing paradigm. We simply want an airtight system that allows *only* Microsoft approved programs to execute, and a hardware enforced way to retroactively delete content when Microsoft makes a "mistake".
We want to ensure that defeating the hardware interlock on our machines requires resources way beyond what an individual or small company can muster. It doesn't matter if organized crime or Chinese corporations have the resources. Their exploits give us justification to tighten the screws on our captive users.
One of the main real selling points of our software is that we aim it at users who don't know or care about computing. They just want to use some applications. If our users had any desire or aptitude to learn about security, they would have defected to that "competitor" that shall not be named. Once we succeed in legally banning un-"trusted" hardware, any talk of user "education" will be banished to dark alleyways.
You say, "never let users install their own applications or plug-ins". Darn tootin. The whole point of "trusted" computing is to prevent users from installing their own applications or plug-ins. That is 99% of the security problem with Windows. If a user doesn't know whether to allow a TCP connection, they certainly have no idea whether some no-name (i.e. non-Microsoft) program is safe to install.
We have 100s of millions of machines running our software in the field. We have a nearly complete monopoly on desktop software. Knee-jerk actions are simply out of the question. The damage done by an insufficiently tested patch is far worse than the damage done by the nastiest malware - because our users will blame it on *us*. (The rebels blame the malware on us, but that is irrelevant.)
No GNU has been Hurd during the making of this comment.
The author may be right that the things he listed are dumb ideas for mission-critical ultra-secure systems. However, he seems to be advocating the five dumbest ideas for usable systems.
.PNG format sent to them by family (where .PNG was not a whitelisted attachment, nor was email from a random gmail account).
The price of Default Deny is loss of flexibility. If it is easy to avoid denial (e.g. automatic addition to a whitelist), it's just Default Permit by another name. If it's really hard, it will keep you from doing everything except that which you already know you want to do--in other words, nothing new, nothing clever, just the same stuff over and over. This would turn computers into the equivalent of a stereo system. They do thsoe narrowly-defined tasks that they were engineered to do, and nothing else.
People are going to occasionally want to do something new. When they do, there are certain things that they almost certainly *don't* want to do. Thus, you enumerate badness to help protect them when they want to use their computer as a flexible general-purpose device.
It's better to have systems that are secure by design. Duh. The point is, though, that even systems that are secure by design are likely to have flaws. If you look for flaws, and fix them, then you have a chance of staying ahead of other people who are looking for flaws to exploit them.
The coolness of hacking has nothing to do with security. Hacking is cool because it demonstrates our ability to manipulate our environment, to do things that are supposed to be impossible through ingenuity. In a factory of mindless corporate drones, hacking is not cool. But if you live in the real world where programs have flaws, there is even a security use for people who enjoy finding ways to use the flaws to accomplish things that the creators didn't intend.
Educating users is ridiculous--his point is that users should't be educated because they should be educated before you hire them. Okay, and how did *they* get educated? What happens if you have to hire real people who are talented but they haven't all gone to this magical security training school? His point *should* have been that there are only some things that can be taught, and that you shouldn't assume you can teach completely counterintuitive behavior. But you might be able to teach someone enough to avoid clicking on strange attachments without deleting photos in
I don't want a secure, useless system. I want a secure, *useful* system. And that means compromises need to be made between security and usability. Reading this article gives very little clue as to how to construct a good balance.
I really hate to sound like an Apple fanboy by asking this, but I do mean it as a serious question and not a troll.
Where does the Macintosh OS fit in to your scheme of things? By all measurements it seems to have been built with user friendliness in mind, however it's also generally regarded as being pretty secure by design also.
Is it secure *only* because it's less popular than Windows? I.e., if it had Windows' marketshare, would it be regarded as insecure? Call me biased, but somehow I don't think it would.
User friendliness versus security is not necessarily a one-to-one tradeoff. It's possible to have something of both, although perhaps at the expense of some third quality (speed, or efficiency perhaps?).
Anyway, I'm not disagreeing with you outright as much as I'm just wondering where some other operating systems fit in on your continuum, if Windows is "user friendly" but insecure and *nix is "secure by design" but not user friendly.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
>> Humans make mistakes, but they also need to correct them. Sloppy code is not acceptable.
Have you ever written code for idiots?
When I'm creating software I have to hide my work in progress from management. By that I mean, show them chunks only. I can never let them see something that looks like an operational product till its' been up and running and tested six ways from Sunday, because if they see a working prototype, they'll try to force me to roll it out as productive immediately. Telling them it's "not done" doesn't work either - I've come it to work and found a demo project distributed as productive. I mean wtf? - Some PHBs just don't get it at all. You tell them its' running against a test database, needs 3 more weeks work and bang, its' out the door. - It's not on fire right now so it must be done, right?
In those circumstances, I don't really give a sh*t if it fails and costs them money, except the blame (and 3 am phone calls) fall to the team that wrote it.
You're %100 right, there is no exuse for buggy code, but there is tonnes of it out there, being used productively that was never really finished. Sometimes it's got less to do with the lazy developers than managers who don't listen.
http://request-header.info