[Radiance-dev] Radiance file type registration
R Fritz
rfritz at u.washington.edu
Thu Feb 26 10:24:13 PST 2009
I'll probably do that soon. I've also written back, asking for
examples.
Randolph
On Feb 26, 2009, at 5:19 AM, Jack de Valpine wrote:
> Hi Randolph,
>
> Just a thought on this. Would it be worth looking at how this
> question is managed in other image types? That way you can construct
> an appropriate response?
>
> Regards,
>
> -Jack
>
> Randolph Fritz wrote:
>> Just the HDR type. It's simplest, and the type I think it's most
>> important to register. The specific section and reply is:
>>
>>> Security considerations: The Radiance HDR file format does not
>>> include
>>> > executable code or scripts; it is a graphics file with an ASCII
>>> > header. Compression is used, which could crash an image
>>> > viewer. There is no way to completely rule out the possibility of
>>> > malicious content, however HDR viewer applications do not usually
>>> > run with administrator privileges--they seem poor targets for such
>>> > attacks.
>>>
>> Response:
>>> This is all good info but it would also be good to comment on
>>> whether
>>> or not the type in typical use needs integrity or confidentiality
>>> protection,
>>> and if it does how it might be provided (internal to the type or
>>> some sort
>>> of external service).
>> This is two-thirds of the "CIA triad" of security issues. These are
>> usually raised with regard to critical database and control data. I
>> am puzzled as to why these are being brought up for an image file
>> format and I have written back asking for an example of what is
>> desired.
>>
>> Randolph
>>
>> Lars O. Grobe wrote:
>>> > Finally got a reply on this. They think it's pretty good but
>>> want more on security for the type.
>>>
>>> did you only submit the hdr or also the scene description types?
>>> Security-wise, the rad-files have to be treated as scripts, as
>>> they allow any command to be executed from within (using the !-
>>> prefix), so I guess this leads to a very different classification
>>> then hdr's. Not sure what kind of nonsense an attacker could hide
>>> inside an octree though (I doubt that there are any security
>>> checks in Radiance about memory protection here?) - but I am just
>>> a non-developer on the wrong list, without inside-knowledge on the
>>> implementation here ;-)
>>
>>
>> _______________________________________________
>> Radiance-dev mailing list
>> Radiance-dev at radiance-online.org
>> http://www.radiance-online.org/mailman/listinfo/radiance-dev
>>
>
> --
> # Jack de Valpine
> # president
> #
> # visarc incorporated
> # http://www.visarc.com
> #
> # channeling technology for superior design and construction
>
>
> _______________________________________________
> Radiance-dev mailing list
> Radiance-dev at radiance-online.org
> http://www.radiance-online.org/mailman/listinfo/radiance-dev
More information about the Radiance-dev
mailing list