[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