[37] in bugtraq


home	help	back	first	fref	pref	prev	next	nref	lref	last	post
Earlier mail from the bugtraq mailing list... forwarded.

wchuang@ATHENA.MIT.EDU (wchuang@ATHENA.MIT.EDU)
Tue Oct 18 18:44:28 1994

Message-Id: <199410031228.AA06996@mail.fwi.uva.nl>
To: rwing!pat@ole.cdac.com (Pat Myrto)
Cc: bugtraq@crimelab.com
Subject: Re: Lets make sure these are fixed (was: Tim Newsham) 
In-Reply-To: Your message of "Mon, 03 Oct 1994 01:54:40 PDT."
             <9410030854.AA05291@rwing.UUCP> 
Date: Mon, 03 Oct 1994 13:28:55 +0100
From: Casper Dik <casper@fwi.uva.nl>
Sender: bugtraq-owner@crimelab.com
Precedence: bulk



>Question I have is - how does doing all those saves and restores in
>SPARC assembler result in the user being able to modify the ucred struct
>in a running program without privs to modify memory directly?  I suppose
>a workaround would be to (cringe) disable ps temporarily, or forthose
>who can, modify it to not show that address info and and deny the info
>needed to find the ucred struct in a running program, at least until a
>real fix is devised.  Perhaps another idea would be to devise some test
>to result in the process being killed when a user overflows the register
>windows (hell, I'm really groping here, so bear with me).

Have you tried it on your system?  As far as I can tell this code might
have worked at one time under Solaris 2.x (x <= 1).   Currently
all it does is core dump.  (With a SIGSEGV/SEGV_MAPERR on the address
specified on the command line)

The code works by taking advantage of the register window underflow
and overflow traps that didn't check whether the "stack frames" are
in the user's address space or not.  Reading memory is done by using up
the register windows thus making sure the last restore causes an underflow
trap (which restores registers from kernel memory: gives read access)
Using the overflow trap it is possible to write memory.

In Solaris 2.2 and 2.3 this works properly as far as I can tell (the
source seems to check the source and target of window loads/stores.
Nor can I get the example to work).

Similar bugs once existed in SunOS 4.1.x (though instruction emulation traps
where most often used).

I do not know where this code comes from, but it has been around quite some
time.

>One thing is obvious:  The crackers have access to source and time to
>really study it, most admins DON'T.  They also know their way around in
>SPARC assembler (I am still looking for a good book on the subject).

I'm not sure whether this is a hacker product or someone really well-versed
in the subject that wrote these.  The original multiply/divide code uses
similar hacks and does not originate in the hacker comunity, if I'm 
informed right.

Having understood the SPARC assembler it is then easy to modify and
adapt this code to try new holes in the system.

One thing strikes me as odd in this code, though: the stack in this code
is made to grow upwards, instead of downwards.

The best reference on SPARC assembler is undoubtedly the architecture
reference manual.  It tells you exactly what all these assembler instructions
do.

>These odds need to be evened up a bit.  And if vendors knew about this
>kind of vulnerability and did or said nothing, that borders on criminal.
>'Bout time source licenses (for reconfig rights only, not derived works,
>a hefty fee and royalties are appropriate for that) became more affordable
>so honest folk would have access and a better chance of dealing with
>these people.  That would at least allow enough differences to be
>introduced that crackers would not be assured of identical conditions
>from site to site.  A unix-type OS is just too complex to lock the
>users out totally - not until vendors can GUARANTEE that they have
>not left some inadvertant holes.

Holes like this one are not found easily unless you know what you're looking
for.

I think this particular hole is fixed in Solaris 2.3 (even FCS) and I think
I even checked 2.2 when I first got this code.  I put the code
aside as being of historical importance only.

Or can people reproduce this on their Solaris systems?  You might want to
change the number of restores/saves too: some systems have 7 others 8
register windows.

>And you can bet the cracker's best or most invasive scripts were NOT
>posted.  Nobody shows their ace-in-the-hole.  There are sure some bugs
>to be trackin' there, it seems to me...  And yes, I wish I had some
>fixes to offer.  I am sure we will get CERT advisories about un-resolved
>holes 'round about January or February 1995...

Only the bin mail hole is still present, I think.

Casper

home	help	back	first	fref	pref	prev	next	nref	lref	last	post
[37] in bugtraq

Earlier mail from the bugtraq mailing list... forwarded.

wchuang@ATHENA.MIT.EDU (wchuang@ATHENA.MIT.EDU)Tue Oct 18 18:44:28 1994

wchuang@ATHENA.MIT.EDU (wchuang@ATHENA.MIT.EDU)
Tue Oct 18 18:44:28 1994
