Contributor II

ClearPass, Struts, development resources, etal

Skimming through the PoCs and writeups for the latest Apache Struts security screw up it's pretty obvious Apache Struts is going to be a constant source of security advisories against ClearPass.


So the timeline so far from my point of view:


August 22nd: Struts vulnerability announcement


August 22nd/23rd: Proof of concept code widely available on github, detailed writeups follow a day or two later


August 24th 10pm Eastern (Friday night):

First advisory released:

- Fix would require 6.7.6 (when avaiable)

- No mention of research needed so assumed vulnerability is known


August 27th (Monday):

Internally: Oh @!#!, they are bundling it as a major patch instead of seperately. It's the first week of class. How are we going to get this tested and deployed before everyone disappears for labor day? Hitting reload every couple of hours on the ClearPass updates page begins.


New version of advisory, still mentions 6.7.6, now it's vague as to if a patch will actually come out - More information promised on the 28th


August 29th (Wednesday):

New version of advisory, there will now be a hotfix so no version upgrade required (Thank God!). Still vague on if actual vulnerability and no actual info update on this.




How long is acceptible to wait for a patch for a system that is the cornerstone of your network's security? At what point do you give up on "research" and just assume it's the case and patch the **bleep** thing? Is ClearPass code too horrible to allow for updating of an upstream resource?


How is Aruba addressing this lag in response times when this WILL keep happening over and over again with Struts?


Why are TIPS, Insight, and Graphite sharing the same HTTP server instance/TCP port as the end user accessible self service functionality? It makes it impossible to properly firewall off admin resources from end user devices. If I can't trust web service authentication to protect the web service why would I trust ClearPass's internal IP filter to save me? It has to accept a HTTP request and parse it before it can even make that judgement. That is unneeded exposure.




MVP Guru

Re: ClearPass, Struts, development resources, etal

Please take this discussion and other security discussions with your Aruba ClearPass SE to product management and/or the Aruba Security Response team.


Using existing software components in a product is pretty common and I would even say (personal opinion) in general it is more secure to use existing software that is audited and fixed rather than re-developing the wheel yourself with all the unknown and new risks involved.


Aruba has taken the responsibility in the past to announce these vulnerabilities, over silently patching what some other vendors do. Separate from that Aruba is actively testing both internally and externally the security of the products, which results in vulnerability announcement as there is always a risk of vulnerabilities when writing software.


Expect today or tomorrow an update to the bulletin at stating that because of the configuration ClearPass is not vulnerable to this CVE. Please note that only the information in the bulletins is authoritative.


Also, in the current version of the bulletin, it states that only the Web Management part might be vulnerable (which appears not to be the case), not the other components. And putting Service Restrictions on the Web UI (best practice anyway!) allows you to limit access to only your management networks.


If you find a security vulnerability in any of the Aruba products, please reach out directly to the Aruba Security Response team instead of posting on public fora which may bring other customers at immediate risk. Contact details are here

If you have urgent issues, please contact your Aruba partner or Aruba TAC (click for contact details).
Contributor II

Re: ClearPass, Struts, development resources, etal



At no point in my post did I advocate not using a third party tool. I'm simply pointing out a specific third party component (Struts) now has a well established history of security incidents. Given how painfully stupid and trivial the latest Struts exploit is it is not unreasonable to be concerned about a two week timeframe to find out if something with PoC code available is an issue for a specific product. This cycle is going to happen over and over again. My concern is greater for this product than others due to it's role in the network and that there is no effective way to tell if ClearPass has been compromised or not unless it somehow gets trashed. It's an appliance and I'm given zero visibility into it, can't run filesystem auditing tools, etal.


And I don't trust the IP filter because by the time it is evaluated the server has already been handed an HTTP request that had to be parsed and fed through some logic. If the admin only services were moved to another port I could firewall that off elsewhere in the network and avoid exposing unneeded surface area on the product.


Also thank you for the update on the advisory. I can now breath easier that it isn't going to mess with vacation time I have scheduled next week. ;-)


Occasional Contributor II

Re: ClearPass, Struts, development resources, etal

Count me (yes, I'll talk to our support team) as another who is really bugged at the fact that I can't split the administrative apps from the user-facing apps in a high-assurance way since it isn't possible to split them across different ports.

MVP Guru

Re: ClearPass, Struts, development resources, etal

Please work with your local partner or Aruba team to get this request addressed to product management. Both partners and Aruba SEs can file feature requests and make sure they get the proper attention.


Send me a personal message via Airheads if you can't find the right person so I can help.

If you have urgent issues, please contact your Aruba partner or Aruba TAC (click for contact details).
Search Airheads
Showing results for 
Search instead for 
Did you mean: