On why debugging OpenSSH can be so hard - openssh

This is a discussion on On why debugging OpenSSH can be so hard - openssh ; When OpenSSH works and I will say it does that most of the time, it's great. But when it doesn't and it has to be debugged, it can be such a pain. At one point, it was not working, complaining ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: On why debugging OpenSSH can be so hard

  1. On why debugging OpenSSH can be so hard

    When OpenSSH works and I will say it does that most of the time, it's
    great. But when it doesn't and it has to be debugged, it can be such
    a pain.

    At one point, it was not working, complaining with the message

    debug3: mm_answer_keyallowed: key 0x67dc00 is disallowed

    Now I just couldn't figure this out. Why did it not like my key?

    It turns out it was intentionally presenting me with misinformation.
    You see, there was no key file present where it was looking. I
    thought it was looking in one place, but it was actually looking in
    another.

    And when I looked at the source code, I found out why it wasn't
    telling me this.

    /* Fail quietly if file does not exist */
    if (stat(file, &st) < 0) {
    /* Restore the privileged uid. */
    restore_uid();
    return 0;
    }
    /* Open the file containing the authorized keys. */
    f = fopen(file, "r");
    if (!f) {
    /* Restore the privileged uid. */
    restore_uid();
    return 0;
    }

    Fail quietly, indeed! It's not simply doing this under ordinary
    operation, but even in debug operation, even under debug level 3. In
    the perfect place where it can tell us quite informatively what's
    about to go wrong--there is nothing!

    And that is going to be eventually lead the program down a wrong path
    somewhere later on, which, ultimately, leads it to cough out the
    highly inaccurate error "key 0x67dc00 is disallowed".

    This then looks like a great opportunity for the developers to help
    us out in the future. In fact, I even thought it was simply an
    oversight not have this logged under debugging. So I dutifully filed
    a bug report, https://bugzilla.mindrot.org/show_bug.cgi?id=1388, then
    eight months passed. And as I said earlier, the misleading error
    turns out to be intended behavior.

    So in case you're wondering why debugging OpenSSH can be so hard, now you know.
    --

    Maurice Volaski, mvolaski@aecom.yu.edu
    Computing Support, Rose F. Kennedy Center
    Albert Einstein College of Medicine of Yeshiva University


  2. RE: On why debugging OpenSSH can be so hard

    >No. He's saying that it leaks information that doesn't need to be
    leaked.

    That is fair enough as regards not leaking information to the client, but there is no excuse for not providing sufficient diagnostics to the server log so that at least the SysAdmin can help the guy. There is no information leak problem there - indeed it may help diagnose attacks as well.

    --
    Cheers,

    Rick Parsons

    EDS - UKIMEA - Data Centre - Midrange Unix
    address: c/o Rolls Royce plc, GP1-2, PO Box 3, Filton, Bristol, BS34 7QE, UK
    email: mailto:rick.parsons@eds.com
    telephone: +(44) 117 979 7883 fax: +(44) 117 979 7353 mobile: +(44) 7790 493162

    *
    If you have received this email in error, please advise me by reply and delete it.

    Electronic Data Systems Ltd
    Registered Office:, Lansdowne House, Berkeley Square, London W1J 6ER
    Registered in England no: 53419
    VAT number: 432 99 5915
    web: http://www.eds.com/


  3. Re: On why debugging OpenSSH can be so hard

    On Fri, Jul 04, 2008 at 08:57:41AM +0200, Tonnerre Lombard wrote:
    > On Tue, 1 Jul 2008 16:02:46 -0400, Maurice Volaski wrote:
    > > Fail quietly, indeed! It's not simply doing this under ordinary
    > > operation, but even in debug operation, even under debug level 3. In
    > > the perfect place where it can tell us quite informatively what's
    > > about to go wrong--there is nothing!

    [...]
    >
    > Please bear in mind that in the world of cryptography, the difference
    > between proper error messages and information disclosure
    > vulnerabilities is narrow, or only a nuance.


    This is a red herring. If the operator of the server is running the
    SSH daemon in debug mode, how is not reporting the real error a
    security risk? I understand and agree with your point, but it seems
    not applicable to this case...

    Now, Maurice didn't provide quite enough context... he didn't mention
    whether the debug info was from the client or the server, and didn't
    mention where the code snippet he posted came from. But if you
    actually look at the snippet, it is clearly from sshd:

    > /* Fail quietly if file does not exist */
    > if (stat(file, &st) < 0) {
    > /* Restore the privileged uid. */
    > restore_uid();
    > return 0;
    > }
    > /* Open the file containing the authorized keys. */
    > f = fopen(file, "r");
    > if (!f) {
    > /* Restore the privileged uid. */
    > restore_uid();
    > return 0;
    > }


    If this is on the server, then again, the sysadmin running the server
    in debug mode has every right to the information that the file is
    missing, and adding debug messages won't expose anything to the remote
    user. Debugging the problem without that info will indeed be
    difficult.

    This can not possibly be construed as a security risk. It's just bad
    programming.

    --
    Derek D. Martin
    http://www.pizzashack.org/
    GPG Key ID: 0x81CFE75D


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.1 (GNU/Linux)

    iD8DBQFIdXI6djdlQoHP510RAhAXAJ9xBPkO8JRtiD2E7gIsQu fPPufsLwCffAfc
    kFgC5dhoxh/MiyXTzk2rhO8=
    =tn6F
    -----END PGP SIGNATURE-----


+ Reply to Thread