Message-ID: <1059367077.3488.256.camel@localhost>
From: pauls at utdallas.edu (Paul Schmehl)
Subject: DCOM RPC exploit  (dcom.c)

On Sun, 2003-07-27 at 21:03, Jason wrote:
> 
> True, a university is not a corporation and has different requirements 
> all together. This does not mean that just because students are learning 
> to program the university is absolved of teaching the student to program 
> securely. A reasonable start here might be a computer secured to 
> industry best practices.
> 
You'd have to talk to the schools of engineering and computer science
for that.  Their faculty are the ones teaching programming, and you can
rest assured they don't consult with IT before planning their courses.

> ** Being a university it is the responsibility of the institution to 
> teach your students the right way and to help them understand why. **
> 
One would hope so.  But what's being taught at a university is entirely
out of the hands of the IT staff that support the university's work. 
Given the rate of buffer overflows, XSS and other problems with code,
one can only think that what's being taught isn't good enough yet.

> Are there policies governing the use of computers on campus networks?
> 
There are at UTD, and I know there are at many other campuses.  And
they're publicly posted and routinely taught.  But again, this isn't
about me or UTD.  It's about admins in general.

> You can shove it down their throats, and you can enforce it. This is not 
> easy and it is not trivial but it is your responsibility as a 
> professional.

You shove something down the throat of vice president, a dean or a
tenured professor and you'll be joining others in the unemployment
line.  I tend to think the same would be true for the executives of any
corporation as well.  And I submit to you that shoving things down the
users throats is grossly _un_professional.

The job of IT is to support the mission of the organization, *not* to
shove things down people's throats.  Rather than force people into a
preconceived mold, our job is to try to find innovative solutions that
allow them to do their work in a secure manner.  A completely secure
environment that disallows research is completely useless to a
university.

>  As I stated in a previous mail, there is a big difference 
> between enabling capabilities needed to achieve a goal and leaving 
> everything turned on because it might be needed later.
> 
Well I'm glad you clarified that.  I had no idea, and I'm sure all the
other IT folks were in the dark as well.

> This is my position.
> 
> ** It has to start somewhere, get on the train and help out instead of 
> complaining that it cannot be done. **
> 
I have not once said that it can't be done.  I have stated repeatedly
that it isn't as trivial as you (and some others) seem to think it is.
> 
> No, I take issue with you presenting and defending the same excuses we 
> hear over and over everywhere. I can't do it, it is too hard, I don't 
> have time, there is no known exploit...
> 
And not once have I defended that.  Go back and read my responses. 
Where I have I *once* said that it can't be done?  I have taken issue
with your simplistic answers to complex problems.

> Yes, it is hard. I know this, you know this, we all know this.
> 
Well now we're finally getting somewhere.

> Now step up to the plate and contribute to the solution instead of 
> allowing the problem to continue. It has been shown several times and 
> ways on this list and others by myself and others that the problem would 
> be a lot less severe if we stopped complaining about how difficult it is 
> and started to do it.
> 
Ummm...I *have* contributed, not just here, but other places as
well...but this isn't about blowing my horn, which I don't do anyway.
> 
> I trivialize the belief that the problem is insurmountable and that not 
> publishing exploits somehow makes the problem go away. This is what my 
> original post was about.
> 
And again, not *once* have I said the problem is insurmountable.  In
fact, I have characterized the DCOM problem as just another PITA, not
even "scary" as Steve discussed.
> 
> One approach, there are many mind you, might be to identify the RPC call 
> in question and then look for the existence of one of the valid return 
> addresses within the payload. Do I have to provide that too?
> 
Now you're going to teach me IDS?  When you don't even understand it
yourself?  First, I'm not worried about outside RPC attacks.  We have a
default deny policy at the edge and have blocked all Windows and Unix
networking ports (including RPC) for some time now.  Second, there's
already a snort sig for this, so I don't need you to provide one.

> Read your posts and show me how you have once contributed something of 
> value to the issue. All I have seen is flawed opinion and a weak defense 
> of a flawed position. I am asking you and all that think like you to 
> contribute to the solution with something productive or sit back and 
> read the list so others can.
> 
You don't think I've contributed.  Others do.  That's life.

> Before responding why not go reverse the vulnerability and write an 
> effective signature for it? Then post that to the list and we will all 
> have something useful to work with.
> 
1) I have better things to do.  2) I'm not a coder.  Never said I was. 
3) I have no interest in reversing vulnerabilities.  And if you think
that's the only way someone can contribute to this list, then I'm
sorry.  It's not.
> 
> Again I ask you to read your posts on this matter and tell me what clue 
> you have presented us.
> 
To some, I've given a perspective of the problems associated with worms
that they may never have considered before.  You apparently think that's
worthless input.  Others do not.

> Is this one?
> 
> "Ron, you are just as clueless as you were when Slammer hit."
> 
> Way to add value there, Bravo!
> 
It's at least as valuable as your rant about no excuses.  Ron comes from
the same place you do and refuses to see the other side of the issue,
much like you.  No point in rehashing it with him.

-- 
Paul Schmehl (pauls@...allas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu/~pauls/

Powered by blists - more mailing lists