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

| 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
pgpC6vbs25Ci8.pgp
Description: PGP signature
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Deliberately create slow SSH response?, Bryan Christ |
|---|---|
| Next by Date: | Help with Openssh V5 - SFTP Chroot issue, Rebstock, Roland |
| Previous by Thread: | RE: On why debugging OpenSSH can be so hard, Parsons, Rick |
| Next by Thread: | Re: On why debugging OpenSSH can be so hard, Maurice Volaski |
| Indexes: | [Date] [Thread] [Top] [All Lists] |