oss-sec mailing list archives
so, can we do something about lesspipe? (+ a cpio bug to back up the argument)
From: Michal Zalewski <lcamtuf () coredump cx>
Date: Sun, 23 Nov 2014 01:24:11 -0800
There have been some low-key discussions about this in the past, but... In short, many Linux distributions ship with the 'less' command automagically interfaced to 'lesspipe'-type scripts, usually invoked via LESSOPEN. This is certainly the case for CentOS and Ubuntu. Unfortunately, many of these scripts appear to call a rather large number of third-party tools that likely have not been designed with malicious inputs in mind. On CentOS, lesspipe appears to include things such as groff + troff + grotty, man, and cpio. On Ubuntu, there's isoinfo (?!), ar from binutils, and so on. Ancient and obscure compression utilities and doc converters crop up, too. Even grabbing something as seemingly innocuous as cpio, a short spin with afl-fuzz (or, probably, anything else) will immediately yield this: http://lcamtuf.coredump.cx/afl/vulns/lesspipe-cpio-bad-write.cpio It's a file with declared block length of 0xffffffff. That gets us here, with the value populated to c_filesize (copyin.c, list_file()): link_name = (char *) xmalloc ((unsigned int) file_hdr->c_filesize + 1); link_name[file_hdr->c_filesize] = '\0'; ...where we end up allocating a zero-byte buffer and then promptly writing out of bounds (just under the buffer on 32-bit systems or somewhere above it on 64-bit). While it's a single bug in cpio, I have no doubt that many of the other lesspipe programs are equally problematic or worse. The saving grace is that lesspipe scripts make most of their routing decisions based on file extensions. Alas, many of these extensions will be completely alien and meaningless to all but the most seasoned users (.cpi, .raw, .r42, .ear, .zoo, .a). And there are some instances of utilities being called on * (e.g., iconv, fileutils). Ultimately, I think that there's an expectation that running less on a downloaded file won't lead to RCE, and the lesspipe behavior in many distros is almost certainly violating that. I'm also not sure if the automation actually scratches any real itch - I doubt that people try to run 'less' on CD images or ar archives when knowingly working with files of that sort. WDYT? /mz
Current thread:
- so, can we do something about lesspipe? (+ a cpio bug to back up the argument) Michal Zalewski (Nov 23)
- Re: so, can we do something about lesspipe? (+ a cpio bug to back up the argument) Hanno Böck (Nov 23)
- Re: so, can we do something about lesspipe? (+ a cpio bug to back up the argument) Bernhard Hermann (Nov 23)
- Re: so, can we do something about lesspipe? (+ a cpio bug to back up the argument) Alexander Cherepanov (Dec 11)
- Re: so, can we do something about lesspipe? (+ a cpio bug to back up the argument) Alexander Cherepanov (Nov 23)
- Re: so, can we do something about lesspipe? (+ a cpio bug to back up the argument) Lionel Debroux (Nov 23)
- Re: so, can we do something about lesspipe? (+ a cpio bug to back up the argument) Michael Samuel (Nov 23)
- CVE request: cpio heap-based buffer overflow [was Re: [oss-security] so, can we do something about lesspipe? (+ a cpio bug to back up the argument)] Murray McAllister (Nov 24)
- Re: so, can we do something about lesspipe? (+ a cpio bug to back up the argument) Alexander Cherepanov (Dec 11)
- Re: so, can we do something about lesspipe? (+ a cpio bug to back up the argument) Hanno Böck (Nov 23)