Re: Hacking: As American as Apple Cider

["Marcus J. Ranum" <mjr () ranum com>]

> Kyle Quest Kyle.Quest at networkengines.com writes:
> Marcus is slowly loosing it... 
> He's trying to build this utopia in his mind
> and the more its complete the further he
> gets from reality... 

        Thanks for the implied compliment that I, at some point, "had it"
in order to "lose it" - slowly or otherwise. :)

        You raise a really interesting point regarding my apparent
utopianism!! Computer security is a field that _demands_ utopianism
because, by its nature, it's a zero sum game. If the bad guys win, I lose,
and vice-versa. If the bad guys find _one_ hole, they win - it's a game of
absolutes, a game of 100%, a game for utopians.

        What's the alternative? Embrace mediocrity? Run Windows on
your mission critical servers, let your sales reps all use Outlook, run
your firewall with a "Default Permit" rule, keep your patches up-to-date
and shrug and say, "well, everyone ELSE sucks TOO" when you wake
up one morning and discover that you suck? Maybe you're comfortable
with that, but I am not!!

        As far as getting "further from reality" - I doubt you'll find a computer
security practitioner who is more grounded in reality than I am. I've been
looking at that reality for a very long time, and have, pretty consistently,
said "it sucks." I think if you accused me of being a "reaction to reality"
I wouldn't argue with you. :) But I've always been a hard-liner and have
pretty much not budged from that view since 1989. Perhaps the industry
has left me behind. As I see it, the industry has embarked on a massive
program of self-deception, in which clueless managers buy garbage
"low carb" security systems that don't actually work - in order to convince
themselves that they're trying. But they aren't trying. They just want to
appear to be trying. Because that's easier than actually trying.

> He starts with the whole "white listing"
> approach. He seems so convinced that it's
> the silver bullet...

Did you actually read my article before you jumped for the keyboard, or
are you reacting to, perhaps, a slashdot summary? I'm asking in all
innocence because I do not understand your reaction.

I said that "enumerating badness" was a dumb idea. I said that "enumerating
goodness" was a smart idea. I did NOT say it's "the silver bullet"  If you're
going to try to trash all over my ideas on a mailing list, don't paraphrase
them inaccurately and trash all over your paraphrase. That's cheap and I
know you're better than that.

> It would be great
> if it was true, but it's not. It's a great
> approach... and it could be the idea
> we should strive to achieve, but it's
> not achievable... for a number of reasons.

Again, in my article I didn't hold "Enumerating Goodness" up to be
some kind of holy ideal. It's just better than "Enumerating Badness."
I've been amazed at how few "security experts" seem to understand
this. For example, on Schneier's blog, someone was hopping up and
down that "Enumerating Goodness doesn't work if you have a web site
as big as Amazon.Com" -- well, sure, it doesn't -- if your website was
not designed with that as a goal to begin with.

Put differently - it's harder to get your head out of your ass than it is
to avoid putting it there in the first place.

