On Thu, 13 Mar 2025, Eli Schwartz wrote: unzip will not permit you to run:

unzip foo.zip ./dir1/member

in order to extract an archive member named "dir1/member". There is no ./ member in the archive, it's not resolved like a filesystem path.

It will print a diagnostic: "caution: filename not matched: ./dir1/member" and exit 11 (no matching files were found.) Correct. Tried that, doesn't work. The whole unzip commandline parsing looks quite fragile to me: unzip [-Z] [-cflptTuvz[abjnoqsCDKLMUVWX$/:^]] file[.zip] [file(s) ...] [-x xfile(s) ...] [-d exdir] (e.g. it allows optional arguments to be followed after any number of member files).

Thanks, Christian -- "Problem solving under linux has never been the circus that it is under AIX." (By Pete Ehlke in comp.unix.aix)

On 3/13/25 12:14 AM, Solar Designer wrote: On Wed, Mar 12, 2025 at 10:22:23PM +0100, Christian Brabandt wrote: Therefore, Vim will try to work-around it by using the [-] glob when a filename starts with a - to protect unzip from parsing the filename as an argument, which is just an ugly work-around. I was puzzled by this. I expected that if you were running unzip via the shell, then the glob pattern would be expanded back to a simple dash before being passed to unzip, and if you were running unzip directly then the glob pattern would never be expanded, so the brackets would break the intended behavior. However, it appears that unzip itself expands glob patterns even for archive names (not only for matching files in archives)? I guess this is unexpected by many unzip users, and it likely allows for other attacks on unzip and on the zip.vim plugin, by providing a filename that includes glob patterns in it so that a different archive would be processed. It certainly surprised me! That being said, given the potential danger is I guess limited to extracting multiple archives you didn't expect but you still cannot control the location (without using the member-named-leading-dash-d trick as well) and you also have to convince the user to have multiple zip archives in the same directory, it seems harder to pull anything off like this.

Note: unzip won't re-parse globs in a directory segment, only the final filename segment. Otherwise, a workaround for the original issue would be to prefix the filename with ./ as we most recently discussed in this thread:

https://www.openwall.com/lists/oss-security/2024/11/06/1 unzip will not permit you to run:

unzip foo.zip ./dir1/member

in order to extract an archive member named "dir1/member". There is no ./ member in the archive, it's not resolved like a filesystem path.

It will print a diagnostic: "caution: filename not matched: ./dir1/member" and exit 11 (no matching files were found.)

-- Eli Schwartz

On Wed, Mar 12, 2025 at 10:22:23PM +0100, Christian Brabandt wrote: Therefore, Vim will try to work-around it by using the [-] glob when a filename starts with a - to protect unzip from parsing the filename as an argument, which is just an ugly work-around. I was puzzled by this. I expected that if you were running unzip via the shell, then the glob pattern would be expanded back to a simple dash before being passed to unzip, and if you were running unzip directly then the glob pattern would never be expanded, so the brackets would break the intended behavior. However, it appears that unzip itself expands glob patterns even for archive names (not only for matching files in archives)? I guess this is unexpected by many unzip users, and it likely allows for other attacks on unzip and on the zip.vim plugin, by providing a filename that includes glob patterns in it so that a different archive would be processed.

Otherwise, a workaround for the original issue would be to prefix the filename with ./ as we most recently discussed in this thread:

https://www.openwall.com/lists/oss-security/2024/11/06/1

Alexander

Divide By Zero in vim/vim from 9.0.1367-1 to 9.0.1367-3

Eli, sorry for the duplicate. I messed up the reply...

On Mon, 20 Jan 2025, Eli Schwartz wrote: It seems strange to me to say that it is a vulnerability, for a vim option that accepts a full-blown script to also crash when fuzzed.

It's not an attack vector to crash /bin/bash when fed a malformed script, so why is there anything to comment on with regard to vim either? It was reported to us via the Security Advisory feature of Github and while I am convinced that this cannot be used to do any harm to users (except for crashing), there was still a small possibility that this may have been abused in the future.

So when in doubt, I go with the handling this as security relevant. How is this "medium" impact? The CVE calculator tends to exaggerate the score, even when being conservative with each metric.

Thanks, Christian

Buffer Overflow vulnerability in VIM v.8.1.2135 allows a remote attacker to execute arbitrary code via the operand parameter.

Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.0102.

vim 8.2.2348 is affected by null pointer dereference, allows local attackers to cause a denial of service (DoS) via the exbufferall method.

