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?

[bryhhh]

The password policy at that firm sucks, but writing passwords on post-it notes isn't such a bad idea. Consider these two different policies:

A. User allowed to use simple passwords that they can easily remember such as 'password', or 'abc123'. This user doesn't have to write their password down to be able to remember it.

B. User with a complex password, but writes it on a post it note because they don't stand a chance in hell of remembering it.

If user B is also requested to take the simple step of placing the post-it note in their purse/wallet, the password instantly becomes many more times secure than the password of user A.

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.

Either stupid or obvious

[Chris_Jefferson]

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.

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?

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?

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.

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.

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.

This is just trolling, crap, and obviousness. Your average slashdot post really.

Re:Either stupid or obvious

[Arathrael]

Your example is bad and you should feel bad.

Actually, I take that back. It's an accurate representation of the article. Which was bad.

The example implies that the only application of 'penetrate and patch' is for idiots to check a design that's so obviously flawed you could simply correct it by thinking about it. And it assumes that if that flaw emerged, the developer would be sufficiently dumb to just fix the flaw as related to the specific test data and not anything else related, like, say, the underlying design.

Which is indeed seemingly what the article says. It basically summarises to 'If you do this in a really stupid way, then this must be a dumb thing to do. Stop being dumb.' There's logic for you. The author of the article actually uses the example of testing for Apache bugs on a system without Apache as justification for the 'penetrate and patch' approach being dumb. You've got to be kidding me. What about on a system with Apache? Would that be dumb?

I mean, I do agree that the 'penetrate and patch' approach is pretty futile if the design is put together and maintained by an idiot. But I'd say it's rendered redundant by the idiocy rather than being intrinsically redundant in itself.

At the other extreme, as the grandparent poster was saying, it's also redundant if you have a perfect design without any bugs and holes. Great. Let's just do that then.

Or, if we want to visit Mister Reality for a moment, we're going to in most cases have a design somewhere inbetween. Security will generally have been considered. But it most likely won't be a perfect design because we're just not capable of it (sidenote: how come users are so dumb they're just not worth educating, but software engineers are capable of perfection? I mean, to paraphrase the article, if educating software engineers was going to work, it would have worked by now...)

Anyway, given the probable failure to reach perfection in design (and the uncertaintly of knowing it even if you did), it might be a good idea, maybe, to actually test the live implementation, and maybe fix any flaws? Or if you wanted to give it a jazzy name, you could call it... penetrate and patch?

Or we could all just aim for perfect designs, assume we succeeded, and bask in the warm glow of our godlike egos. That's not a dumb idea at all.

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.

DailyDave

[tiny69]

There's already been some entertainment over Marcus's article on the DailyDave. Dave Aitel doesn't agree with Marcus.

http://lists.immunitysec.com/pipermail/dailydave/2 005-September/002347.html

Dave's "Exactly 500 word essay on "Why hacking is cool, so that Marcus changes his web site"." http://lists.immunitysec.com/pipermail/dailydave/2 005-September/002366.html

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.

Re: #4) Hacking is Cool

[seabasstin]

very interesting, I am getting it.
your analysis of the Pavlov's dog, raises a number of interesting questions, but definitely support the "Dumbest lists author" in his assertion that their is a significant erasing of boundaries when talking of computer network crime, that makes the criminal completely separate the effects of his crime on REAL people.
This I feel is also a real issue in a Globalized Corporate economy where arbitrary invisible entities are considered equal to citizens in the judiciary of most countries.
thanks for the reference

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.

Re:A much bigger problem

[Jetifi]

Yep, that's because companies spend too much time and money on border security (company firewalls, email filters etc.), while creating SPOF's in trying to minimize maintenence and admin budgets while forgetting that defense in depth is far, far more effective.

Given that users today like to use a variety of tools that use far more ports than just 80 and 25, it's more sensible to have protection at multiple levels: vlan, proxy, mail server, software firewalls, and AV/IDS from top to bottom, updated in as close to real-time as you can get.

The architecture proposed in this article goes to the opposite extreme, eliminating the DMZ and striving to minimize the need for a corporate firewall. I think it goes a little too far, but he's definitely got some good ideas.

