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

[meister () ftp com (prince of insufficient light)]

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

I was wondering that too; perhaps there is some obscure bug in the SPARC
chip itself that allows the access without flagging an exception? (grope
grope, i know virtually NOTHING about sparc assembler and the chips internals)

However, as a data point, i tried the above referenced Sparc code on two
different Sparc Classic machines: one running Solaris 2.2, the other
running Solaris 2.3, with the kernel jumbo patches applied.

The results were exactly as i expected to get on both machines:

% ./read 0x<insert address here>
Segmentation fault (core dumped)

Code was compiled with GCC 2.4.5. Adb showed me that GCC did not do 
anything funny to the assembly source; the rdmem routine was assembled
as given. The seg fault occured at the "restore" instruction in the
following section of the provided code:

btst 4, %o0
andn %o0, 7, %fp
restore

So. Has anyone found that the provided code *does* do what the message
implied? what were your test conditions?


                                     -phil servita, FTP Software, 
                                           Systems Dept.