MODCLUSTER-875: Fix the handling of bad advertisements, add tests

[jajik]

https://redhat.atlassian.net/browse/MODCLUSTER-875

[rhusar]

The CVE description is not complete, there are other vectors but same result.

The actual failure mode in MODCLUSTER-875 isn't "NPE in verifyDigest" - it's any unchecked exception in AdvertiseListenerWorker.run() permanently kills the worker thread, because the loop only catches ClosedChannelException and IOException. Worse, listening is left at true, so isListening() keeps reporting healthy while advertisement handling is dead.

e.g.

• Integer.parseInt(sline[1]) -> HTTP/1.1 abc OK\r\n → NumberFormatException → same problem
• Utils.parseSocketAddress (Utils.java:40) -> X-Manager-Address: 127.0.0.1:notaport → NumberFormatException -> same problem

So, the fix is quite different from what is proposed here.

I ll take it from here and open a proper fix, thanks @jajik

[rhusar]

Also, this would be always null here, so the server name in the. message is useless.

[jajik]

Are you sure about this? What about a message with a Server header but a missing Date, Sequence, or Digest?

[rhusar]

You are right, I should have said "could be".

[jajik]

The CVE description is not complete, there are other vectors but same result.

That sounds like a different CVE to me. We cannot expect reports that cover everything, especially with multi-layered issues like this.

The actual failure mode in MODCLUSTER-875 isn't "NPE in verifyDigest" - it's any unchecked exception in AdvertiseListenerWorker.run() permanently kills the worker thread, because the loop only catches ClosedChannelException and IOException. Worse, listening is left at true, so isListening() keeps reporting healthy while advertisement handling is dead.

Yes and no. It's true that the exception handler should cover more of them, but the issue here was that an exception was thrown in the first place.