(Also, in their defense, the road warriors are normally the salesmen keeping the company afloat :-)

Re:String comparison?

[SetupWeasel]

You expect a user that's writing passwords on post-it notes to be that smart?

Why the hell would writing you password on post-its be a stupid idea? Everywhere I've worked the IT people didn't give a shit about the guy in the next room or cube getting your password. It was the people outside the building that mattered.

You are telling me that you could come up with a unique 14 character password every week and not have to write it down? Listen, I'm a pretty fucking smart guy, and I don't have that ability. With the number of passwords I have to manage these days, I'm lucky to remember where I wrote that one down.

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.

Re:Locking down users

[Anonymous Coward]

I have a job much like your job, I have to keep track of 100's of users and their PC's and make sure they are not infected with viruses and malware, babysit the network, firewall stuff, website maintenance .. blah blah blah... you know the drill.

I have to say ... sorry man but you ARE a network nazi. Sorry. Yea I understand the problem that PHB's and users do not understand the things you have to do, but, you sir, are being a lazy ass.

Before I was promoted to my current position they hired a guy like you. He went around and locked down everyone's PC. He initiated ridiculous policies and installed tyrannical "security" measures all over the place. It was an utter joke. Productivity went to Zero. People just stopped working. They couldn't get anything done.

People hated this guy with a passion that I can not begin to describe. The reason is that they were being treated like idiots by default by some guy who doesn't even begin to understand what it is that THEY need.

What's the point of having security measures so tight that not even the users can use the system? Security measures should be mostly transparent to the end users. Security does not mean cripple the system.

Anyway, eventually this guy become such a terror that he was let go and I took his job. I do what he didn't want to do: babysit the ugly monster. I keep things lax and make sure people have what they need to do their jobs. I talk with people every day and give them what they need to do their work. I get along famously with most of the staff. Nobody said it was supposed to be easy, or fun, but your job is to keep the system useable.

I don't understand the God complex some IT people have.

The Four Dumbest Ideas in One Paragraph.

[Allistair]

I can't decide whether it's obvious or stupid. So, I've come up with my own arbitrary list of dumb ideas directly from the article.

On the surface of things, the idea of "Educating Users" seems less than dumb: education is always good. On the other hand, like "Penetrate and Patch" if it was going to work, it would have worked by now. There have been numerous interesting studies that indicate that a significant percentage of users will trade their password for a candy bar, and the Anna Kournikova worm showed us that nearly 1/2 of humanity will click on anything purporting to contain nude pictures of barely clothed females. If "Educating Users" is the strategy you plan to embark upon, you should expect to have to "patch" your users every week. That's dumb.

I disagree with much of this statement from the writer's "educating users" section. I'm not only for educating users but I am also a big proponent of educating writers.

1. Suggesting that "if it (educating users) was going to work, it would have worked by now" is dumb. This statement is a fallacy of bifurcation -- suggesting that there are only two possible outcomes. Either it works or it doesn't. Of course, this leaves out a very real third possibility: the writer is an addle-minded moron for creating this either/or "test" of effectiveness.
2. Stating that "There have been numerous interesting studies" but failing to cite any of them. I am not familiar with the candy bar studies but I wonder... Do any of these studies look at how many of the same users will trade their password for a candy bar if they have had some security training? And what is the age demographic being studied if candy bars are so appealing? Unless, of course, the candy in question is Snickers -- 'cause Snickers really satifies.
3. Stating that it will be necessary to "patch" users every week. It may not be necessary to "patch" your users every week if you make "Educating Users" part of a larger approach to your computer security program. Don't try to educate your users about everything. Instead, educate them about enough to make them good network citizens. Besides, if you are stripping off all attachments without educating your users, you will have successfully identified one of the "six dumbest things to do to the CEO's email."
4. Writing "nude pictures of barely clothed females." Come on! Are they nude? Are they barely clothed? That is really going to skew that 1/2 of humanity statistic.

Point by point review of the page

[zonestalker]

Allrighty-o let's get into the business...

<quote>The Six Dumbest Ideas in Computer Security</quote>
Why six? Why not five or traditional ten? Only "six" ideas in ComSec area drags us down, huh. Yeah mate keep on dreaming.

<quote>There's lots of innovation going on in security - we're inundated with a steady stream of new stuff and it all sounds like it works just great. </quote>
Actually Marcus we are NOT "inundated with a steady stream of new stuff" and they do NOT "sound like they work just great". Actually,I pray you meant software and hardware protection methods when you mentioned the word "stuff", nothing is new on the western front. We are still using routers, switches, antivirii software and firewall boxes, and software , to protect our machines. Yes you can say "spyware protectors" are new but then they are not new practically they are specialized firewall-antivirus programs that checks only a limited area of the hard disk and network activity. And both are "old" technologies.

<quote>Every couple of months I'm invited to a new computer security conference, or I'm asked to write a foreword for a new computer security book. </quote>
Which ones? There are two books mentioned in your website and only one of them is about computer security, barely... trying to get people using linux is not a ComSec business. Your duty is to secure the network as it is. Whether your employer uses linux or windows is regardless on that matter. Trying to convert a 80 windows machine'd topology to linux is a sure shot to get fired as far as I can see...

<quote>And, thanks to the fact that it's a topic of public concern and a "safe issue" for politicians, we can expect a flood of computer security-related legislation from lawmakers.</quote>
Yeah. We can expect it about p2p'ing and filesharing which is a grey area ethically. And local laws won't affect attackers from overseas. You found a cracker who has successfully cracked into your system from Lebanon. What will you do? Find and get him in USA to get into trial which will cost a LOT to your employee? Politicians are talking about the 'net since the Clinton-Gore election so what is new?

<quote> So: computer security is definitely still a "hot topic." But why are we spending all this time and money and still having problems?</quote>
Yes it is a hot topic but, although it is a rhetorical question let me answer that we are spending all this time and money into ComSec because nothing is fool, or for that matter crack,proof.

<quote>Let me introduce you to the six dumbest ideas in computer security. What are they? They're the anti-good ideas.</quote>
Including educating users... and non-patching... and tagging problems... Anti-good... yeah... *drooling*

<quote>They're the braindamage that makes your $100,000 ASIC-based turbo-stateful packet-mulching firewall transparent to hackers. </quote>
Erm, if one spends that amount of money into a firewall and somehow make it transparent to everyone... sorry "Hackers" I would bet my money that that person had a braindamage before installing that! When considering there are free alternatives on the market...

<quote>Where do anti-good ideas come from? They come from misguided attempts to do the impossible - which is another way of saying "trying to ignore reality."</quote>
Then what are you doing here exactly? What are you trying to tell us? Don't educate users, don't patch the system? Don't know how an attack is made so we can't create a solution to that?? Don't know about you guv, but you are "trying to ignore the reality."!

<quote> Frequently those misguided attempts are sincere efforts by well-meaning people or companies who just don't fully understand the situation, </quote>
like you

<propaganda mode>but other times it's just a bunch of savvy entrepreneurs with a well-marketed piece of junk they're selling to make a fast buck. In either case,

Re:Dumber Article...

[An Onerous Coward]

If you read it as "write perfect code," then yes, the guy is crazy. But I think the article passed through a dumbification filter before it got to your brain. what I think he's really saying is, "Think about the security implications of new features before you add new features."

"What we need is a way to detect that the screensaver is a trojan and warn me that this is a bad thing."

This one makes the Halting Problem look like a walk in the park.

Whitelisting should work fine, in situations where the user isn't able to add to the whitelist at the click of a button. But even if the user can decide for himself whether to run a program, it would be nice if it were simple for the user to decide what privileges the program should have.

I don't see anything wrong with the idea, because there is no reason not to add an antivirus scanner into the mix. But the AV scanner alone is only as good as its latest definitions. Even if they're good enough to catch 99% of the bad stuff, you're still left with the glaring fact that the scanner can only protect against threats it knows about. A whitelist will protect against threats both known and unknown.

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:Dumber Article...

[hattig]

I don't think you get who I am defining as a user in this case.

Not you. Not me.

I'm talking about your average office person that uses Word, Excel, Powerpoint, maybe a couple of other applications. The people that can barely operate a computer beyond what their job entails. People that are the number one cause of the propogation of worms and viruses and spyware because they click Yes on everything that pops up, because it is a computer, and computers are giant brains that know everything. Okay, I exaggerate, but you must get my point?

Mac OS X has Automator. Let them use something like that to automate tasks.

You are a big proponent of sticking all the security at one location, however I believe that security should be everywhere.

You can bypass the noexec mount option by running ldlinux.so directly with the application name.

Re:Dumber Article...

[10101001 10101001]

I'd like to counter your arguments.

One of the points basically comes down to "write perfect code".

I'd say his argument is closer to "don't write in C". Primarily exploits like buffer overflows are a resulting of using C. Now, as you point out, if one wrote perfect code, then using C would be fine. But clearly people don't write perfect code. So, the next best thing is to use a language that is designed to handle a lot of the problems that are experienced in incorrectly using C.

Of course, there's nothing about using Java or another language that makes your system immune from attack. But Java/Lisp/another high level language, design-by-contract, and checks for overflows (or using a language where overflows basically can't occur) would go a long way to turning exploits into loggable DOS attacks. The best way to design well is to use tools geared toward that end. Sadly, C isn't one of them.

His argument that an OS should ask you before running something is also stupid. How many users do you know who would actually read & understand such a question? Never mind actually giving a sensible answer.

Few. But the users he's primarily talking about are those on company workstations/desktops, not home users. In such an environment it makes perfect sense to lock down the system and give the IT department the control on whether a user can run programs. To that end, the user never has to give a sensible answer. They just need to have their IT staff "do the right thing". The fact that no OS seems to support such well isn't a good thing (Linux sort of supports it, but you have to go through hoops to set it up).

Now, what about the home user? The fact is, while most home users are incapable of knowing whether something is "good" or "bad", there's nothing to stop the OS from figuring out if a program was installed properly and only allowing such to run. Further, there's nothing stopping the OS from setting to so it's trivial to block a program from running ever; imagine, for example, being able to easily keep MSN Messenger from loading. The fact is, modern OSs are a long way from allowing the sort of fine-grain control over program behavior. Zonealarm seems a great example of a step in the right direction, allowing independent blocking of in/out network traffic.

Users might know very little of how to do "the right thing", but that doesn't mean the OS can't do a lot on its own. Nor does it mean that the user can't try and succeed a lot of the time. Of course, don't be surprised when you'll have to reenable Java for granny after you disabled it one day because of an annoying web ad but the next can't get a web game to work. Of course, the real answer then is more granular control. And of course, as was stated, the opt-in, not opt-out mentality so that granny never had to disable the web ad in the first place, but instead she's the one who enabled support for the web game.

Why We Should Thank Virus Writers

[Anonymous Coward]

http://www.zone-h.org/en/news/read/id=3287

"Why computer virus writers are useful and why we should thank them."

An Immunologist's view on computer hacking.

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:Dumbest Ideas in Corporate Email Security

[Neop2Lemus]

At one company I worked at
when the 3 month period came,
you changed your password thrice
and kept it just the same.

Re:OK.

[Sancho]

Agreed.

Further, points 1 and 2 are essentially the same things, just reworded.

Point 4 is somewhat mistitled. I do think learning the basics of how exploits work is important to creating sturdier code. Otherwise, you'd just write stuff that's vulnerable to buffer overflow constantly.

Point 5... Where do I begin? The problem is NOT self-correcting. I work for a university, and every year we get students asking us how some bank got their university e-mail address and "Should I respond to them?" For every one that does that, probably 10 actually respond. He also seems to think that there is a technical solution to "attachments and phishing" but never explains the technical solution to phishing. Presumably it is to only allow e-mails from a whitelist, given his default-deny ideas. Well frankly, that isn't going to work for most people.

Point 6 I agree with to an extent. The problem comes when everyone adopts this strategy--no innovation actually gets implemented! Also, technologies that are developed to fill a need often cannot be "waited on" in the manner that he describes. Also, on the patch-level, this may not be workable either. If you have a critical vulnerability, you can't afford to wait until everyone else has tried the patch. You definitely want to test it before deploying it, but that's along a different line of thought.

Overall, some interesting ideas, but as you say, many aren't really security ideas. They're SOP for lots of companies, though.

