Customized HostnameVerifier bypasses the hostname verification

[GraceXiaoYa]

ISSUE TYPE

• bug report

SUMMARY

We found a security vulnerability. In file cloudstack/plugins/network-elements/palo-alto/src/main/java/com/cloud/network/utils/HttpClientWrapper.java, the customized HostnameVerfier allows all hostname to pass the verification (at Line 76).

Security Impact:

Hostname Verification is required to verify the identity of the other party. Bypassing it could allow man-in-the-middle attacks.

Useful Resources:

https://cwe.mitre.org/data/definitions/297.html

Solution we suggest:

Do not customize the HostnameVerifier or specify the verification logic instead of allowing all hostnames.

Please share with us your opinions/comments if there is any:

Is the bug report helpful?

[DaanHoogland]

sure this is not a good practise but as you provide no attackvextor/exploit there is nothing we can do with this report @AthenaXiao . thanks

[GraceXiaoYa]

Thank you so much for replying. We are a security research team at Virginia Tech. We are doing an empirical study about the usefulness of the existing security vulnerability detection tools. The reported one is what we got from certain tools.

We'll so appreciate it if you can give us some information about the following questions. Your feedback is important for us to help improve the state-of-the-art.

1. What kind of bug checker/vulnerability detection tools you are using? Do you think they are helpful?
2. What kind of supports or features do you think are necessary for a bug detector to help the practices? E.g. Demonstration of exploits or some customized fixing suggestions?
3. Are there any types of bugs/security vulnerabilities you want the detection tools to pay more attention to?

[DaanHoogland]

@AthenaXiao this is a community driven project, people that experience problems try to get solutions merged. Static analysis has been showing us bad coding practices but without shown exploit no action will be taken. Usually it turns out we are talking about dead code or code that is isolated and unexposed. As this is an integration system, a lot of support for external systems gets implemented and sometimes not phased out in a timely fashion. We get reports like this from time to time and usualy as a result, but seldom do we feel there is a thread serious enough to take action. As said without exploit nobody will be interested to take action.
As for potential attack planes, these are the API en the VR/dnmasq/iptables of routers and other system VMs.

[DaanHoogland]

relates to #4058

[dingelish]

occasionally run into this issue. i'll strongly recommend at least "alert" by printing on stderr about the usage of "insecure by default implementations". recently lots of attackers are looking into such "default flaws" in famous/wide adopted frameworks, and then use some tools like "zoomeye" to find vulnerable "default"-configured instances. i'd say as Apache project maintainers/developers, we all want to make our projects trustworthy. how do you think? @DaanHoogland

[DaanHoogland]

@dingelish I do agree, and I would like to schedule work on this, that's why I didn't close the issue. The problem is that someone has to pick it up and address it. Not having an exploit lowers the incentive for people to address it, so if you have run into this issue please add it here. A message on stderr is not going to mean much in a multi machine system like this, i think. I do not have good alternative but a red flag on the ui when a ROOT admin logs in might be an option.

[yadvr]

Closing this due to no development activity or discussions, as stale. Kindly re-open or submit an issue/PR when progress is possible. Thanks for the issue.