Finally got a reply on this. They think it's pretty good but want more on security for the type. I'm puzzled as to their questions, but will endeavor to address them in a further reply.
Randolph
Finally got a reply on this. They think it's pretty good but want
more on security for the type.
Hi,
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 
CU Lars.
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
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@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
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@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@radiance-online.org
http://www.radiance-online.org/mailman/listinfo/radiance-dev