You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The zangle code produced by README.MD includes a flag to switch enabling absolute paths with the intent to prevent escape from the working directory, as that would allow user-priviledged malicious actions to occur from untrusted documents.
However, this can be bypassed without the flag on Linux systems using the double dot file system syntax. Including an arbitrary number of '../' sections in the relative path would allow for the escape of the working directory up to root '/', from which point the malicious file context can descend again into accessible directories. Presently this is the only check for the path.
if (path[0] == '/' and !options.allow_absolute_paths) { return error.@"Absolute paths disabled; use --allow-absolute-paths to enable them."; }
I propose this is an oversight that needs to be corrected for safety and usability purposes with a more robust check of the paths provided for each file context. At minimum the '..' syntax should be filtered against, and a measure taken to ensure a similar issue cannot occur on Windows.
The text was updated successfully, but these errors were encountered:
The zangle code produced by README.MD includes a flag to switch enabling absolute paths with the intent to prevent escape from the working directory, as that would allow user-priviledged malicious actions to occur from untrusted documents.
However, this can be bypassed without the flag on Linux systems using the double dot file system syntax. Including an arbitrary number of '../' sections in the relative path would allow for the escape of the working directory up to root '/', from which point the malicious file context can descend again into accessible directories. Presently this is the only check for the path.
if (path[0] == '/' and !options.allow_absolute_paths) { return error.@"Absolute paths disabled; use --allow-absolute-paths to enable them."; }
I propose this is an oversight that needs to be corrected for safety and usability purposes with a more robust check of the paths provided for each file context. At minimum the '..' syntax should be filtered against, and a measure taken to ensure a similar issue cannot occur on Windows.
The text was updated successfully, but these errors were encountered: