Very Computer

Many people have been asking me whether SunOS is vulnerable to the rlogin
attack described in CERT advisory CA-97.06, released this week. It is not.

I have checked the source for each release and find that the variable
affected by the overflow attack is not kept on the stack. Thus no such attack
can succeed.

Under normal conditions this information would have been included in the
bulletin. However I was not able to supply the information before the
publication deadline. I certainly apologize for any inconvenience resulting
from the lack of this information.

-mg-

Mark Graff
Sun Security Coordinator

*>Many people have been asking me whether SunOS is vulnerable to the rlogin
*>attack described in CERT advisory CA-97.06, released this week. It is not.

*>I have checked the source for each release and find that the variable
*>affected by the overflow attack is not kept on the stack. Thus no such attack
*>can succeed.

*>Under normal conditions this information would have been included in the
*>bulletin. However I was not able to supply the information before the
*>publication deadline. I certainly apologize for any inconvenience resulting
*>from the lack of this information.

Useful information. HOwever SunOS rlogin does not properly check the
variable since if you hand it too long a TERM variable, it does crash
rlogin.
--
Bill Unruh

Quote:>I have checked the source for each release and find that the variable
>affected by the overflow attack is not kept on the stack. Thus no such attack
>can succeed.

--
----------------

----------------
exit(main(kfp->kargc, argv, environ));

The code in rlogin looks like this:

        s = getenv("TERM");
        if (s)
            strcpy(term, s);

        strcat(term,"/");
        strcat(term,speeds[<ttyspeed>]);

Whatever string you use to overflow, shortly after "term", the strings
used for "speeds" live.  One you overflow into those, the strcat will
not end as your strcat'ing the end of the overflown buffer to itself,
a process that doesn't finish until strcat hits the end of the data segment.

I'm fairly confident that you can't abuse this.  However, since
programs shouldn't core dump the buffer overflow is fixed in the next
release, but it doesn't look like a security problem from where I stand.

Casper

--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Quote:>I can answer that; it's in the data segment.  After the term variable,

I understand and accept that rlogin may not be vulnerable to the
CERT-reported problem; my point, which I appear to have miscommunicated,
was that "that variable isn't in the stack, it's not a problem" is a bad
assumption.

Sorry for any misunderstandings.

--
----------------

----------------
exit(main(kfp->kargc, argv, environ));

Quote:>I understand and accept that rlogin may not be vulnerable to the
>CERT-reported problem; my point, which I appear to have miscommunicated,
>was that "that variable isn't in the stack, it's not a problem" is a bad
>assumption.

I also recall several data segment problems, one in rdist which allowed
you to zero out the user variable and one in sendmail which allowed you
to negatively index an array and write random values on random
places in the data segment.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

-mg-

Quote:>Many people have been asking me whether SunOS is vulnerable to the rlogin
>attack described in CERT advisory CA-97.06, released this week. It is not.

Quote:>-mg-

>Mark Graff
>Sun Security Coordinator

Can't this information be passed to CERT and have them release the info?
--
                             Bradley M. Kuhn
                       http://www.smart.net/~bkuhn

        Geek code, favorite quotes, PGP public key, et al. on WWW page

Quote:>Can't this information be passed to CERT and have them release the info?

Quote:>All versions of SunOS?  You could be more specific here...

Quote:>Well, I am still wondering, since this message is *not* PGP signed, or
>authenticated in any other way....

If the lack of a PGP signature represents a serious impediment to my
comments being taken seriously, tell me about it, folks, and I will see
about mending my ways.

-mg-

Mark Graff

Sun Security Coordinator

415-786-5274