Solaris telnetd Analysis

kcope has put on a short PDF paper on why the vulnerability in telnetd happens:

3199 } else /* default, no auth. info available, login does it all */ {
3200 (void) execl(LOGIN_PROGRAM, “login”,
3201 “-p”, “-h”, host, “-d”, slavename,
3202 getenv(“USER”), 0);
3203 }

1397 break;
1399 case ‘f’:
1400 /*
1401 * Must be root to bypass authentication
1402 * otherwise we exit() as punishment for trying.
1403 */
1404 if (getuid() != 0 || geteuid() != 0) {
1405 audit_error = ADT_FAIL_VALUE_AUTH_BYPASS;
1407 login_exit(1); /* sigh */
1409 }
1410 /* save fflag user name for future use */
1411 SCPYL(user_name, optarg);
1412 fflag = B_TRUE;

As you can see the “Must be root to bypass authentication” should already rise some worries, but what is funnier that because we are requesting a different user than ‘root’ we actually get ‘root’ access, as login thinks we are already ‘root’, when its called by in.telnetd.

  • Ethical

    …the weakest link…

    The question begs, was this ever peer-reviewed? – wow.

    From an in-house perspective:
    Corrective action, invoke peer review, create training manual for in-house developers. Make the manual a mandatory read and test, as part of the induction process for all those who create code…and part of peformance review for bonuses, appraisal etc….

    Isn’t this bread and butter stuff?

    It’s easy to criticise, praise, and provide guidance. Core operting system code.

    Gobsmacked. I am because this is such a simple problem. It’s not a failing to manage keys on an EFS partition, and forgetting that some of that data is in a swap file or on a non-encrypted FAT/NTFS partion. It’s not input validation.

    It should be complete shock, but with streamlined businesses and processes, the cost to change those processes, or the fight for the budget, just isn’t worth the hastle for some managers. Especially.

    This could have been picked up by an automated code review.

    Perhaps a case of security and economics, the few hands, but many eyes.


  • CCC

    The problem is in the ‘login’ program, not telnet, so a local exploit should work as well, even if the telnet service is not available.