Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Secure-Shell
[Top] [All Lists]

Re: On why debugging OpenSSH can be so hard

Subject: Re: On why debugging OpenSSH can be so hard
Date: Wed, 9 Jul 2008 22:21:46 -0400
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

Attachment: pgpC6vbs25Ci8.pgp
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>