[FIX][VM] Secure image writing

Bert Freudenberg bert at isg.cs.uni-magdeburg.de
Thu Mar 7 17:06:47 UTC 2002


On Thu, 7 Mar 2002, Tim Rowledge wrote:

> Bert Freudenberg <bert at isg.cs.uni-magdeburg.de> is claimed by the
> authorities to have written:
> 
> > Image writing was not disabled in restricted mode. Someone replaced the
> > static call to ioCanWriteImage with a dynamic lookup and made a typo in
> > the function name string.
> I don't think that's actually the case; it should indeed by
> ioCanWriteImage these days. It has a dynamic lookup even if the plugin
> is built internal.

In the original version (ar 2/5/2001) it said 

	Interpreter>>writeImageFileIO: imageBytes
		self ioCanWriteImage ifFalse:[^self primitiveFail].

(which, btw, also explains why ioCanWriteImage was in sq.h) This was
replaced (JMM 11/8/2001) by

	Interpreter>>writeImageFileIO: imageBytes

		sCWIfn _ self ioLoadFunction: 'setCanWriteImage' From: 'SecurityPlugin'.
		sCWIfn ~= 0 ifTrue:[okToWrite _ self cCode:' ((int (*) (void)) sCWIfn)()'.
			okToWrite ifFalse:[^self primitiveFail]].

which ought to have been 'secCanWriteImage', which is what my fix fixes.

> > If it wasn't a string, the compiler would have
> > catched the error. Why is this dynamically loaded anyway? We surely
> > don't ever want the SecurityPlugin to be compiled externally."!
> Why not? It would be perfectly usable that way. When doing devlopment it
> might even be useful to delete it and then replace it for secure
> testing.

Well, it did more harm than good: disabling security is not a good idea
at all.

> There is a really big hole in the idea of the security plugin anyway;
> build the plugin internal but then write a fake one with security
> turned off (just copy the code that used to be in various unix files
> faking it out) and stick it in the right place. This will override
> the internal one and open your kimono whether you like it or not.

Of course. But since file writing is restricted to the "untrusted"  
directory for code loaded from the net that can't happen.

OTOH, it might be a good idea to disable dynamic plugin loading at 
all for a Browser Plugin VM, because there still is the problem that you 
can call any libc function from an external module.

-- Bert




More information about the Squeak-dev mailing list