Real example: I did a thing for an Ecommerce site where I managed,
after considerable back-and-forth to talk them into just putting a
prefix of
/transact/
in front of all the URLs that had anything to do with a transaction.
Suddenly they were able to put code (not that anyone writes code anymore)
in their CGI to do the equivalent of:
if(strncmp(url,"http://www.bank.com/transact/",30)) {
        // 404
Is it perfect? Hell no. Does it knock down everything except targeted attacks
for the cost of one call to strcmp? Hell yes. What's hard about that??

So you can extend the idea a bit farther. If you tell me that "All URLS look
like:"
http://www.bank.com/images/.*\.gif
http://www.bank.com/images/.\.jpg
http://www.bank.com/transact/jsessionid=[0-9A-Z]{12}
..or whatever - is that valuable? Hell yes. You can stick a copy of Squid
cache in front of your site and make a whole lotta rosie disappear in a
heartbeat. Then you make the stuff that matches nothing go to a 404
server and look at the 404 server logs every so often and see if something
looks weird.

Are you saying that because something's not a 'silver bullet' that it's
a bad idea?? Because that's not very good thinking. I'm not talking about
something that's world-shakingly hard, here.

Let's try this another way. Instead of doing what I'm talking about, why
not follow the "traditional" approach:
10 set up Apache (or whatever)
20 monitor bugtraq (or whatever)
30 whenthere's a new vuln, *panic* and rush to the office to fix it
40 add a rule to your web proxy/loadbalancer/firewall/deep packet inspection
        doo-doo to prevent the URL that matches the worm you just heard about
GOTO 10

"Silver bullet"??? That's not even a "bullet"

> First of all, systems would be impractical
> and unusable.

WOW! How can you assert that? That's how computers WORKED
until relatively recently!!! One did not simply go onto a mainframe and
install an app without permission, and have it be available and runnable
for the whole world. "Impractical" and "unusable" are hard properties
to define but certainly it's a question of degree, isn't it?

> If you have an OS module
> or an AV that blocked everything that's
> not known to be good what would happen
> a person bought a software that the AV
> or the OS module didn't know about?

Oh, come on. Do I have to do all your thinking for you? The
purpose of my article was to stimulate thinking, not stimulate
knee-jerking "it cannot be done" reactions.

Let's fantasize for a second. First off, forget AV. You don't
need AV. AV is a side-effect of dumb "Default Permit" thinking.
So let's suppose instead we have a trustworthy application that
comes with the O/S. Its purpose is to authorize other apps to
become runnable on the O/S. Let's call it the "Authorizer" OK?
And the Authorizer won't authorize anything new to run until
it asks you "let this thing run? (Yes/No  Always-yes/Always-no)"
And every piece of software that has an auto-install utility
needs to be smart enough to call the Authorizer and so you're
sitting there going, "wow. I just installed photoshop and now
Authorizer wants to know if I want to run
c:\mycrap\Adobe\PhotoShop
Hmmmm... OK"

Before you throw more rocks at the idea, I should mention
that this is _exactly_ how the first Antivirus product Peter
Tippett wrote worked (it later became Norton Antivirus) - but
users weren't comfortable with it because they preferred to
"Enumerate Badness" because there wasn't that much
badness out there, at that time.

I think you're being ridiculous when you consider how
relatively effective "policy engineering tools" like Zone Alarm
have proven to be. My 72-year-old mother was able to
build a fairly effective firewall policy using Zone Alarm. And
she was born around the same time as people started
building computers. It's disingenious at best, and stupid at
worst.

You talk about annoying? Annoying is whenever I download
my Email from my POP server and my antivirus software
pesters me over and over "LOOK! there's a VIRUS in
this attachment! I CLOBBERED IT FOR YOU!" - as if I care.
Again, if you want to talk "real world" - I live this stuff just
like you do. I'm just not sitting back accepting mediocrity
and making excuses for it.

> It
> wouldn't work, right. It's not very likely
> that users would put up with that.

They put up with ZoneAlarm. They put up with AV alarms.
Hell, they put up with Outlook and IE. If they'll put up with
Windows Update they will put up with *ANYTHING*

> Even if
> we look at the application white listing
> techniques used by the current host security
> software, what's the story? Well, we have
> an average user who gets this pop up asking
> if he/she wants to allow application xyz
> to run. In over 99% of the time the user 
> says yes...

Can you substantiate that, or did you just pick that
number out of thin air? (If the latter, maybe you can get
a job at Gartner!)   Folks I've talked to at Cisco and
Zone/Checkpoint say it's not that bad - it's still bad
but anecdotally it's closer to 30%. I believe that a lot
of the reason it's so high is because of the terrible
pervasiveness of the culture of "Default Permit" and
"Enumerating Badness" which I am trying to change
with my own futile little thrashings...

> It's somewhat similar if we look at network 
> based security mechanisms. There are times
> when white listing works, but there are many
> times when it doesn't.

Sure! I didn't say it was a perfect solution!!

> Let's say you have
> a service provider that has who knows how
> many customers. Do you think they'd be
> able to get information about every single
> web, ftp, etc server to create a "Default Deny"
> policy? The task would be slightly easier
> if there was no dynamically generated
> content, but what if there was? 

"Default deny" isn't going to work for a service
provider. I never said it would. I never said it
was a "Silver bullet."   Boy, you sure aren't
playing fair - you're attacking a position I never
took and claiming I'm "losing it" because the
position I never took isn't good. I bet you were
the ace of your high school debating team, huh?

> I'm amazed how naive Marcus is when he writes:
>
> "Now, your typical IT executive, when I discuss 
> this concept with him or her, will stand up and 
> say something like, "That sounds great, but our 
> enterprise network is really complicated. Knowing 
> about all the different apps that we rely on would 
> be impossible! What you're saying sounds reasonable 
> until you think about it and realize how absurd 
> it is!" To which I respond, "What about the title 
> 'Chief Technology Officer' are you earning if you 
> don't know what your systems are running and/or 
> being used for?""
>
> Let's say we have a large financial company
> that has custom apps build by contractors,
> third-party vendors, or even internal staff.

OK... You have a large financial company, that
has custom apps built that they don't understand,
which work in ways that they don't understand? Is
that what you're saying? So they've spent all
this money on stuff they don't understand...

> Does he really believe that a top IT exec will
> know that a biz app built 5 years ago before he
> even joined the company uses a whole bunch of named pipes 
> and dynamic MSRPC services.

Of COURSE not. But it sure shocks the hell out of them
if you talk to them like that (and I do!).  Because they
are the guys writing the checks (metaphorically) for this
disaster. And if you can get them to understand that
that is what they are building - a disaster - they will
start asking questions. Like they'll go to their developers
and ask if this stuff is being thrown together or if it's
being designed in accordance with any kind of sane
process or not. And they'll be horrified if they learn the
truth. And then they MIGHT just start organizing things.

What are you saying? That Marcus is crazy because
he thinks businesses should know how their networks work
and how they are being used? Is that it? I know they
don't - I'm not, as you accuse me of being, naive. But if you
sit back and accept mediocrity you're really not helping
at all. Should we tell those IT execs, "HEY! Have your
coders write whatever crap they want! Have them ignore
good design! Have them add or delete rules from the
core firewalls with no oversight! Better yet, have some
contractor who has no stake in getting the job done
right do it! What are you, F-ing retarded!?"

> And if he is aware
> of the nature of this biz app network traffic,
> how would he be able to deploy a "Default Deny"
> system without knowing the low level details,
> which are probably known only to a couple of
> developers who are long gone?

So are you saying "Because Marcus' suggestions
do not retroactively cure past mistakes, they are
no good?"

Do you understand that past mistakes are done and
are not fixable? They can only either be lived-with
or redone. _I_ didn't make corporate IT's past mistakes.
In fact, I suggested (a long time ago) how to avoid
them. They got made anyhow. That's not my problem,
or my fault, and - frankly - I'm not interested in fixing
them because I don't think it can be done.

> All these things show that Marcus built himself
> a utopia where people are perfect... where they don't
> make mistakes... and where software is built with
> no bugs in them. It would be nice if it was true,
> but we all know we are not even close.

Where in the heck did I say people are perfect and
don't make mistakes??!?!?!?!?!  If I thought that for
even a second, you've certainly done enough to cure
me!

So what are you saying? Because people make mistakes
we shouldn't even TRY to get it right? Because people
make mistakes we should just roll over and give up?
Because people make mistakes, you, Kyle Quest
have personally given us permission to just say,
"Awwwww, f*ck it!" about computer security???! Is that it?

[OK, there I was playing a trick from your book. Putting
a ridiculous statement in your mouth, as you did to me
earlier, and then crapping all over it. Sucks, doesn't it?
I'll stop now because it's cheating and it's cheap fun.]

> Now with his "Hacking is Cool" dumb idea he again
> uses this naive black and white... bad and good
> approach... oversimplifying the hacking and security
> research phenomenon we are experiencing right now.

It's a phenomenon I've been tracking since its
beginning. Oversimplifying it is not something I am
trying to do - I've written and talked about it I don't know
how many times (too many) in the last 12 years.
Anyhow... It's a nuanced and subtle issue and it's
not one I am trying to dismiss lightly. If you want a
more detailed series of arguments about why I think
vulnerability disclosure and so forth is bad, the article
you're reacting to isn't it. I'd suggest you go back to my
CSI 1998 keynote or some of my writings in USENIX
;Login: from around 2000 when I was doing a regular
column there.

> He presents hacking and security research in general
> as simply finding exploits and running them, which
> he implies in this quote: 
>
> "teaching yourself how to hack is also part of 
> the "Hacking is Cool" dumb idea. Think about it 
> for a couple of minutes: teaching yourself 
> a bunch of exploits and how to use them...".

Note I said _part_? I do _not_ present hacking and
security research in general in such simplistic terms. 

> "Wouldn't it be more sensible to learn how to design 
> security systems that are hack-proof than to learn 
> how to identify security systems that are dumb?"
>
> It sure would... but that's not commercially
> possible.

Aha! There. You've finally said something I can
agree with!!! :)  Can we be friends, now?

> Products of reasonable complexity 
> would take too long to make and would be
> prohibitively expensive.

So, a piece of freeware like Qmail is prohibitively expensive
compared to a piece of freeware like sendmail?? No, wait,
I got that wrong... An operating system that pays attention
to security design issues like OpenBSD is going to be
prohibitively expensive at $0 license cost compared to
WindowsXP at $150 license cost? No... wait... I must
have that wrong, too. Wait. Do you know WHAT you're
talking about?

> This is the exact
> problem we covered in school way back when I was
> getting my software engineering degree.

Ah. Suddenly everythnig comes clear. You have a
degree in software engineering. No wonder you think
you know everything about everything but appear to
believe that "accept mediocrity"  and "accept the fact
that all code crashes" are your philosophical touch-stones.

> I guess majoring in psychology prevented Marcus 
> from learning things like that early in his career...
> and even know.

<grin>
Psych was an easy major I could use to get out with a degree
'cuz my daddy had spent a lot of money on my education and
it was important to him. I spent all my time in the computer room
coding. Never took any CS courses, though. I admit I wish I had
learned assembler... coming into college with 4 years of BASIC
programming under my belt was poor prep for when I started
self-study in C on our PDP 11-44. What were you doing back then,
teething? Learning to walk? Getting potty trained?

mjr.