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"."

Comments

Dumbest security policies?

[Anonymous Coward]

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.

Re:Dumbest security policies?

[nunchux]

Five years or so ago I did freelance work for a short-lived "online greeting card company" (shut up, I know.) Basically I'd go to a control panel to get an order, adjust the proof in the Flash template and send it back. I had absolutely no access to any other part of the site, the databases, not even the customer's contact info (much less credit card #'s.)

I still had to change my password every two weeks, with conditions similar to what you describe-- IIRC ten or more characters, mix of numbers and letters, had to be substantially different than the one before. I eventually a system down for remembering what it was, but I'll be the first to admit I was using my Mac's "stickies" to keep track of the password for the first six months. Considering they were dealing primarliy with graphic designers, not programmers, I can only imagine what some of the other employees were doing. Since they also weren't the easiest employers to deal with, I can only imagine that the lack of give-a-shit factor kept many employees from trying to hard to keep that ever-changing password a closely guarded secret. Let me stress that the damage that could be done if my password was compromised was completely negligible-- maybe someone could have inserted a dirty message in a greeting card, but it still had another check to go through before it went online!

Basically my point is, there's a point where security for security's sake is an annoyance. I'm certainly not an expert in these matters but IMO making low-level users go through hoops is just going to foster ill will, better to lock down their privileges in the first place and make sure no damage could be done if that account was compromised. Frequently changing admin passwords is of course another matter, but that's part of the responsibility that comes with the job.

Re:Dumbest security policies?

[Timbotronic]

I taught a programming course at an Australian government department where they had a "no unauthorised software" policy. Unfortunately, the language I was teaching wasn't on their list, so they wouldn't allow me to install it on the training room computers that weren't even connected to the office network!

Needless to say the course was less than effective and illustrates what should be the seventh dumbest idea - "Security policies have no effect on productivity". The amount of grief caused to companies by rigid, pedantic security nazis is astounding.

Poor Article

[hoka]

The article really fails to address any real issue with security. What the article really read like was something more along the lines of, "Six Things Dumb Management Sometimes Do In Relations to Computer Security". The real problem with technical computer security is the poor quality of software (software designed without security, or without enough security in mind), and the general lack of general system protection (NoExec memory, Stack Smashing/Active Bounds Checking, Targetted/Strict ACLs, etc). The damage worms/viruses/hackers can cause on a much stricter system is really far less than a normal system, if the penetration can even be achieved in the first place.

On my webservers...

[Space cowboy]

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 :-). The webserver also prepends (php.ini: auto_prepend_file) a PHP file that registers a shutdown-hook. Those constants can then be examined in the shutdown hook code to see if any of the dangerous functions have been called, and if so, check to see if *this* script is allowed to call them.

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 /' :-) Perl and Python are both unavailable to the webserver uid, so PHP is pretty much the obvious attack vector.

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 :-), then the firewall is called on again. It's all logged, and the site-owners get to see when and why the IP is blocked. Sometimes it's even highlighted problems in their HTML :-)

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

DRM

[Kelerain]

That nice list, and they didn't include Digital Rights Management? The link is to a Cory Doctorow talk that explains and argues these points (it was for a talk he gave to microsoft)

1. That DRM systems don't work
2. That DRM systems are bad for society
3. That DRM systems are bad for business
4. That DRM systems are bad for artists
5. That DRM is a bad business-move for MSFT

A very good read if you are in the position of explaining this to someone in a position to mandate DRM.

One good point this article makes

[suitepotato]

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.

Re:zerg

[Kymermosst]

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.

Re:Real security has to be build into the foundati

[Alex Brasetvik]

noexec can be easily circumvented. Read here for more information.

Relevant example:


              alex@joker:/tmp# mount | grep tmp /dev/hda7 on /tmp type ext2 (rw,noexec,nosuid,nodev)
              alex@joker:/tmp# ./date
              bash: ./date: Permission denied
              alex@joker:/tmp# /lib/ld-linux.so.2 ./date
              Sun Dec 3 17:49:23 CET 2000

#4) Hacking is Cool

[Quirk]

"Hidden in Parker's observation is the awareness that hacking is a social problem."

Crime as a problem of context is studied in Gregory Bateson's seminal book Mind and Nature: A Necessary Unity. Bateson addresses two flaws in our court system. One is to treat a crime as something isolated and somehow measurable in penal terms. Taking a crime out of context, i.e., the makeup of the criminal, is blind to the forces that generate criminal actions.

Bateson speaks of (crime) "...as not the name of an act or action; it is the name of a frame for action. ...( he suggests)... we look for integrations of behavior which a) do not define the actions which are their content; and b) do not obey ordinary reinforcement rules." In this context he suggests play, crime and exploration fit the description. As long as we are only able to punish according to some sort of arbitrary eye for an eye method of bookkeeping we will be unable to root out crime.

Bateson's second criticism of our judicial system addresses it's adversarial nature. He writes... "adversarial systems are notoriously subject to irrelevant determinism. The relative 'strength' of the adversaries is likely to rule the decision regardless of the relative strength of their arguments. Bateson's second

He further goes on to a brilliant analysis of the Pavlovian study of dogs in terms of the dog's view of the context; and, how the dog's context is violated when the dog's view of a "game" of distinction is morphed into a game of guessing without there being any markers to tell the dog the context of the game has been changed. This switch in context drives neurotic and violent behaviour in the dog. I suspect much anti social behaviour is driven by the criminal's inability to read society's context markers.

The Final Solution

[rufusdufus]

There is a way to fix security problems on end-user machines completely.
The solution is to keep the operating system and applications on read-only media. The end-user operating system of the future should be designed around this idea, and they should reboot from readonly media on a regular basis, this way viruses cannot spread and worms cannot get a foothold.
Its doable. Its feasable. Its the future, once engineers really decide to solve the problem.

Re:A much bigger problem

[Johnny Mnemonic]

We give our users Mac laptops, which largely corrects this issue.

Re:Dumber Article...

[hattig]

Whilst I agree that his 'write perfect code' is a bit far reaching, he did point out that decent design beforehand can save a lot of time down the road. Yes, this should be common software engineering methodology, but I'm sure we all know of times when there's a deadline, the boss is angsty and you've got to get something working to keep your job, and a decent design document isn't what he wants to see.

If we limit the issue down to a corporate network, then refusing to run that infested screensaver because it isn't on the list of {Word, Excel, Outlook, Powerpoint, ...} would probably save an awful lot of hassle in the long run - well, apart from trojans, so you'd probably have to only execute applications with certain hashes rather than names. If the corporate IT infrastructure was well designed (hah!) at all levels then there would be far fewer issues. On the other hand, take Microsoft software - you need to run it in your corporation, yet you have no control over it.

I bet someone could come up with a Linux distribution that had a database of 'approved' applications (e.g., application name, application path, application MD5) - basically all applications that come on the install - and had a modified kernel that checked that database whenever starting a new process. Hell, it'd make an interesting programming project. In fact, this is something that I would see something like OpenBSD implementing first. You'd also have to do the same for library files of course, and scripts would be an interesting problem - you can run bash or perl for example, but if the script then does unlink on your filesystem because it is bad... you could limit it to only allowing the scripting language to access approved script files (yet another database, and each scripting language would need modification to use this database). As an alternative, possibly the filesystem itself could manage the entire scheme - you can't run something the filesystem refuses to load!

Of course, in the end with these more positive methods is that it still only takes one bad thing to get past the plethora of security systems you've set up.

Locking down users

[slashflood]

I was working as an IT Manager for a mid-sized company for a while. The main problem with "locking down users" is, that nowadays there is no respect for IT Administrators anymore. Especially in small/mid-sized companies, where every single employee goes directly to his/her boss or even worse to the CEO just to complain about their "inability to work", because of the locked down computer. "The bad admin locked down the computer and I can't work anymore!". Sure, the PHB, CEO, HR won't understand the difference between user/admin rights.

I have a pretty strong personality and a thick skin, but after a while, I gave up. Even brand-new interns complained about the situation that they were not able to install their "favourite software" or about the blocked ports at the corporate firewall.

After a while, the HR manager came to me and said, that in four years, half of the employees complained about me. Whenever I tried to change something (firewall, user rights, ...), there were another ten or twenty complains.

All of the users are working as administrators on their computers at home - I know that, because most of them told me about the troubles they have with spyware and viruses, but they would never accept to have lower permissions at work. The common sense is, that the computer at work is actually theirs.

The same with company laptops. Everyone connects it at insecure networks at home, friends, hotel rooms, other companies and so on and after a business trip, you have to either reinstall the machine or remove spyware/malware.

It's just the lack of understanding, the habit to always work with admin rights at home and the lack of respect for the job of an IT administrator/manager.

Re:Locking down users

[slashflood]

power-tripping network Nazis

See? You're the best example. I/We am/are talking about account restrictions for average users (no admin access) in business environments and you're calling me "power tripping network Nazi". That's exactyl what I mean. At work, it's not your computer and not your responsibility when something really bad happens.

Just go on with your administrator account at home.

Well said

[X.25]

Really good points.

I worked in "security research" field for 10 years. I loved it.

Then companies got involved, certifications/courses/books appeared, pentesting became a business...

I moved to another field, for the very reasons MJR explained in his editorial.

Everyone wanted to be "secure", but noone wanted to invest time or brains in order to achieve that goal.

In 4 years of pentesting (and I'm talking about BIG players and companies with bright people, big budgets), I have only ONCE seen a company that actually took SERIOUS measures in order to improve its' security. I'm not talking about adding another layer of firewalls or installing new toys, but actually redesigning their security infrastructure/thinking.

All the others wanted signed paper which says "You are secure now".

I ended up pointing all of them to MJR's Ultimate Firewall

Re:Zone Alarm

[Elminst]

A gret program yes... but (L)users don't want to be bothered to THINK about anything.

They won't read the box that comes up. they'll mindlessly click "Allow" even if the message said "This program would like to kill your wife and rape your dog. Would you like to allow it?"**

Whatever it takes so they can get on teh intarweb!!1

**Just like not reading EULA's. A while back company (don't remember who) made a EULA that actually said you get money if you call them. Several THOUSAND people installed the program before one guy actually called.

Re:Joke?

[Kadin2048]

No, at least not by my definition.

On a standard Mac OS X box (not sure about Server), the root user isn't even enabled by default. You need to go pretty deep into the preferences in order to enable it.

The first user you create during the install process is an "Administrator," which means you can 'sudo -s' on the commandline and become root temporarily, but only by re-authenticating. I'm not sure if that meets your criteria for 'root-like entity,' but it seems a pretty good compromise to me.

Anything you run through the GUI (and anything you run through the CLI unless you specifically sudo and become root) executes as a non-root user. So email attachments, etc., cannot execute as root unless the user takes the very unlikely steps of enabling the root user, and then logging in as it.

There were a few privilege escalation bugs in past versions of the OS which allowed an Administrator to become root without properly authenticating again after login, but they were in early versions and I haven't heard of any recently.

Re:A much bigger problem

[MightyYar]

I'm a luzer as well, and I frankly find IT's antics pretty entertaining. They have a mixed environment of Win95-WinXP running on everything from crap 90MHz machines up through the latest-and-greatest.

My first frustration with them started when they put up the internet content filter. This I had to bypass by turning on my apache proxy at home and accessing the internet through my home machine (using ssh, of course). The local helpdesk guy just rolled his eyes at me when I showed him playboy.com. I wasn't just being a pain, though - they had the filter tuned so tightly that even some of our vendor websites were filtered.

The next thing they did was run this horrid agent via the login script that lets them do whatever they want. On the surface, it seemed okay because they were just using it to make sure your machine was patched and running the latest anti-virus. However, it seemed to crash or seriously effect the performance of most machines that were still running 95 or 98. Their solution? Put 2000 on all of those machines. Ever run 2000 on a 200 MHz machine with 32-64MB of RAM with Norton running? Unusable. So, I figured out that you could easily trip up their startup script by strategically placing a single text file. The IT guys know this and leave me alone, and in fact refer people to me (with a wink and nod) when they have this problem. :)

Password management is a disaster. If you use Outlook or webmail, occasionally you might get a warning that your password will expire in n days. One of the options is to change your password. Almost everyone does. Uh-oh, now you can't log in to the network... why? I don't pretend to know. All I know is that you must make the password change when you first log in to windows and never when prompted after login. I'd ridicule the people that haven't grasped this - but really, they are just following directions, aren't they?

What is next? I don't know, but there is a reason that us Luzers find the IT management to be an obstacle rather than a help.

Re:A Fundamental Linux Security Flaw

[sbryant]

b) packages should have a list of certified sites for their dependencies. OR, there should be an https repository for ALL packages.

You appear to be using SuSE, yet you say you have to go hunting around for packages. This doesn't make sense.

If you use YaST to install packages, you can do so from one of the official mirrors. These contain all of the dependencies, so you don't need to go hunting. I've got the latest KDevelop, and everything it needed was installed automatically, so I'm wondering what on earth you did to have problems. The machine here has KDevelop 3.2.2 on KDE 3.4.2b, all installed via YaST with SuSE's own packages, and no googling for anything.

Furthermore, SuSE do appear to sign their packages. I'm not sure when this is checked though, so it may or may not be OK to rely on that. Using https for transfers won't really change anything; it wouyld stop eavesdroppers, but I don't think anyone is interested on eavesdropping on transfers of publicly available packages.

Your point is otherwise valid, and installing random packages from random/untrusted locations is an accident waiting to happen. Major distributions, however, do take steps to ensure that their packages are safe. Any distribution which provides a package which is dependent on an external package (ie: not provided by that distribution) is providing you with a bug, and it should be reported as such.

-- Steve

Re:Joke?

[tengwar]

Yes. And I wish people would realise this!

You don't get a root login by default, but any user in the admin group has rw privileges in the Applications directory. If, for the sake of argument, you replace some common application such as the Safari web browser with a trojan subsitute, can either run with the privs of any user who starts it. If you replace an app which normally requests authentication to run as root, you can get full privileges by getting the user to enter their password exactly as they are expecting to do. Although the default user is not the Unix root, this hole means that there is little difference between the security of Windows and Mac.

There is an easy fix: create an account which has admin privileges, then remove these privileges from your normal account. This works almost as easily as the default installation. For a few operations (such as dragging an app into the Applications folder) you will be asked for the user name and password of an administrator, and for these you supply the details of the new admin account that you created. There really is no other down-side that I've come across in running MacOSX like this (unlike using a non-admin user in Windows).

Re:A much bigger problem

[hey!]

I'm a luzer as well, and I frankly find IT's antics pretty entertaining. They have a mixed environment of Win95-WinXP running on everything from crap 90MHz machines up through the latest-and-greatest.

[snip]

Their solution? Put 2000 on all of those machines. Ever run 2000 on a 200 MHz machine with 32-64MB of RAM with Norton running?


Well, if you read between the lines here, it's clear that at least one reason that your IT department does stupid things is because there isn't a proper capital budget for replacing old machines. In fact I'd bet they don't have a proper operating budget either. It's typical enough: not enough resources to prevent problems, barely enough resources to mount a pantomime of a response to them when they arise. The only thing you'd need to get a perfect trifecta of dysfunctional management is a culture of scapegoating masquerading as "accountability".

The typical game plan:

(1) Willful ignorance
(2) Wishful thinking
(3) Make a show of responding
(4) Look for somebody to blame.

IT is overhead, and overhead is the devil when you run a company. That means in a well run company you seldom can expect everything you might wish for. But you can't just wish overhead away: you have to be smart enough to know when spending less on one piece of overhead means you spend more in ten other plances. Sounds like your senior management fails this test.