Bugtraq mailing list archives
Re: Lets make sure these are fixed (was: Tim Newsham)
From: meister () ftp com (prince of insufficient light)
Date: Mon, 3 Oct 1994 17:09:56 -0400
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.
Current thread:
- Re: Lets make sure these are fixed (was: Tim Newsham) prince of insufficient light (Oct 03)