Untrusted search path vulnerability in VIM Development Group GVim before 7.3.034, and possibly other versions before 7.3.46, allows local users, and possibly remote attackers, to execute arbitrary code and conduct DLL hijacking attacks via a Trojan horse User32.dll or other DLL that is located in the same folder as a .TXT file. NOTE: some of these details are obtained from third party information.

autoload/netrw.vim (aka the Netrw Plugin) 109, 131, and other versions before 133k for Vim 7.1.266, other 7.1 versions, and 7.2 stores credentials for an FTP session, and sends those credentials when attempting to establish subsequent FTP sessions to servers on different hosts, which allows remote FTP servers to obtain sensitive information in opportunistic circumstances by logging usernames and passwords. NOTE: the upstream vendor disputes a vector involving different ports on the same host, stating "I'm assuming that they're using the same id and password on that unchanged hostname, deliberately."

Description of problem:

Ben Schmidt has discovered the following security flaw in Vim, which could lead to arbitrary code execution. Insufficient sanitization can lead to Vim executing arbitrary commands when performing keyword or tag lookup.

Flaw description pasted from original rdancer.org report (see [1]):

3.1. Keyword Lookup -- The K'' Command 3.1.1. Shell Commands and Ex Commands

Because the string passed to the shell for execution is not sanitized, it is possible to specify arbitrary shell commands where Vim expects an argument for the keyword program. Same applies to arbitrary Ex commands.

3.1.2. Keyword Program Command Line Switches

It is possible to specify command line switches for the keyword program in place of the argument. The gravity of this vulnerability depends on the keyword program selected. GNU man, the default keyword program in many installations, supports for example the --pager'' option (cf. the GNU man(1) manual page). This allows arbitrary command execution.

3.2. Tag Lookup -- the Control-]'' and g]'' Commands

Insufficient sanitization of an Ex command argument allows specifying additional arbitrary Ex commands in place of the argument.

3.3. Unknown Shell/Keyword Program

Because the syntax of the shell that is being used to execute the commands is not known beforehand, there may be other unknown vulnerabilities, that are present depending on the shell being used. Ditto for the man(1) program, and other keyword programs.

Version-Release number of selected component (if applicable): 3.0--current, possibly older

How reproducible: Always

Steps to Reproduce: 1. See part "4.EXPLOIT" from the original rdancer.org report [1] Actual results: Arbitrary code execution possible

Expected results: No security flaw present.

References:

[1] http://www.rdancer.org/vulnerablevim-K.html

Proposed patch:

Report: http://groups.google.com/group/vimdev/msg/dd32ad3a84f36bb2 Patch: http://groups.google.com/group/vimdev/attach/dd32ad3a84f36bb2/K-arbitrary-command-execution.patch?part=2

RH SRT official statement:

This issue affects all versions of the vim-enhanced package, as shipped with Red Hat Enterprise Linux 2.1, 3, 4 and 5 and within Fedora releases of 8, 9 and 10.

Heap-based buffer overflow in the mchexpandwildcards function in osunix.c in Vim 6.2 and 6.3 allows user-assisted attackers to execute arbitrary code via shell metacharacters in filenames, as demonstrated by the netrw.v3 test case.

src/configure.in in Vim 5.0 through 7.1, when used for a build with Python support, does not ensure that the Makefile-conf temporary file has the intended ownership and permissions, which allows local users to execute arbitrary code by modifying this file during a time window, or by creating it ahead of time with permissions that prevent its modification by configure.

Description of problem:

Jan Minar has reported the following problem present in Vim shellescape() function implementation and demonstrated by testcases in tar.vim plugin:

The implementation of the shellescape() function does not properly escape all special items, in particular the '!' character). This can result in untrusted data being insufficiently sanitized and possibly lead to arbitrary code execution.

To show this vulnerability can be exploited, the tar.vim plugin test cases has been updated (tarplugin, tarplugin.v2 and tarplugin.updated test cases).

CVE-2008-3074 has been pre-assigned and used in rPath advisory:

http://www.openwall.com/lists/oss-security/2008/07/10/7

References:

http://www.rdancer.org/vulnerablevim-shellescape.html http://www.openwall.com/lists/oss-security/2008/07/15/2 http://www.openwall.com/lists/oss-security/2008/07/10/7 http://www.rdancer.org/vulnerablevim.html http://www.openwall.com/lists/oss-security/2008/07/13/1 http://www.openwall.com/lists/oss-security/2008/08/01/1

Description of problem:

Jan Minar has reported the following problem present in Vim shellescape() function implementation and demonstrated by testcases in zip.vim plugin:

The implementation of the shellescape() function does not properly escape all special items, in particular the '!' character). This can result in untrusted data being insufficiently sanitized and possibly lead to arbitrary code execution.

