[HN Gopher] Arbitrary file write vulnerability in GNU gzip's zgr...
___________________________________________________________________
Arbitrary file write vulnerability in GNU gzip's zgrep utility
Author : perihelions
Score : 76 points
Date : 2022-04-18 20:25 UTC (2 hours ago)
(HTM) web link (access.redhat.com)
(TXT) w3m dump (access.redhat.com)
| develatio wrote:
| 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
| mikece wrote:
| "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 wrote:
| 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 wrote:
| 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.
| benibela wrote:
| I made a whole collection:
| https://github.com/benibela/nasty-files
| asddubs wrote:
| "--no-preserve-root" made me laugh. for testing unescaped
| calls to rm?
| pixl97 wrote:
| 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 wrote:
| 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.
| timdoug wrote:
| 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$
| TheDong wrote:
| 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).
| foota wrote:
| The thought of writing anything in sh is horrifying to me.
| bee_rider wrote:
| 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.
| nikonyrh wrote:
| This reminds me that filenames can contain newlines.
| mc4ndr3 wrote:
| Why does a search tool even need to open a writable file handle?
| opencl wrote:
| It's for searching inside of compressed files, and does this by
| decompressing to a temporary directory.
| deathanatos wrote:
| ... that is also shocking... it wouldn't just stream the
| decompression, perhaps piping the decompressed stream into
| grep itself?
| staunch wrote:
| 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.
| belltaco wrote:
| .
| pixl97 wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| josephcsible wrote:
| When is this actually exploitable? Are there any common programs
| or setups that result in zgrep getting called on attacker-
| provided filenames?
| hsbauauvhabzb wrote:
| 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.
___________________________________________________________________
(page generated 2022-04-18 23:00 UTC)