OPTIONS requests expose what other methods are supported

[jdalls]

CUPS project Security,

Has anyone reported the below issue and provided a solution to resolve. I did the internet research and I can’t find anything, you guys are my last hope.
I am NOT a programmer. The best I can do is upgrade CUPS to the latest version.

Thanks for your help!

This issue was highlighted by our network vulnerability scanner. Problem Management(PM) ticket PM60976.

“Web servers that respond to the OPTIONS HTTP method expose what other methods are supported by the web server, allowing attackers to narrow and intensify their efforts.”

The method I used to test this was telnet. This is the response I get from running the telnet command.

HTTP/1.0 200 OK
Date: Wed, 06 Mar 2019 14:22:42 GMT
Server: CUPS/1.6 IPP/2.1
Content-Language: en_US
Allow: GET, HEAD, OPTIONS, POST, PUT
Content-Length: 0

I found many solutions to disable “OPTIONS” for Apache, Apache Tomcat & IIS but nothing for CUPS.
I reviewed the cupsd.conf and didn’t see any options.

Jim

[michaelrsweet]

@jdalls It is not possible to disable support for the OPTIONS command, since it is required for HTTP upgrade to TLS. Can you provide any additional references as to what vulnerabilities your scanner thinks are present?

Thanks!

[jdalls]

Mike, Thanks for your time! I can’t believe someone responded this fast.

There are no other network vulnerabilities reported for this server.

This is a HTTP request method. Examples of being OPTIONS, TRACE, and DELETE. This issue is normally reported for Apache & IIS web servers. It’s the first time I’ve seen it for CUPS – heck I had no idea CUPS had a web interface until now.

Our network vulnerability scanner hasn’t reported any other issues with CUPS listening on port 631 and having the HTTP request method OPTIONS enabled. I would configure CUPS to disable the Web interface but our guy in the print shop says he needs the Web interface to set up new printers.

On most of our servers with this issue the HTTP method is disabled in IIS using “filters”. In Apache we use a security constraint (a few lines in the Web.xml file)

Hope this helps. It’s not much but I hope it helps.

Jim

[jdalls]

oops - closed by mistake.

[michaelrsweet]

@jdalls No, I was wondering if your software actually referenced what the vulnerability is. Saying the OPTIONS request can be used to narrow an attack doesn't actually say anything - an attacker can just try those other requests to see if the request methods are supported, so I'm not sure why having the OPTIONS request return a list of supported request methods is a problem?

Like I said, CUPS must support the OPTIONS request method because we need it for TLS upgrades (a required part of IPP). So what I need is more information about the vulnerability being reported and the scanner being used to determine whether this is something we will even try to address.

[jdalls]

Mike,
This URL might be helpful, it has some basic information about the scanner: https://www.rapid7.com/products/insightvm/.
This is a link to the vulnerability: https://www.rapid7.com/db/vulnerabilities/http-options-method-enabled
This URL explains everything, the url for this was found on www.rapid7.com also: https://www.owasp.org/index.php/Test_HTTP_Methods_%28OTG-CONFIG-006%29

[michaelrsweet]

OK, after reviewing HTTP Upgrade to TLS (RFC 2817) and HTTP/1.1 Semantics and Content (RFC 7231), it looks like returning the Allow header is usually optional except when returning a 405 (method not allowed) status, and HTTP Upgrade to TLS doesn't explicitly require the Allow header either.

I will investigate what can be done here without breaking existing clients. As for getting a fix, you should contact your Linux distributor for assistance...

[michaelrsweet]

(Not tagging as security since the Server header identifies the HTTP server as CUPS, which tells you a lot more than the Allow header...)

[michaelrsweet]

[master d2df4e4] Stop advertising the HTTP methods that are supported (Issue #5540)