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