Impact
When running Git in the Windows Subsystem for Linux and working on Windows drives directly, and when running Git on macOS and working on smb://-mounted network shares, Git is susceptible to NTFS-related attacks.
While it would seem that NTFS Alternate Data Streams (the subject of CVE-2019-1352) are disabled when accessing files or directories on Windows drives from within the Windows Subsystem for Linux, files and directories can still be accessed via their NTFS short names (where enabled).
For smb://-mounted network shares on macOS, the situation seems reversed: NTFS short names are disabled, but NTFS Alternate Data Streams are not.
Patches
The problem has been patched in the versions published on Tuesday, December 10th, 2019.
Workarounds
Turn on core.protectNTFS explicitly, e.g. via git config --global core.protectNTFS true at a user-level, or via git config --system core.protectNTFS true at the system level.
Alternatively, avoid cloning untrusted repositories.
References
Impact
When running Git in the Windows Subsystem for Linux and working on Windows drives directly, and when running Git on macOS and working on
smb://-mounted network shares, Git is susceptible to NTFS-related attacks.While it would seem that NTFS Alternate Data Streams (the subject of CVE-2019-1352) are disabled when accessing files or directories on Windows drives from within the Windows Subsystem for Linux, files and directories can still be accessed via their NTFS short names (where enabled).
For
smb://-mounted network shares on macOS, the situation seems reversed: NTFS short names are disabled, but NTFS Alternate Data Streams are not.Patches
The problem has been patched in the versions published on Tuesday, December 10th, 2019.
Workarounds
Turn on
core.protectNTFSexplicitly, e.g. viagit config --global core.protectNTFS trueat a user-level, or viagit config --system core.protectNTFS trueat the system level.Alternatively, avoid cloning untrusted repositories.
References