To show this vulnerability can be exploited, the tar.vim plugin test cases has been updated (zipplugin and zipplugin.v2 test cases).

CVE-2008-3075 as been pre-assigned and used in rPath advisory:

http://www.openwall.com/lists/oss-security/2008/07/10/7 (ZIP-2)

References:

http://www.rdancer.org/vulnerablevim-shellescape.html http://www.rdancer.org/vulnerablevim.html (ZIP-1) http://www.openwall.com/lists/oss-security/2008/07/15/2 http://www.openwall.com/lists/oss-security/2008/07/13/1 (ZIP-4) http://www.openwall.com/lists/oss-security/2008/08/01/1

CVE-2008-2712 bullet (2)

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2712

mentions zipplugin based on same advisory as ZIP-1. According to ZIP-2 and ZIP-4 the zip.vim / zipplugin.vim has not been fixed as of Vim 7.2a.19/zip.vim v19, so the bullet (2) -- mention about zipplugin should be removed from CVE-2008-2712.

The Netrw plugin 125 in netrw.vim in Vim 7.2a.10 allows user-assisted attackers to execute arbitrary code via shell metacharacters in filenames used by the execute and system functions within the (1) mz and (2) mc commands, as demonstrated by the netrw.v2 and netrw.v3 test cases. NOTE: this issue reportedly exists because of an incomplete fix for CVE-2008-2712.

VIM version 8.0.1187 (and other versions most likely) ignores umask when creating a swap file ("[ORIGINALFILENAME].swp") resulting in files that may be world readable or otherwise accessible in ways not intended by the user running the vi binary.

VSCodeVim before 1.19.0 allows attackers to execute arbitrary code via a crafted workspace configuration.

An issue in the installer of gvim 9.0.0000 allows authenticated attackers to execute arbitrary code via a binary hijacking attack on C:\Program.exe.

buffer overflow when outputting colored output in xxd ===================================================== Date: 10.05.2024 Severity: Low

When outputting colored hexdumps using the -R command line flag, together with -g1 (group every byte), -c 256 (format 256 octets per line), -d (show offsets in decimal) and -o <largenumer> (add offset to the file position), the buffer used to write to may overflow.

Impact is low since the user must intentionally execute xxd with several non-default flags, but it may cause a crash of xxd.

The Vim project would like to thank github user Lennard Hofmann for reporting and fixing this issue in Vim patch 9.1.0404.

URLs: https://github.com/vim/vim/commit/67797191e039196128c69

Thanks, Chris -- Ein Torheit, über die viele Satiren gemacht worden und bei der jede neue Satire verliert, ist in der Wirklichkeit desto komischer. -- Jean Paul

Integer overflow in :history Ex-Command in Vim < 9.0.2068 =========================================================

Severity: Low

When using the :history ex-command, it's possible that the provided argument overflows the accepted value. Causing an Integer Overflow and potentially later an use-after-free.

This is not a major issue as most users probably won't use intentionally large values for the :history command

The issue is fixed in Vim version 9.0.2068.

This issue was reported on October 26th, 2023 by Cole Dilorenzo to the vim-security mailing list.

https://github.com/vim/vim/security/advisories/GHSA-q22m-h7m2-9mgm https://github.com/vim/vim/commit/9198c1f2b1ddecde22af918541e0de2a32f0f45a

Thanks, Christian -- Wer den Sirenengesang der Werbung widersteht, ist mündiger Bürger. Und gefährdet Arbeitskräfte. -- Oliver Hassencamp

Untrusted search path vulnerability in the of Vim allows local users to execute arbitrary code via a Trojan horse Python file in the current working directory, related to an erroneous setting of sys.path by the PySysSetArgv function.

References (test case, PoC): http://www.nabble.com/Bug-484305%3A-bicyclerepair%3A-bike.vim-imports-untrusted-python-files-from-cwd-td18848099.html

Proposed patch: The Debian patch for similar dia's Python related issue, available at:

http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=pythonpath.diff;att=1;bug=504251

should be sufficient to resolve this issue.

Vim (Visual editor IMproved) is an updated and improved version of the vieditor.Several input sanitization flaws were found in Vim's keyword and taghandling. If Vim looked up a document's maliciously crafted tag or keyword,it was possible to execute arbitrary code as the user running Vim.(CVE-2008-4101)Several input sanitization flaws were found in various Vim systemfunctions. If a user opened a specially crafted file, it was possible toexecute arbitrary code as the user running Vim. (CVE-2008-2712)All Vim users are advised to upgrade to these updated packages, whichcontain backported patches to correct these issues.