lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
From: security at brvenik.com (Jason)
Subject: DCOM RPC exploit  (dcom.c)

Paul Schmehl wrote:
[snip]
> It takes a lot more work than that.  What do you do about the machines
> that *do* need DCOM?  Ever notice there are students learning
> programming at a university?  It's not like a corporation where you can
> shove changes down people's throats without planning carefully first.

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.

** Being a university it is the responsibility of the institution to 
teach your students the right way and to help them understand why. **

Are there policies governing the use of computers on campus networks?

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

This is my position.

** It has to start somewhere, get on the train and help out instead of 
complaining that it cannot be done. **

> 
> You keep trying to trivialize the difficult.  And you make the false
> assumption that I'm complaining about my *own* problems, when in fact
> that's not the case at all.  I'm arguing on behalf of all the people you
> so cavalierly denigrate.

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

Yes, it is hard. I know this, you know this, we all know this.

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.

Here is a suggestion that is pretty easy to implement to start this 
effort off. Put the references provided by this list into a few new 
sections at

http://www.utdallas.edu/ir/tcs/techsupp/internetsecurity/index.htm
or if you prefer
http://www.utdallas.edu/ir/tcs/techsupp/security.html

They might be

* Best practices for securing windows.
* Tools to help with securing windows.
* Sites to learn more about making windows secure.


> 
>>If the "Unis" do all this work for free ( hardly, my taxes pay for it ) 
>>and play such a huge role then maybe they could do a little research as 
>>a team and make it "Easy" to run windows.
>>
> 
> Your taxes pay for the universities to do their work, but that work is
> provided to the world for free.  Don't trivialize that.
> 
[snip - a bunch of trivialize this trivialize that]

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.

> 
>>Attempting to put words into my mails and twist my statements to support 
>>your position will not work.
>>
> 
> If I did that, you'd have a legitimate complaint.  I haven't.
> 
>>>Oh, I get it.  You've never actually used an IDS.  You just understand
>>>the dictionary definition of one.  Try sitting in front of the console
>>>staring at a half a million alerts and see if the IDS *does* anything
>>>besides spewing information that *you* have to research, that *you* 
>>>have to interpret and that *you* have to take action on.
>>>
>>
>>All this reminds me of a quote. I cannot recall the orgin unfortunately.
>>
>>"never argue with idiots, they will drag you down and beat you with 
>>experience"
>>
> 
> Indeed.  Your post proved you know nothing about IDSes, so when I
> pointed that out, you retreat to quotes and smug replies.  I can't say
> that I'm surprised.

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?

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.

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.

[snip - the mondays]

> If you had a clue, you wouldn't post what you posted.
> 

Again I ask you to read your posts on this matter and tell me what clue 
you have presented us.

Is this one?

"Ron, you are just as clueless as you were when Slammer hit."

Way to add value there, Bravo!



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