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

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

Accounts. A logic issue was addressed with improved file handling.

Vim is an open source command line text editor. When performing a search and displaying the search-count message is disabled (:set shm+=S), the search pattern is displayed at the bottom of the screen in a buffer (msgbuf). When right-left mode (:set rl) is enabled, the search pattern is reversed. This happens by allocating a new buffer. If the search pattern contains some ASCII NUL characters, the buffer allocated will be smaller than the original allocated buffer (because for allocating the reversed buffer, the strlen() function is called, which only counts until it notices an ASCII NUL byte ) and thus the original length indicator is wrong. This causes an overflow when accessing characters inside the msgbuf by the previously (now wrong) length of the msgbuf. The issue has been fixed as of Vim patch v9.1.0689.

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

Last updated 24 July 2024

Last updated 24 July 2024

Last updated 24 July 2024

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

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

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

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

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

Accounts. A privacy issue was addressed with improved private data redaction for log entries.

NULL Pointer Dereference in GitHub repository vim/vim prior to 9.0.1402.

NULL Pointer Dereference in GitHub repository vim/vim prior to 9.0.1392.

Incorrect Calculation of Buffer Size in GitHub repository vim/vim prior to 9.0.1378.

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

Divide By Zero in GitHub repository vim/vim prior to 9.0.1367.

AMD. A buffer overflow issue was addressed with improved memory handling.

AMD. A buffer overflow issue was addressed with improved memory handling.

A null pointer dereference issue was discovered in function guix11createblankmouse in guix11.c in vim 8.1.2269 thru 9.0.0339 allows attackers to cause denial of service or other unspecified impacts.

AMD. A buffer overflow issue was addressed with improved memory handling.

AMD. A buffer overflow issue was addressed with improved memory handling.

AMD. A buffer overflow issue was addressed with improved memory handling.

AMD. A buffer overflow issue was addressed with improved memory handling.

Floating Point Comparison with Incorrect Operator in GitHub repository vim/vim prior to 9.0.0804.