Re: Lets make sure these are fixed (was: Tim Newsham)

[rwing!pat () ole cdac com (Pat Myrto)]

"In the previous message, Casper Dik said..."
> 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)

Not yet - I don't have Solaris 2.x, and I wanted to take time to study it
and get info about it before I tried to run it (call me paranoid, I
have no idea what those assembler instructions might do, not knowing
anyting about SPARC assembly).  I will be trying them, though.  I just
don't want to turn my machine into a blubbering mess with some code
I am not in a good position to evaluate first.  I don't have a throwaway
box to test this sort of stuff, so I prefer to err on the side of
caution.

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

Oh, wunnerful.

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

So this is basically a variation on the zero-divide thing, then.

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

Well, having the code posted without any comments via what appears to
be a .forward file planted without the acct owners knowlege hardly
suggests that its just from somene well versed.  If it were posted with
explanatory comments, from a person who owns up to having posted it,
and perhaps suggestions what to do about it, I could understand.  But
these were messages with no comment, no nothing.  Just this strange
code.

> 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.
 
Would that be signifigant?  Uncontrolled stack growth or shrinkage
would either just show as a memory leak, or a seg violation respectively,
wouldn't it?

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

I will look for that.  The coverage in the Answerbook helps one understand
the instructions, but does little to cover how those interact with the
underlying OS.

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

But they seem to get foundk, much to the dismay of some victim, don't they?

Many folks that would know what they are looking for don't even have
the opportunity to do anything about it.  I guess that's what sticks in
my craw.  Sun is quicker than most at getting SOMETHING out, but if
system info were more widely available (and I mean via routes other than
posting src from anon sites), I suspect useful workarounds and fixes
would practiclly be out the next day, unless I overestimate some of the
talent on this mailing list (and I doubt that).

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

Perhaps other Solaris 2.x users (with varying patch applications) might
check this out and post their findings.  I will do likewise on SunOS
4.1.2 (yeh, I know its got whiskers, but I like it)...  Seems these
days, I get on a SysV based system designed for the shrinkwrap market,
I swear alot...  :-)

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

Good point.  I forgot that different CPUs have different window counts.
I have a SS1, so I suspect that means I have 7 windows, 8 to overflow...
Is doing all those saves and restores what one calls doing a 'register
spill' - presumably to leave a full set for a starting application?

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

I sincerely hope so.  I just hate being in the "Day late and dollar
short" position.  Thank the Force for the availability of mail.local.c
for working on to fix the mail hole.  I included what looks like a good
way of accomplishing safe opens contributed by a respondent to my mail
query in the summary.  Lot of ideas I hadn't thought of, all combined
in that modified mail.local.c

Thanks for clearing up some of my questions.
-- 
pat@rwing  [If all fails, try:  rwing!pat () eskimo com]  Pat Myrto - Seattle WA
"No one has the right to destroy another person's belief by demanding
empirical evidence."  --   Ann Landers, nationally syndicated advice columnist
and Director at Handgun Control Inc.