Re:Joke?

[JesseMcDonald]

That would be more practical if users could create their own limited UIDs. As it is, the system adminitrator would have to manage a number of limited, e-mail-only UIDs (one for each user), or enable some kind of sudo or "run as" procedure (without authentication) with a common UID. Either way, there are still system services that could not be protected in this manner, and the mechanism would be system-specific and thus difficult to design into an e-mail client. A chroot-jail design would at least protect the user's files, but requires root priviledges to work.

One way of "jailing" attachments would be to run them inside a User-Mode Linux process, with no access real network devices or the host filesystem. AFAIK, that would prevent the attachment from altering the system in any way, and could be automated without access to the root account. Of course, this is not all that different from limiting (executable) attachments to Java programs and running them within a limited JVM...

Re:Dumber Article...

[einhverfr]

I'm talking about your average office person that uses Word, Excel, Powerpoint, maybe a couple of other applications. The people that can barely operate a computer beyond what their job entails. People that are the number one cause of the propogation of worms and viruses and spyware because they click Yes on everything that pops up, because it is a computer, and computers are giant brains that know everything. Okay, I exaggerate, but you must get my point?

Ok, then substitute macros in office documents for Perl/Bash scripts.

The best goal of security, IMO, is to prevent what can be prevented without impinging on operations and contain the rest of the damage. It is not that you *cannot* prevent the occasional incident, but rather that preventing the occasional incident is far more costly in some cases (viruses on Windows for example) than managing the damage.

Sure Linux is better. In that case we can substitute Python macros in Gnumeric....

But you still have some of the issues. Unless your system focuses heavily on damage containment, the security will be brittle and when someone does succeed in breaking in the damage will be very serious. This is what the article misses BTW (and what is generally wrong with the way people use firewalls).

Re:zerg

[Anonymous Coward]

3. Wicked Musical Score.

4. A change from the mundane command line we all know, to flying physics equations and absurdly designed server rooms that look incredibly awesome to the point the information stored requires 1 000 back ups as redundancy to the bolts of electricity arc'ing between the towers...

5. Stylishishness, who wouldn't want to hang out in Cyberrella (the hacker club) where everyone is somehow or other l33t and yet they all are social enough to go out of their houses, it's the geek dream, a haven to call their own that's actually desirable.

6. Did I mention Angelina Jolie has sex (implied) with a geek? You basically add every geek on the planet (even the female ones, because EVERYONE would sleep with Angelina given the chance) to your fan club just with that alone.

7. Angelina's breasts

Re:A much bigger problem

[Creepy Crawler]

Comments by people (like you) who post worthwile content is why I'm still here.

It really is neat-o when I read about personal stories about hell-desk or being that "luzer" (when we know you arent... luzers dont even know what ssh is).

Thanks. (no, this isnt satire, I really am pleased that slashdot can still generate what it originally did years ago.. real people commenting about their problems.)

Re: "skip the testing, it looks fine"

[seabasstin]

I am so with you!
I worked on an IM project where the demo showed the send process of the IM transaction.

The business manager saw this and in his ecstasy of being able to launch early said put it on the production server ASAP, the production manager panicked and told him we needed a week to tie loose ends; and then told us we needed to get done the project done a month ahead of schedule because she couldn't get herself to remind the business manager that IM is 2-way communication process.
So when we didn't make it, and it was declared OUR failure (the production team) and we didn't really care since being creatives in our heart of hearts we knew that it was only because of business for being STUPID.

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.

Re:Here it comes...

[Tassach]

You fail reading comprehension.

Postfix was designed so that failures are compartmentalized. No one ever said it was immune from failure -- just that the damage from an eventual failure would be contained.

The article you cite shows a bug which allowed a LOCAL USER to delete other people's mail. While this is indeed a flaw, the damage is completely contained to the mail system -- it is not remotely exploitable, does not allow privilige escalation, does not compromise root, and is trivially solved by not granting users shell accounts on the mail server.

Compare this bug to the numerous Sendmail bugs which allowed a REMOTE user to gain ROOT priviliges on the box. There is a HUGE difference in severity between a limited local denial of service attack and a remote root exploit.

Congradulations on proving the point you were trying to refute.