Re: [SLUG] Re: Preventing attacks

[O Plameras]

Matthew Palmer wrote:
On Mon, Nov 08, 2004 at 01:31:51PM +1100, O Plameras wrote:
 

Ken Foskey wrote:
   

I am unsure how this would have prevented the attack on the kernel that
was applied?  Please explain.
     

With the intruder having acquired unprivileged access to system,  he/she 
could
have been confined to limited sets of functions because that is one of 
the things
that SELinux does. Because he/she is restricted in what can be done it will
take a bit longer to figure out ( I assume ) how to escalate privileges 
to root. In
   

Only if the set of privileges granted to the program didn't include access
to the flawed function.  It was ptrace(), so an "allow only that which is
really required" policy would have probably blocked the access, there's no
guarantee.
 

I cannot comment on this because I do not know what you are talking about.
If you can be clearer.
the meantime the SysAdmin who does what he does will notice unusual
activities within his system and so, the intruder could have been 
detected before
doing damage to the Servers.
   

Potentially.  Depends on how many tripwires the attacker managed to hit.
 

Your're probably right.
 

2. Would 'kerberos' have prevented this sort of break-in ?
       

The initial attack was by social engineering.  One developers key was
compromised due to their lack of security thought. With one weak link in
the chain then it all comes down.
     

Now, I posed the problem without really knowing  the complete details of 
the circumstances
because 'kerberos' is meant to be the strongest security protection 
against this sort of
attacks.
   

Where the hell did you pick that up from?  "This sort of attacks" could be
one of:
 

I got it from people who should know.
1) Sniff the entry of a password on a previously compromised host: hmm, no,
Kerberos doesn't protect against r00ted boxen.
 

Can you elaborate how kerberos and r00ted boxen works and where the 
latter will be
able to trick kerberos ?

2) Exploitation of a kernel vulnerability to obtain escalated privileges:
riiight.
 

I do not quite follow this. You probably did not read the circumstance 
surrounding
the Debian Break-In. (http://www.wiggy.net/debian/explanation/)

3) Use of a stored authentication credential to gain access to a system
account on another system: probably not, and Kerberos is a real pest in this
situation.
 

You are saying things about kerberos without knowing what kerberos is, 
what it is not,
and what it can do.

I gather that 'ssh' which I noticed is the cryptographic 
security procedure used
at these Debian sites has not prevented the attacks.
   

Hoo boy.
 

I note here some differences between ssh and kerberos:
1. SSH needs local identity files whilst kerberos does not
   

You mean known_hosts?  No, kerberos just restricts you to a small set of
hosts which you can access (without setting up cross-domain trust
relationships).  And after all, if an attacker has just sniffed your
password, he'd be very, very unlucky not to get the hast you connected as
well.
 

Everything in ~/.ssh directory.
2. SSH does not impose time restrictions on a session whilst kerberos 
does (Prevents
replay attacks)
   

From memory, SSH uses some form of challenge/response to set things up, so a
replay attack wouldn't be feasible.
 

From this response, it appears you do not understand what is a 'replay 
attack'. If
you can explain perhaps. Your not as clear as can be.

3. In SSH the client decides what tools and application to run on the server
   

I call 'horseshit'.  Should have done it two days ago, but there you are.
 

What you have above is the real 'horseshit' because in SSH once a client 
connects there
is no mechanism to restrict the user to a subset of commands or functions.

Whereas with Kerberos, there is a mechanism to do this.
whilst in kerberos, the server may restrict the clients from running 
certain tools and
applications (Ease and simplicity of management as to who and what to 
allow or
disallow)
   

You've never actually administered, or even smelt, a Kerberos system, have
you?  "Ease and simplicity of management" is not something I hear often in
connection with Kerberos.
 

This is another example of 'saying without knowing'. In kerberos, the 
SysAdmin
simply goes to the one Server (Master Server and make changes for a user 
for example)
and that change will be implemented in each servers within the realm.

In SSH the SysAdmin will have to connect to each Server the user is 
connecting to ,
to effect the changes. Imagine if you have a Farm of Servers consisting 
of 500 Servers.

So, I suggest you send yourself back to the drawing board as far as 
Kerberos is concerned.

 

This is my understanding of SSH and Kerberos so correct me if I'm wrong.
   

You're wrong.
 

As you can see you're the one who is wrong.

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html