Re: S/Key & OPIE Database Vulnerability

From: Eivind Eklund (perhapsat_private)
Date: Mon Jan 31 2000 - 12:17:23 PST

  • Next message: Gary Geisbert: "Re: Disable Parent Paths"

    On Thu, Jan 27, 2000 at 02:47:45PM -0500, Jordan Ritter wrote:
    > On Thu, 27 Jan 2000, Eivind Eklund wrote:
    >
    > # You don't get the same effect by using ssh RSA authentication, partly
    > # you either have
    > # (1) Users that key in the passphrase each time they connect to the
    > #     server
    > # OR
    > # (2) Agent forwarding, which means that if any computer they have an
    > #     account on is compromised, so is your box.
    >
    > I don't see how 2 can true, at least by default.  For agent-forwarding to
    > give an attacker a useful advantage against the originating host, that
    > host would have to both be running sshd, and have the public key specified
    > in that particular user's authorized_keys.
    
    I was not talking about the originating host (they/you distinction.)
    
    If host A allows users to ssh into it using RSA authentication
    (authorized_keys), and a user on A use agent forwarding, has an
    account on B, and B is compromised, then the crackers on B also get
    access to A, without anything being logged on the user's workstation.
    
    I've seen this mode of attack exploited by crackers.
    
    If anybody are interested in writing code to prevent it, note that the
    best way to do this would probably be to:
    
    1. Add a new challenge type to SSH (For SSH v1, this would be
       challenge type 2, as 0 and 1 is already used.)  This challenge
       should be signed by each machine along the agent forwarding path,
       with the signatures also indicating what machines are on both sides
       of the machine signing.  This allows full verification as long as
       there isn't any spot in the forward chain with two old versions of
       SSHD after each other.  (Getting the info on which machines are on
       each side will be slightly complex.)
    2. authorized_keys should be extended with policies around each key
       (I would probably base these on KeyNote, and look at how OpenBSD
       has implemented the Kerberos ticket policies using this.)  These
       policies should also be able to say 'Ask the user explictly', which
       should be passed back to the agent.
    3. The client should be modified to log all challenges, and be able to
       ask the user if (s)he wants to do a particular authentication.
    
    Eivind.
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:32:37 PDT