Re: Security problems with UnManagedStruct
At 12:17 AM -0800 1/28/04, Jeff Clites wrote: On Jan 27, 2004, at 7:29 AM, Leopold Toetsch wrote: getinterp P5 dlfunc P0, Nul, Parrot_UnManagedStruct_get_pointer, pIP ... This is unlimited self-inspection and self-modification :) With little additions (nested structs) one could read/write all Parrot_Interp internals (including possible security bits) and not only registers like above. But current state is already sufficient to seriously damage the interpreter ($P2 above is a struct representing the current interpreter) This type of security issue seems inherent in anything NCI-related--once NCI is involved, all bets are off. It seems that, in order to guard against this (and related problems), any sort of secure mode operation of parrot would have to block use of any of the NCI infrastructure. Or restrict it to functions which have sufficient privileges, presumably because they've been audited to make sure they're correct. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Security problems with UnManagedStruct
On Jan 27, 2004, at 7:29 AM, Leopold Toetsch wrote: getinterp P5 dlfunc P0, Nul, Parrot_UnManagedStruct_get_pointer, pIP ... This is unlimited self-inspection and self-modification :) With little additions (nested structs) one could read/write all Parrot_Interp internals (including possible security bits) and not only registers like above. But current state is already sufficient to seriously damage the interpreter ($P2 above is a struct representing the current interpreter) This type of security issue seems inherent in anything NCI-related--once NCI is involved, all bets are off. It seems that, in order to guard against this (and related problems), any sort of secure mode operation of parrot would have to block use of any of the NCI infrastructure. JEff
Re: Security problems with UnManagedStruct
Leopold Toetsch writes: This is unlimited self-inspection and self-modification :) With little additions (nested structs) one could read/write all Parrot_Interp internals (including possible security bits) and not only registers like above. But current state is already sufficient to seriously damage the interpreter ($P2 above is a struct representing the current interpreter) Uh huh. I saw this coming when we first started rediscussing UnmanagedStruct. I see it not as a security hole, but as serious internal-hacking power without C code. I don't think it's fair to say that if you do something like this that the interpreter won't crash. You're being truly, ungodly evil, and you deserve what you get. But I also think it's important that this stay possible. When we're worried about security, we don't allow dlfunc (except in certain places) anyway. Luke
Security problems with UnManagedStruct
Please have a look at the following code: $ cat hack_self.imc .include datatypes.pasm .sub _main new $P1, .PerlArray push $P1, .DATATYPE_INTVAL push $P1, 32 push $P1, 0 push $P1, .DATATYPE_FLOATVAL push $P1, 32 push $P1, 0 .sym pmc Nul null Nul getinterp P5 dlfunc P0, Nul, Parrot_UnManagedStruct_get_pointer, pIP invoke set $P2, P5 assign $P2, $P1 print I20 print \n print N10 print \n set $P2[0;20], 20 set $P2[1;10], 42.0 print I20 print \n print N10 print \n end .end $ parrot hack_self.imc 0 0.00 20 42.00 This is unlimited self-inspection and self-modification :) With little additions (nested structs) one could read/write all Parrot_Interp internals (including possible security bits) and not only registers like above. But current state is already sufficient to seriously damage the interpreter ($P2 above is a struct representing the current interpreter) leo
