[x3d-public] SFImage component mismatch; security implications

Andreas Plesch andreasplesch at gmail.com
Mon Sep 16 06:49:59 PDT 2019

On Mon, Sep 16, 2019 at 7:55 AM Brutzman, Donald (Don) (CIV)
<brutzman at nps.edu> wrote:
> In general, the usual spec response is "results are undefined" because we avoid legislating how bad content should be handled, letting browsers do whatever is most efficient.  Caveat author - thus the importance of quality assurance (QA).
> Looking at Web3D Conference 2019 release of X3Dv4 spec, not finding any such statement:
>         18.4.6 PixelTexture
>         http://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD1/Part01/components/texturing.html#PixelTexture
>         5.3.6 SFImage and MFImage
>         http://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD1/Part01/fieldsDef.html#SFImageAndMFImage
> We should probably add this, something like
> "Rendering results are undefined when an incorrectly specified SFImage texture or MFImage texture array is defined."

Adding a sentence would be very useful. To avoid saying 'defined'
shortly after 'undefined' perhaps shorten to:

"Rendering results are undefined when a SFImage texture or MFImage
texture array is specified incorrectly."

> Also thinking we should list Security Considerations for this domain.  For example, conceivably a malformed SFImage might lead to buffer overruns or definition of hostile code if not protected against.
> Food for thought:
>         An Overview of Image Security Techiques - Semantic Scholar
>         https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=11&ved=2ahUKEwiV1fbwodXkAhWCCjQIHRCnBOcQFjAKegQIABAC&url=https%3A%2F%2Fpdfs.semanticscholar.org%2F6b44%2Fd2809d2dc515c865b989d6cefae5764d883d.pdf&usg=AOvVaw38PNDJCJr07U_d9LDrKU59

This seems about protecting the authenticity of an image.

>         What could an “<img src=” XSS do?
>         https://security.stackexchange.com/questions/135513/what-could-an-img-src-xss-do

mostly about referencing foreign content

>          IMG tag vulnerability
>         https://security.stackexchange.com/questions/36447/img-tag-vulnerability

raises svg as xml vulnerabilities, and triggering login prompts.

These issues do not seem to apply to the local PixelTexture image. Not
sure what could be specific to PixelTexture, unrelated to XML/JSON/etc

In x3dom, the pixeltexture gets parsed into a floating point array,
then converted into integer array which is then directly used as a
webgl texture. If the image is too large webgl complains but that is
something webgl has to handle anyways. If the array is too large js
may slow down, run out of memory, but that is something which can
happen generally, eg. is not specific to images.

So ImageTexture with urls to a remote server may deserve more of an
explicit security advisory (a server can change to supply anything).


> On 9/15/2019 1:11 PM, Andreas Plesch wrote:
> > A question on PixelTexture came up on how to treat SFImage pixel
> > values which do not match the number of components. For example,
> >
> > "1 1 1 0xAABB"
> >
> > gives a value larger than 0xFF for the one component pixel.
> >
> > Is this just invalid or should the value be masked to the lower byte, 'BB' ?
> >
> > If invalid, is there guidance on how browsers should render ? black ?
> >
> > -Andreas
> >
> all the best, Don
> --
> Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
> X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman

Andreas Plesch
Waltham, MA 02453

More information about the x3d-public mailing list