Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Re: explanation, gurus? :-) (image memory representation)

From: jeff:rebol at: 21-Aug-2001 7:10

Howdy, DocKimbel:
> > What about this one? > > > > img: make image! [10x10 #{FFFFFF}] == make image! [10x10 > > #{ > > FFFFFFCC96CFD8A9CD0000000A00004C96CFE8B0CD0000000A00001C90CF > > E8B0CD0000000A0000C4E3D9E8B0CD0000000A000084E... > > That's clearly a bug. The byte sequence that appear is a > Rebol memory space dump !! It's more than a simple bug, > it's a potential security hole !
When we create an image and pass in some binary data to use for that image: if the image is larger than the data we provided the remaining memory is uninitialized. This memory is from the heap. No live objects will be in there, but perhaps fragments of recycled objects could be evident there. It'd be hard for someone to programmatically exploit this current behavior by looking a random window of heap memory because the contents are as good as random due to the variances in the recycling path for different OSes, architectures, and machine configurations-- this is also not an issue of a being able to munge the stack since this is all heap memory (possibly reclaimed or otherwise). Nonetheless, this remainder memory should be cleared.
> Also, did you notice that image!'s data are stored > internally in 32 bits ?
We save out images with out the alpha channel and reconstruct the alpha channel when reading images back in.
> It would be great if more Rebol types were supported by the > /library interface. (Image! should be my first choice!).
The next Library revision will allow all string-series! types to be passed where a library routine expects string!-- that includes such types as image, binary, issue, email, etc. RETURING these types is a whole different issue, though. :-) -jeff