Security problems with UnManagedStruct

[Leopold Toetsch]

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.000000
20
42.000000

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

[Jeff Clites]

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

[Luke Palmer]

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

[Dan Sugalski]

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
d...@sidhe.org have teddy bears and even
teddy bears get drunk