Change Details

**List of steps to reproduce** (step by step, including full links if applicable): * Set in LocalSettings.php: ``` $wgFileExtensions = array_merge($wgFileExtensions, array('svg')); ``` * Upload an SVG file. Give it the destination filename `Test$output.svg`. **What happens?**: See error message in the `File:` page: > Error creating thumbnail: convert-im6.q16: unable to open image `/tmp/svg_caed3aacae81aada8a9a30bb/Test/tmp/transform_e13974305cb3.png.svg': No such file or directory @ error/blob.c/OpenBlob/2924. convert-im6.q16: no images defined `PNG:/tmp/transform_e13974305cb3.png' @ error/convert.c/ConvertImageCommand/3229. See in `$wgDebugLogFile`: ``` [thumbnail] thumbnail failed on <hostname>: error 1 "convert-im6.q16: unable to open image `/tmp/svg_caed3aacae81aada8a9a30bb/Test/tmp/transform_e13974305cb3.png.svg': No such file or directory @ error/blob.c/OpenBlob/2924. convert-im6.q16: no images defined `PNG:/tmp/transform_e13974305cb3.png' @ error/convert.c/ConvertImageCommand/3229." from "convert -background "#ffffff00" -thumbnail 120x120\! '/tmp/svg_caed3aacae81aada8a9a30bb/Test'/tmp/transform_e13974305cb3.png'.svg' PNG:'/tmp/transform_e13974305cb3.png'" ``` **What should have happened instead?**: A bitmap preview should have been created. **Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc.**: MediaWiki 1.37.2 This bug is similar to T308394. It happens because `str_replace` in `SvgHandler::rasterize` [substitutes](https://www.mediawiki.org/wiki/Manual:$wgSVGConverters#Usage) the strings `$path`, `$width`, `$height`, `$input`, and `$output` in `$wgSVGConverters`, but it does the substitutions sequentially, not simultaneously. `$input` gets replaced with an input path that contains `$output`. Then, that newly introduced `$output` gets replaced with the output path (in addition to the `$output` that was already present in `$svgConverters[$svgConverter]`. https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/df1a7bf546886209b72542488bf50d4dc7f142b5/includes/media/SvgHandler.php#344 As with T308394, I did not find any security vulnerabilities caused by this bug. The only substitution an attacker can control flexibly is `$input`. Though the `$output` substitution that happens later is outside the shell quoting, its substituted value is a generated temporary path that is not likely to contain shell metacharacters. I suppose there could be unexpected behavior if the path to the temporary directory contained a space, or something like that.

**List of steps to reproduce** (step by step, including full links if applicable): * Set in LocalSettings.php: ``` $wgFileExtensions = array_merge($wgFileExtensions, array('svg')); ``` * Upload an SVG file. Give it the destination filename `Test$output.svg`. **What happens?**: See error message in the `File:` page: > %%%Error creating thumbnail: convert-im6.q16: unable to open image `/tmp/svg_caed3aacae81aada8a9a30bb/Test/tmp/transform_e13974305cb3.png.svg': No such file or directory @ error/blob.c/OpenBlob/2924. convert-im6.q16: no images defined `PNG:/tmp/transform_e13974305cb3.png' @ error/convert.c/ConvertImageCommand/3229.%%% See in `$wgDebugLogFile`: ``` [thumbnail] thumbnail failed on <hostname>: error 1 "convert-im6.q16: unable to open image `/tmp/svg_caed3aacae81aada8a9a30bb/Test/tmp/transform_e13974305cb3.png.svg': No such file or directory @ error/blob.c/OpenBlob/2924. convert-im6.q16: no images defined `PNG:/tmp/transform_e13974305cb3.png' @ error/convert.c/ConvertImageCommand/3229." from "convert -background "#ffffff00" -thumbnail 120x120\! '/tmp/svg_caed3aacae81aada8a9a30bb/Test'/tmp/transform_e13974305cb3.png'.svg' PNG:'/tmp/transform_e13974305cb3.png'" ``` **What should have happened instead?**: A bitmap preview should have been created. **Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc.**: MediaWiki 1.37.2 This bug is similar to T308394. It happens because when `str_replace` in `SvgHandler::rasterize` [substitutes](https://www.mediawiki.org/wiki/Manual:$wgSVGConverters#Usage) the strings `$path`, `$width`, `$height`, `$input`, and `$output` in `$wgSVGConverters`, it does the substitutions sequentially, not simultaneously. `$input` gets replaced with an input path that contains `$output`. Then, that newly introduced `$output` gets replaced with the output path (in addition to the `$output` that was already present in `$svgConverters[$svgConverter]`). https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/df1a7bf546886209b72542488bf50d4dc7f142b5/includes/media/SvgHandler.php#344 As with T308394, I did not find any security vulnerabilities caused by this bug. The only substitution an attacker can control flexibly is `$input`. Though the `$output` substitution that happens later is outside the shell quoting, its substituted value is a generated temporary path that is not likely to contain shell metacharacters. I suppose there could be unexpected behavior if the path to the temporary directory contained a space, or something like that.

**List of steps to reproduce** (step by step, including full links if applicable): * Set in LocalSettings.php: ``` $wgFileExtensions = array_merge($wgFileExtensions, array('svg')); ``` * Upload an SVG file. Give it the destination filename `Test$output.svg`. **What happens?**: See error message in the `File:` page: > %%%Error creating thumbnail: convert-im6.q16: unable to open image `/tmp/svg_caed3aacae81aada8a9a30bb/Test/tmp/transform_e13974305cb3.png.svg': No such file or directory @ error/blob.c/OpenBlob/2924. convert-im6.q16: no images defined `PNG:/tmp/transform_e13974305cb3.png' @ error/convert.c/ConvertImageCommand/3229.%%% See in `$wgDebugLogFile`: ``` [thumbnail] thumbnail failed on <hostname>: error 1 "convert-im6.q16: unable to open image `/tmp/svg_caed3aacae81aada8a9a30bb/Test/tmp/transform_e13974305cb3.png.svg': No such file or directory @ error/blob.c/OpenBlob/2924. convert-im6.q16: no images defined `PNG:/tmp/transform_e13974305cb3.png' @ error/convert.c/ConvertImageCommand/3229." from "convert -background "#ffffff00" -thumbnail 120x120\! '/tmp/svg_caed3aacae81aada8a9a30bb/Test'/tmp/transform_e13974305cb3.png'.svg' PNG:'/tmp/transform_e13974305cb3.png'" ``` **What should have happened instead?**: A bitmap preview should have been created. **Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc.**: MediaWiki 1.37.2 This bug is similar to T308394. It happens because when `str_replace` in `SvgHandler::rasterize` [substitutes](https://www.mediawiki.org/wiki/Manual:$wgSVGConverters#Usage) the strings `$path`, `$width`, `$height`, `$input`, and `$output` in `$wgSVGConverters`, but it does the substitutions sequentially, not simultaneously. `$input` gets replaced with an input path that contains `$output`. Then, that newly introduced `$output` gets replaced with the output path (in addition to the `$output` that was already present in `$svgConverters[$svgConverter]`). https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/df1a7bf546886209b72542488bf50d4dc7f142b5/includes/media/SvgHandler.php#344 As with T308394, I did not find any security vulnerabilities caused by this bug. The only substitution an attacker can control flexibly is `$input`. Though the `$output` substitution that happens later is outside the shell quoting, its substituted value is a generated temporary path that is not likely to contain shell metacharacters. I suppose there could be unexpected behavior if the path to the temporary directory contained a space, or something like that.